Някой програмисти просто няма да се научат да пишат грамотно по 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 часа вечерта всяка неделя.
Всеки който се занимава професионално с web hosting знае каква заплаха представляват заразените потребители с malware, web shells etc. В обшият случей се използва maldet един не лош скрипт. Той се отличава с 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 – който също не се отличава с голямата си скорост но пък защо да не пробвам. На бързо го инсталирах
Пускам 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 реши проблема:
{scan} found ClamAV clamscan binary, using as scanner engine...
След като вече използва ClamAV maldet приключва сканирането си 3-4-5 пъти по бързо в сравнение с преди. Теста показа – 70к inod-а ги изтъркла за около 25 мин което си е около 3 пъти и половина по бързо в сравнение с преди.
Преди да почна с поредният random hate към 50 с’тинки OS искам да кажа, че ежедневно ми се налага да я администрирам и я познавам от първо лице единствено число доста добре. Днес отделих време за да изтествам новата магическа нечувана и невиждана функция за диструбитивен ъпгрейд (псевдо) 😀 . Първото нещо което ме изуми е, че RedHat в своята безкрайна мъдрост са решили да прекратят поддръжката на х86 архитектурата 🙄 . Напълно съм наясно че сме 2014-та година и сървърни процесори с 32 бита инструкции липсват отдавна. Мда ама какво правят потребителите на малки VPS-и – х64 лапа повече рам, както и да го погледнеш ако имаш тънка виртуална машинка с 512МБ-1ГБ рам ще се бориш за всеки мегабай от нея и няма да прахосаш 20-30% от нея просто за да използваш по големият сет от инструкции. Препсувах тъй като си бях инсталил х86 CentOS и дръпнах един х64. Веднага видях разлика в ISO-тата – ~100MB при minimal 6.5. Препсувах още един път. Инсталирах си отново виртуалката като реших да видим RedHat колко добре са си свършили работата – изнесох /var и /usr на отделни LVM дялове 😈 . След инсталацията обнових всички пакети инсталирах си и apache, php, mysql и bind – беше интересно дали ще запалят сървисите. Отворих си като добра ученичка ръководството на CentOS за ъпдейта и започнах прилежно да го следва стъпка по стъпка. Когато стигнах до момента да започне реалното надграждане тая пумия ме изряза, че имам критичен проблем 🙄 . Преглеждам детайлният изход – мдаааа /usr неможе да е на отделен дял 😆 знаех си, че няма да бъда разочарован от Jim Whitehurst и компания. Освен „екстремният“ проблем имаше доста съобщения за неподписани пакети, файлове за конфизи които не съответстват и прочие. WTF дори не бях ползват 3-ти хранилища всичко от техните огледала смъкнах не бях правил никакви настройки просто елементарен yum install. Вече всичко беше ясно затова съвсем безцеремонно форсирах upgrade. Рестартирах отново прилежно както ме подкани накрая скрипта и всичко приключи заради /usr дяла. Бях твърде мързелив, че се пробвам да го фиксна, така или иначе всичко беше само с научна цел няма как продуктов сървър да го надграждам към момента. Хванах преинсталирах си виртуалката като този път всичко си го набутах в 1 дял. Също си взех поука, никакви ъпдейти никакви допълнителни сървъси, след инсталацията директен ъпгрейд. На финалната стъпка отново изскочи досаният диалог който ми каза, че имам доста High проблеми – невалидни пакети, конфизи и прочие но може да продължи. Знаех си че по начало не ги правят както трябва нещата. Рестартирах отново и зачаках – о какво чудо ъпгрейда приключи успешно. И всичко работеше или поне зареждането на системата така и не пробвах да инсталирам допълнителни пакети, но halt командата си зависваше – хух все пак трябваше да има бъг 💡 . След тая цялата тарапана реших да инсталирам на чисто Centos 7 да видим дали ще ръмжи за /boot дял в LVM – 6.5 не позволява такава дързост. Стартирах си ISO-то и бях меко казано шокиран от инсталатора – всичко беше крайно не удобно „подредено“, напълно алогично с цел да е красиво. След известна борба успях със заветната цел и аха да се инсталира и гръмна, че трябва да си изнеса /boot-а извън LVM-a 👿 Това е крайно не сериозно и досадно, ако поради някаква причина забравиш да си увеличиш размера на boot дяла от 200МБ и понатрупаш стари ядра какво се случва.
В общи линии нищо не очаквах и пак съм разочарован от CentOS.
Колкото и да псувам RHEL и CentOS shit-а има някой неща които са им измислени доста грамотно. Например добавянето на голям брой допълнителни IP-та е доста приятна задачка. По принцип ако трябва да добавя голям брой адреси бих си разписал едно bash скриптче в което в цикъл да извършва въпросната операция че на ръка не си е работа. При Centos/RHEL хората са го измислили доста приятно range файл. В общи линии създаваме файл /etc/sysconfig/network-scripts/ifcfg-eth0-range0. Тук заменяме eth0 със името мрежовият адаптер ако не е eth0. След което добавяме следното съдържание
В Centos-а е малко интересен в сетъпа на bridge адаптери. Приемам че вече е инсталиран bridge-utils пакета и eth0 (в това е в моя пример) е конфигуриран, така че нека да разгледаме основните стъпки
Копираме настройките на eth0 в br0 (тук вече ако ви трябват друго именуване на адаптерите си го коригирате)
Занествате записите за eth0 в конфигурационният файл на br0
замествате типа на адаптера от Ethernet на Bridge
Махате MAC адреса от br0 конфигурацията
Задавате в eth0 конфигурацията че ще се имаме мостов адаптер br0
За да спестя време си го разписах като елементарно bash скриптче
cd /etc/sysconfig/network-scripts/
cp ifcfg-eth0 ifcfg-br0
sed -i 's/eth0/br0/' ifcfg-br0
sed -i 's/Ethernet/Bridge/' ifcfg-br0
sed -i '/HWADDR/d' ifcfg-br0
echo 'BRIDGE="br0"' >> ifcfg-eth0