Cpanel large error_log files

0

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

Increase maldet speed

0

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

CentOS докога

0

Преди да почна с поредният 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.

Добавяне на множесто IP-та в CentOS

0

Колкото и да псувам RHEL и CentOS shit-а има някой неща които са им измислени доста грамотно. Например добавянето на голям брой допълнителни IP-та е доста приятна задачка. По принцип ако трябва да добавя голям брой адреси бих си разписал едно bash скриптче в което в цикъл да извършва въпросната операция че на ръка не си е работа. При Centos/RHEL хората са го измислили доста приятно range файл. В общи линии създаваме файл /etc/sysconfig/network-scripts/ifcfg-eth0-range0. Тук заменяме eth0 със името мрежовият адаптер ако не е eth0. След което добавяме следното съдържание

IPADDR_START=192.168.0.129
IPADDR_END=192.168.0.254
NETMASK=255.255.255.128
CLONENUM_START=0

като аргументите са

  • IPADDR_STARTначален IP адрес
  • IPADDR_ENDкраен адрес
  • NETMASKмрежова маска
  • CLONENUM_STARTномерация от която да започнат мрежовите адаптер eth0:0 в нашият случай

 

CentOS bridge setup

0

В Centos-а е малко интересен в сетъпа на bridge адаптери. Приемам че вече е инсталиран bridge-utils пакета и eth0 (в това е в моя пример) е конфигуриран, така че нека да разгледаме основните стъпки

  1. Копираме настройките на eth0 в br0 (тук вече ако ви трябват друго именуване на адаптерите си го коригирате)
  2. Занествате записите за eth0 в конфигурационният файл на br0
  3. замествате типа на адаптера от Ethernet на Bridge
  4. Махате MAC адреса от br0 конфигурацията
  5. Задавате в 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

Go to Top