Измина доста време от както писах за последно но съм ужасно зает с новата ми работа, все още не съм се устроил и не съм си пуснал Интернет на новото ми място. Отделно, че хостинга където се помещаваше малкия ми блог го сполетяха доста хардуерни неволи и имаше известен период в които не можеше да функционира поради невъзможността ми да имам физически достъп до машината. След дълго мислене взех решение да прехвърля блогчето ми на публичен web сървър, решение което изискваше много мислене и не особено лесно приемане. Все пак съм преди всичко системен администратор и това удря по гордостта ми много, но към момента нямам нито една подходяща машина на която да бъде хостнат сайта така, че преглъщам горчивия залък и продължавам напред. Като изключим този факт и факта че съм изключително лимитиран от възможност за манипулации по настройките на apache + php + mysql нещата не изглеждат чак толкова зле. Хората си правят редовни бекъпи имат си дизастър рековъри план имат си техническа помощ която може да помоля за помощ – както и се наложи за да импортират бекъпа на базата ми данни които е в скромния размер от около 1GB.  За сега има още няколко дребни настройки да се довършат но това ще е като имм нерви да се боря с тъпия cpanel 😆

Преди да започна с глупостите искам да кажа, че не съм много напред с web hosting-а и всичко което ще напиша е опит които съм придобил в последните 2-3 месеца. Администрирам едни доста натоварен VPS по посещаемост според tyxo е в топ 80 но влиза в топ 70 ;). Та мисълта ми е, че вече след толкова време придобих разни навици и достигнах до добрите практики по един или друг начин (обикновено по трудния) :D. Няма да пиша или да навлизам в детайли на конфигурацията никак даже. По скоро ще споделя идеите над които да помислите.

  1. Обновявайте софтуера редовно. Apache, php mysql всичко си иска обновления. Дали за да закърпите дупки в сигурниста, дали заради поправени бъгове или нови възможности. Винаги дръжте софтуера си в крак с времето. По принцип рядко се пробива един сървър през апликациите обикновено през дупки в кода на хостваните неща се пробива ама да не разчитаме само на това.
  2. Apache – web server-а ви не е желателно да има активни повече модули от тези които реално ползвате. Колкото повече модули по- бавна работа.
  3. Повече потребители на същия сървър – opcode cache. Преди време писах пък и zerdion направи доволно тестове и се вижда реално ползата от тая магия. В моя случай съм избрал eAccelerator защото в реална работна среда той показва най добри резултати с пуснати всички настройки към него. По бързо зареждане по малко ядене на ресурси което респективно означава повече потребители.
  4. Притискат ви с трафика – gzip. Най лесния начин да намалите реални трафик които правите е с gzip компресия на http отговорите към клиента. Mod deflate е решението за apache. За други http server-и не съм проучвал въпроса :). Реално около 50% ми падна трафика при компресия върху html,css,js,xml. Трябва да проверя дали мога да компресирам и друг вид съдържание ще е интересно. Защото реално снимките са съдържанието което прави най много трафик в един сайт.
  5. mysql serer – горещо ви препоръчвам ако не сте се наградили с версия 5.1 да го направите. Като цяло Oracle имат някакъв малък опит с бази данни 😆 и тоя опит са го вкарали добре в 5.1 версията не съм пробвал 5.5 но и това планувам да стане скоро.  Определено се ускори работата на sql заявките може би леко падна натоварването но с не повече от 5-6% но a пък и новите функционалности за програмистите са прекрасни. Основаната такава partitions. При надграждане внимавайте какви настройки имате в my.cfg Не всички стари опции са валидни, също е добре да махнете старите библиотеки поне при CentOS 5.5 направиха проблеми при Debian нямах такива ядове. След това си вижте mysql log-а защото някои от опциите са с различни имена и е добре да ги промените ако след време минете към 5.5 да не се чудите защо не палва конфигурацията ви.
  6. sql заявките.  Задължително разрешете опцията за записване на slow query. По тези дневници можете да върнете информация на програмистите ако не сте вие за бавните заявки да се оптимизират. Колкото по малко такива заявки по малко натоварване за сървъра ви 😉
  7. Малко защита – сменете подразбиращия се порт на ssh-а ви няма нужда смотани ботове да се опитват да ви хакват. Apache го подсигурете с mod_security доста полезен модул прави филтрация на доста шитни – sql inj, rfi DDoS и прочие. Няма да спре голям хахор ама поне ламерите ще ги отсее. PHP е добра идея да се защити с Suhosin. Може да се сложи като допълнително разширение или направо като пач в php кода. Аз лично предпочитам първия по изчистен ми се струва.

Като за начало това са нещата които се сещам. Не са много а като се замисля съм направил доста оптимизации по сървъра но много от тях са доста специфични според ситуацията и няма смисъл да ги обяснявам тях като например лимитации на кешове или пък колко процеса има вдигнато apache-то. Вероятно с времето ще се сещам и за още неща които са как да кажа част от малките неща които дават големия резултат. Машината е доста добре оптимизирана за сравнение ние правим на 20к уникални посещения на ден и сме на най ниския възможен vps план load time на страниците ние не надхвърля 1,5-2 сек или ако го надхвърля е заради външните източници на реклами иначе самата страница се изплюва за части от секундата. Хора с близки позиции до нас са с не оптимизирани сървъри с доста повече ресурси от нашия и имат същите резултати. Общо взето оптимизиране му е майката и пиенето на бира бащата 😆

ps Песничката леко се връзва с тематиката 😀

eAccelerator е един прекрасен механизъм да по забързаме бавното php. Общо взето идеята е елементарна  😆 при изпълнение на php скриптове тая щуротия ги пази до opcode ниво и при следващо извикване ако няма промени пo скрипта се ползва opcode копието. Резултата е по бързо изпълнение по ниско натоварване на сървъра, по малко разхищение на ресурси. Общо взето това е.

Сега да споделя простотията която успях да сътворя. Преди малко по малко от седмица на един сървър обновявах php версията която ползва заради фаталният CVE-2010-4645 бъг. Поднових версията до 5.2.17 където видях, че е поправен. Не ми се рискуваше с 5.3.5 версията, че има разлики и не знам кое как ще сработи , а и най важното беше късно вечерта. Речено сторено. Ъпдейта мина повече от гладко, но след като приключих ми направи впечатление че пъргавостта на сайта падна доста. Но единия от разработчиците ме беше предупредил, че ще тестват нови скриптове и не му обърнах много внимание. Вчера ми се наложи да настройвам едни cron-ове на php и когато ги пуснах видях един доста неприятен надпис, че компилацията ми на eAccelerator-a е за старта версия на php-то ми и с новата не работи ;). Ясно вече всичко е ясно. Набързо прекомпилирах eAccelerator-a и всичко си дойде на мястото по груби наблюдения зареждането на страниците падна двойно като се освободиха ценни мегабайти рам. Като цяло вече поне си направих теста и със сигурност има полза особено при над 200 потребителя online нещата стават доста красноречиви а при 400 😉 Има и други механизми но според тестовете eAccelerator-a е най грамотния избор. Нямам особено време за тестване затова се доверявам на хората 😀

http://www.youtube.com/watch?v=eJarZiMQaKA

malmon е един изключително интересен нов проект – като цяло е замислен за защита на хостинги сървъри от зловреден софтуер на него, създаден от моя приятел и linux guru ShadowX. Да поясня какво точно се има на предвид – нищо не пречи да си метнете на кои хостинг едно приятно c99 шелче да речем и ако е не достъчно добре настроена файловата система нищо не пречи на злия хахор да докопа шел достъп. Като цяло идеята на malmon е точно така да следи качването на такива приятни мизерии и да ги премества в карантинна директория различна от document root-a. Принципа на които работи е доста приятен – следи за създадени нови фаилове в папка която е настроен да гледа софтуера и при наличие на някои фаил кото съвпада с определени сигнатури го препраща към вечните ловни полета. Нещо като антивирусен софтуер 😉 Скрипта е написан на python което го прави лек, бърз и гъвкав. За да следи за създадени нови файлове използва относително новия механизъм на ядрото inotify. Въпреки че все още скрипта не е официално стабилна версия от 3 дни не съм имал проблеми на един порядъчно натоварен сървър – единия от сайтовете там е в топ 100 на tyxo 😉

Мога да продължа да наливам сухи статистики и обяснения на дълбоко как работи кода, но няма да го направя. По скоро ще ви призова да го сваляте тествате и ако имате предложения да пишете на автора 😉 Ако видите бъгове пак му пишете хора сме грешим и е добре да се подкрепяме. Наздраве!

Преди няколко дни имах ужасен проблем с инсталиран ModSecurity и phpMyAdmin. Общо взето проблема се коренеше в това че, защитния модул възприемаше рекуестовете на phpMyadmin-a като sql injection атаки. Решението отново е тривиално просто за файловете на phpmyadmin-a изключвам мачването на правилата. Правилата ги записах в modsecurity.d/modsecurity_localrules.conf които се намира в папката на apache сървъра ви. Ето ги и самите правила.

<LocationMatch „/phpmyadmin/tbl_change.php“>
SecRuleEngine Off
</LocationMatch>

<LocationMatch „/phpmyadmin/sql.php“>
SecRuleEngine Off
</LocationMatch>

<LocationMatch „/phpmyadmin/managecontent.php“>
SecRuleEngine Off
</LocationMatch>

<LocationMatch „/phpmyadmin/import.php“>
SecRuleEngine Off
</LocationMatch>

<LocationMatch „/phpmyadmin/tbl_select.php“>
SecRuleEngine Off
</LocationMatch>

<LocationMatch „/phpmyadmin/tbl_replace.php“>
SecRuleEngine Off
</LocationMatch>