by ·0 Comments

По подразбиране когато си инсталирате Munin в Cpanel липсват няколко благи конфига които трябва да си ги направим на ръка. За мен един от тях е мониторинга на температурата  на дисковете.

В общи линии конфигурацията е тривиална

1. Трябва да определим типа на нашите дискове – той може да бъде един от следните : ata, scsi, sat[,auto][,N][+TYPE], usbcypress[,X], usbjmicron[,x][,N], usbsunplus, marvell, areca,N/E, 3ware,N, hpt,L/M/N, megaraid,N, cciss,N, auto, test. Най лесният начин за това е чрез cat на „/proc/ide“ или „/proc/scsi“. При мен:


# cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: WDC WD1003FBYZ-0 Rev: 01.0
  Type:   Direct-Access                    ANSI  SCSI revision: 05
Host: scsi1 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: WDC WD1003FBYX-0 Rev: 01.0
  Type:   Direct-Access                    ANSI  SCSI revision: 05
Host: scsi4 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: TOSHIBA DT01ACA1 Rev: MS2O
  Type:   Direct-Access                    ANSI  SCSI revision: 05

 

 

Както се вижда имам 3 диска тип ATA.

2. За да почнем да следим температурата трябва да опишем в munin node дисковете ни. В файла /etc/munin/plugin-conf.d/hddtemp_smartctl добавяте записи от следният тип


# cat /etc/munin/plugin-conf.d/hddtemp_smartctl
[hddtemp_smartctl]
user root
env.drives sda sdb
env.args_sda -d ata
env.args_sdb -d ata

 

Можем да ударим тест на нашият бъдещ конфиг по следният начин


# env drives="sda sdb sdc" args_sda="-d ata" args_sdb="-d ata" args_sdc="-d ata"  /etc/munin/plugins/hddtemp_smartctl
sda.value 32
sdb.value 33
sdc.value 33

 

Ако получите стойности значи всичко е ок. Ако получите грешка трябва да проверите дали всичко правилно описано. Следва да рестартирате munin nod-а ви и да изчакте 10-15 мин да се популират малко данни и да почне да се чертае графика. Можете да проверите /var/log/munin/munin-node.log за грешки и по лесното им отстраняване.

Ако искате да получавате email при критична температура на дисковете трябва да добавите описание за критична такава:

[example.com]
    address 127.0.0.1
    use_node_name yes
    hddtemp_smartctl.sda.critical 55
    hddtemp_smartctl.sdb.critical 55

by ·0 Comments

Днес реших да направя няколко теста върху чиста Cpanel инсталация за която имах необходимост от няколко потребителя. Тъй като не исках да натоварвам работещите сървъри с пакетиране архивиране и трансфер на файловете използвах архивите от предишната вечер. Трансферирах си всички архиви в /home и установих че Cpanel не предлага възстановяването на повече 1 акаунт едновременно както през GUI така и през CLI. През GUI тъй като нямаше как да се получи номера реших да се изхитря с cli скрипта restorepkg. Използването му е безкрайно просто

/scripts/restorepkg username.tar.gz

Като действието се повтаря за всеки потребител по отделно. При опит да използвам * вместо името на потребителя скрипта деректно ме отряза затова трябва да се подходи малко по елегантно –


archives=$(ls /home/ | grep tar.gz)

for archive in $archives

do

/scripts/restorepkg --force $archive

done

Сега бързо обяснение. Правим си списък с всички архиви и го блъскаме в променливата archives след това обхождаме списъка елемент по елемент като стартираме разпакетирането за всеки архив по отделно. Нищо кой знае колко сложно интересно защо пичовете от Cpanel не са изплзвали подобно решение за множество файлове.

by ·0 Comments

От миналата седмица закупихме Fantastico Deluxe инсталатора, който по мое скромно мнение е един от най приличните за CPanel сървъри. Инсталирахме го тествахме и всичко мина гладко. Днес един клиент ми съобщи за проблем с енкодинга на wordpress инсталация. Прегледах нещата и веднага лъсна проблема базите бяха с енкодинг по подразбиране Latin1 вместо UTF8 като се предполагаше. Още по забавното е, че в phpmyadmin-а пише че се използва UTF8 по подразбиране, драма. Реших да прегледам файловете на Fantastico-то да видя дали няма някъде където мога да окажа настройките за базите данни по подразбиране на пръв поглед не видях нищо. След това нещо ме текна да видя какво има в my.conf-а и какво да видя нямаше съответните настройки във конфигурация и всичко си пали на каквото му е зададено по подразбиране. Mysql сървъра е хардкоднат да ползва UTF8 ако не е конфигуриран с други настройки и Fantastico-то явно е с Latin1 ( което е доста глупаво решение). Решението както винаги е тривиално добавят се 2 реда в [mysqld] часста за да се окаже UTF8 като кодировка по подразбиране и всичко заспива 🙂

character-set-server=utf8
collation-server=utf8_general_ci

Нямам никаква идея поради каква причина съм пропуснал тези настройки при положение че си играх да правя няколко „фини“ настройки на mysql-а.

Enhanced by Zemanta

by ·2 Comments
Tux, as originally drawn by Larry Ewing

Image via Wikipedia

Днес мисля малко да по размишлявам върху това извращение на природата CentOS. Вдъхновен от наскоро излязлата CentOS 6-та версия имам какво и аз да кажа. Само по себе си тая глупост е разработка RedHat и е сървърен форк на тяхната Red Had Enterprise Linux. Използва rpm пакетния им менаджер (които е ужасно велик, да ама не).

Нека да започна с това което ме накара да започна да пиша и да размишлявам що за изрод е това CentOS и има ли почва в моите сървъри. Преди около седмица излезе верися 6 и реших да ъпдейтна настоящата ми 5.6 инсталация на VPS хостинга ни. Бях доста неприятно изненадан като видях, че не ми отчете пакети ъпдейт. Реших, че нещо аз бъркам и проверих в Интернет. Бях шокиран като видях препоръката на производителя е да се прави чиста инсталация и дистрибутививен ъпгрейд от 5.6 не е препоръчителен и се прави с кила черни магии и затова не е възможно по стандартен начин. Хммм доста интересен момент. 😆 И това се води enterprise дистрибуция, много интересно. Не виждам как може дори да се класира в тази категория освен, че производителя и сложил това гръмко наименование. Да приемем следните 2 сценария – единия е правим нов инстал другия е не правим.

1. Сценарии – Свалям сървъра разкачам го спира всички услуги които поддържа. Инсталирам го за 1 час или повече бизнеса за които работя търпи големи загуби като парички. Аз си губя работата като системен админснитратор вероятно или ще отнеса солени глоби. Да не коментираме всички мъки покрай настройките и правилния архив на данни и настройки. Кила нерви резулатта е имаме чиста система. Очевидно варианта не е приемлив.

2. Сценарии – Не правим дистрибутивен ъпгрейд системата си седи така докато се пускат кръпки по сигурноста. Докато в един момент не и се прекрати подръжката след известно време бива хакната заради пробойна в някоя от услугите които предлага, заради невъзможноста да си да осигурява диструбутивно надграждане. Крадат се данни или просто само се компроментира сървъра – отновно солени глоби или си губиш работата.

Доста интересно и двата сценария завършват доста неприятно за системния им администратор заради капитална греша в дизайна на дистрибуцията подбора и  мързела на компанията която я разработва за да не осигури съвместимост между пакетите. Докато от друга страна има не чак толкова enterprise дистрибуции които се надграждат тихо и кротко, без да носят гръмки имена. Имам Debian сървър които е от версия 3 надграден до актуаланта версия 6 в момента сиреч преживял е 3 големи надграждания като не е имало отказ до достъпа на услугите. По принцип единия от основните принцип на админа е – „Ако работи не се пипа“ но затова хората откриват дупки пускат кръпки затова излизат нови пакети да подобряват стабилността или да ускоряват производителността. В заключение освен мое лично мнение но и мнение на много мои приятели къде по добри админи от мен е CenOS не струва.

Related articles
Enhanced by Zemanta