Лесно можем да избием всички mysql заявки на определн потребител с елегантното:
select concat('KILL ',id,';') from information_schema.processlist where user='user123';
Заместваме user123 с желаният от нас потребител и изпълняваме в mysql и всичко е ОК 🙂
Новият Debian Stable е факт от около седмица и ме сърбяха ръцете да си надградя виртуалката до него но нямах никакво време до днес. Тъй като денят ми стартира рано реших да посветя време на ъпгрейда. Промених сорс листа ми като промених wheezy на jessie
sed -i "s/wheezy/jessie/g" /etc/apt/sources.list && apt-get update
Тук изгърмяха 2 огледала:
След като разкарах излишните огледала и врътнах от 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
Тъй като от 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
Изпълних си командите за чистиха се файловете им като осъзнах нещо важно пичовете изобщо не споменаха как се де регистрира плъгина им от контролният панел 🙄 😆 Мдаа педераски номер но се случва то и аз трябваше да гледам повече. Също така имаше останала една камара техни файлове явно се надяват да се върна като техен клиент, тъй като имали най много скриптове за инсталация както каза съпорт (не думай това е най важното направо) 
. Та нека да продължим с пълното изкормване:
Това е най важната стъпка която трябва да се направи преди да затриете всичко останало тъй като после ще се окажете бе плъгин но с икона в контролния панел тъй като все е още е регистриран.
/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 и то много семпли
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
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-а, което не е много умно като идея.
Някой програмисти просто няма да се научат да пишат грамотно по 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