by ·0 Comments

Новият Debian Stable е факт от около седмица и ме сърбяха ръцете да си надградя виртуалката до него но нямах никакво време до днес. Тъй като денят ми стартира рано реших да посветя време на ъпгрейда. Промених сорс листа ми като промених wheezy  на jessie

sed -i "s/wheezy/jessie/g" /etc/apt/sources.list && apt-get update

Тук изгърмяха 2 огледала:

  • MariaDB – от това огледало вече няма нужда Jessie включва версия 10.0.6 в себе си което не ми се понрави много. След 5.5 мичетодб и mysql не са съвсем съвместими заради което към момента врътнах обратно към mysql 5.5.42 – той е по подразбиране в jessie
  • DotDeb – използвах го преди за php55 тук също е излишен защото Jessie идва с 5.6.7-1

След като разкарах излишните огледала и врътнах от MariaDB към Mysql apt-get dist-upgrade мина чисто, reboot и вече бях с Debian 8.0. Отворих си web server-а и за моя изненада работеше тук историята е дълга – с няколко думи Nginx-а ми е компилиран допълнително от source с допълнителни директиви. dpkg -l nginx-full 1.2 мдааа някой е забравил да си unhold-не пакетите. Unhold и upgrade всичко е по план nginx-а се счупи 😆 . Nginx-а работи обработва заявки и php-fpm процеса е up and runnign но php code не се изпълнява и не плюе грешки 🙄 ЛЮБИМОТО МИ.

След известно търсене на информация за промените открих следният пасаж

Fastcgi configuration issues ============================

nginx shipped a modified fastcgi_params, which declared SCRIPT_FILENAME fastcgi_param. This line has now been removed. From now on we are also shipping fastcgi.conf from the upstream repository, which includes a sane SCRIPT_FILENAME parameter value.

So, if you are using fastcgi_params, you can try switching to fastcgi.conf or manually set the relevant params.

Бинго. Промених виртуалните хостове да използват fastcgi.conf вместо да правя груби вмешателства и всичко запали. След това ударих един бърз diff за да видим разликата каква е между 2-та конфига


diff /etc/nginx/fastcgi_params /etc/nginx/fastcgi.conf
1a2
> fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;

Което ми припомни че наливането на големи конфигурации във виртуаните хостове не е готина идея. Остава да си прекомпилирам отново Nginx-а с добавките които искам mod_sec + pagespeed но това може да почака. Далеч по важното е, че правилото ми се повтори ако нямаш огледа от 3-ти източници и кастъм изпълнения Debian не се чупи при dist-upgrade!

https://www.youtube.com/watch?v=gEQCny6zNF0

by ·0 Comments

Тъй като от 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

by ·0 Comments

Mdadm е мой любим приятел но има нещо което дразни ужасно много – периодични проверки и ресинк за сигурност на здравето на RAID масива- например има данни в bad sector-и, което от своя страна смачква машината от към IO. В общи линии след чоплене открих виновниците – кронове които се стартират обикновено около 1ч вечерта всяка неделя. Идеята е ясна – сигурност че масива е в перфектно състояние и няма драми с информацията. Това е добре ама ежеседмично ми се вижда много, затова си го преконфигурирах да се рънва на всяка първа дата от месеца.

За Redhat базираните деривати пътя на крона е /etc/cron.d/raid-check. За Debian базираните дистроци пътя е /etc/cron.d/mdadm. Кроновете от своя страна извикват bash скриптове /usr/sbin/raid-check за CentOS etc и /usr/share/mdadm/checkarray за Debian и приятели. Параметри към скриптовете се взема от /etc/sysconfig/raid-check или съответно /etc/default/mdadm където може да бъде забранен изцяло check-а, което не е много умно като идея.

 

by ·0 Comments

Някой програмисти просто няма да се научат да пишат грамотно по 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

by ·0 Comments

Всеки който се занимава професионално с 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 пъти и половина по бързо в сравнение с преди.