Тъй като от netenberg изобщо не оправдаха очакванията ми за fantastico 3 та реших да го разкарам тоталка. Въпреки кореспонденцията която водихме преди много време и насоките които им дадох за подобряване на продукта им до конкурентно способно ниво на softaculous и installatron се стигна до момента в който трябваше да бъде деинсталиран техният плъгин от Cpanel сървърите ми. Тъй като няма инструкции как се премахва това недоразумения вдигнах тикет на support-а те ми дадоха следните инструкции.

rm -rf /var/netenberg/fantastico_de_luxe/
rm -rf /usr/local/cpanel/whostmgr/docroot/cgi/fantastico/
rm -rf /usr/local/cpanel/3rdparty/fantastico*
rm -rf /usr/local/cpanel/base/frontend/*/fantastico
rm -f /usr/local/cpanel/base/frontend/x/cells/fantastico.html
rm -f /usr/local/cpanel/whostmgr/docroot/cgi/addon_fantastico.cgi

Изпълних си командите за чистиха се файловете им като осъзнах нещо важно пичовете изобщо не споменаха как се де регистрира плъгина им от контролният панел 🙄  😆 Мдаа педераски номер но се случва то и аз трябваше да гледам повече. Също така имаше останала една камара техни файлове явно се надяват да се върна като техен клиент, тъй като имали най много скриптове за инсталация както каза съпорт (не думай това е най важното направо) :mrgreen: . Та нека да продължим с пълното изкормване:

Това е най важната стъпка която трябва да се направи преди да затриете всичко останало тъй като после ще се окажете бе плъгин но с икона в контролния панел тъй като все е още е регистриран.

/usr/local/cpanel/bin/unregister_cpanelplugin /var/netenberg/fantastico_f3/fantastico_f3
rm -rf /usr/local/cpanel/3rdparty/fantastico_f3
rm -rf /usr/local/cpanel/base/frontend/*/fantastico_f3
rm -rf /usr/local/cpanel/bin/fantastico_f3.cpanelplugin
rm -rf /usr/local/cpanel/whostmgr/addonfeatures/fantastico_f3
rm -rf /usr/local/cpanel/whostmgr/addonsfeatures/fantastico_f3
rm -rf /usr/local/cpanel/whostmgr/docroot/addon_plugins/fantastico_f3.jpg
rm -rf /usr/local/cpanel/whostmgr/docroot/cgi/addon_fantastico_f3.php
rm -rf /usr/local/cpanel/whostmgr/docroot/cgi/fantastico_f3
rm -rf /var/cpanel/apps/fantastico_f3_cpanel.conf
rm -rf /var/cpanel/apps/fantastico_f3_whm.conf
rm -rf /var/netenberg/fantastico_f3

В случей че сте пропуснали стъпката unregister_cpanelplugi се налага да се играе още една допълнителна стъпка:

mkdir --parents /var/netenberg/fantastico_f3
cd /var/netenberg/fantastico_f3 && curl -O http://174.120.165.106/fantastico_f3/sources.tar.bz2
cd /var/netenberg/fantastico_f3 && tar --bzip2 --extract --file sources.tar.bz2
/usr/local/cpanel/bin/unregister_cpanelplugin  fantastico_f3
rm -rf /var/netenberg/

Воала вече fantastico е извън играта и можете да спите спокойно. Причините поради които го смених с конкурентен продукт са 3 и то много семпли

  • Нямат API с което мога да си комуникирам ако искам да правя допълнения или някакви други магии
  • нямат hooks при определени действия да мога да се закачам и да дописвам функционалност
  • кофти support доста бавен и не много адекватен в отговорите си

ps. paper_lantern и x3 имаше останала икона която се разкарва с

rm  /usr/local/cpanel/base/frontend/paper_lantern/dynamicui/dynamicui_fantastico_f3.conf
rm /usr/local/cpanel/base/frontend/x3/dynamicui/dynamicui_fantastico_f3.conf

Някой програмисти просто няма да се научат да пишат грамотно по RFC никога. Забелязах множество errror_log файлове в който се бяха натрупали огромен брой малоумни warning-и и notice за неспазване на PHP стандартите. В общи линии е трудно да се обясни на потребителя, че кода който е сложил е кофти и трябва да се поправя. В общият случай съм забелязал че потребителите не ги вълнуват error log-овете след като им работи кода. По принцип радикален подход е да спра изцяло error_log файловете и който иска да си ги пуска, но като цяло ще създаде дискомфорт за доста потребители. Затова се засилвам към подход 2 – админски супер сили или 1 ред bash. Търсене на файлове с име error_log с размер повече от 5MB (тук стойността ми я оставям по голяма въпреки че 1MB е повече от достатъчно) и изтриването им ежеседмични. Въпросният ефект се постига елементарно с find

find /home/ -name error_log -size +5M -type f -delete

Остава само да се блъсне в крон който да се изпълнява веднъж седмично и имаме доста персистентно решение. В моя случей ми се струва ок в 1 часа вечерта всяка неделя.

0 1 * * 1 find /home/ -name error_log -size +5M -type f -delete >/dev/null 2>&1

Всеки който се занимава професионално с web hosting знае каква заплаха представляват заразените потребители с malware, web shells etc. В обшият случей се използва maldet един не лош скрипт. Той се отличава с 3 неща

  1. Ужасно бавен е
  2. Ужасно бавен е и ако го пуснеш в мониторинг режим ще се изгаври със сървъра ти
  3. Поддържа собствена база данни с md5/hex дефиници за кофти код.

Точно последната му характеристика го прави полезен, тъй като освен всичко друго може да събмитваш файлове който не са били засечени досега и на по късен етап ще влязат в базите данни. Както споделих в точка 1 и 2 скоростта му е шокиращо ниска – при ниско натоварване на машината 70к файла се сканираха за около час и половина. Поради тази причина започнах да помагам на моя добър приятел ShadowX с malmon – алтернатива на maldet написана на python с малко по голяма гъвкавост. За съжаление от липса на време (основно но не само) не сме довършили проекта, който към момента не е много използваем – има доста бъгове които трябва да се изчистят. През изминалите дни имах проблеми с клиенти заразени с CryptoPHP които имаха огромни public_html файлове ~60к+ inod-а на потребител. Тъй като сумарно трябваше да се сканират над 200к файла което по груби сметки щеше да отнеме 5+ часа реших да тунинговам конфигурацията на maldet, за да намаля файловете които ще се сканират до някаква по разумна бройка и време. Докато чоплех конфа забелязах следните редове


# Attempt to detect the presence of ClamAV clamscan binary
# and use as default scanner engine; up to four times faster
# scan performance and superior hex analysis. This option
# only uses ClamAV as the scanner engine, LMD signatures
# are still the basis for detecting threats.
# [ 0 = disabled, 1 = enabled; enabled by default ]
clamav_scan=1

Интересно… Явно има възможност да използва ClamAV – който също не се отличава с голямата си скорост но пък защо да не пробвам. На бързо го инсталирах


/scripts/update_local_rpm_versions --edit target_settings.clamav installed

/scripts/check_cpanel_rpms --fix --targets=clamav

Пускам maldet-а върху малка папка – не виждам разлика в скоростта и поведението – използваше си неговият perl-ски скенер вместо този на clamav. След кратко ровене из сорса на maldet открих следните редове

 clamscan=`which clamscan 2> /dev/null`
 if [ -f "$clamscan" ] && [ "$clamav_scan" == "1" ]; then
        eout "{scan} found ClamAV clamscan binary, using as scanner engine..." 1
    for hit in `$clamscan -d $inspath/sigs/rfxn.ndb -d $inspath/sigs/rfxn.hdb $clamav_db -r --infected --no-summary -f $find_results 2> /dev/null | tr -d ':' | sed 's/.UNOFFICIAL//' | awk '{print$2":"$1}'`; do

Мдааа направих един which clamscan и за моя голяма изненада открих че clamav изобщо не е в PATH-a ами тъпият Cpanel го е оставил само в /usr/local/cpanel/3rdparty/bin/ от където той си използва бинарките. Един бърз ln реши проблема:

ln -s /usr/local/cpanel/3rdparty/bin/clamscan /usr/bin/clamscan

При повторно сканиране maldet вече горно съобщава

{scan} found ClamAV clamscan binary, using as scanner engine...

След като вече използва ClamAV maldet приключва сканирането си 3-4-5 пъти по бързо в сравнение с преди. Теста показа – 70к inod-а ги изтъркла за около 25 мин което си е около 3 пъти и половина по бързо в сравнение с преди.

По подразбиране когато си инсталирате 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

Днес реших да направя няколко теста върху чиста 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 не са изплзвали подобно решение за множество файлове.