За единия проект които водя в gitweb ме дразнеше, че няма оцветяване на кода в дървото. Лесен начин как да оцветите синтаксиса в tree частта на gitweb е като инсталирате пакета highlight и добавите следния ред в /etc/gitweb.conf или където ви се намира конфигурационния файл на gitweb
$feature{‘highlight’}{‘default’} = [1];
За Debian пакета го има в пакетната система за другите дистрибуции не съм проверявал.
ps Има и алтернативен вариант като се правят промени по файловете на gitweb ама ми се стори безсмислено като има простичък вариант 🙂
Измина доста време от както писах за последно но съм ужасно зает с новата ми работа, все още не съм се устроил и не съм си пуснал Интернет на новото ми място. Отделно, че хостинга където се помещаваше малкия ми блог го сполетяха доста хардуерни неволи и имаше известен период в които не можеше да функционира поради невъзможността ми да имам физически достъп до машината. След дълго мислене взех решение да прехвърля блогчето ми на публичен web сървър, решение което изискваше много мислене и не особено лесно приемане. Все пак съм преди всичко системен администратор и това удря по гордостта ми много, но към момента нямам нито една подходяща машина на която да бъде хостнат сайта така, че преглъщам горчивия залък и продължавам напред. Като изключим този факт и факта че съм изключително лимитиран от възможност за манипулации по настройките на apache + php + mysql нещата не изглеждат чак толкова зле. Хората си правят редовни бекъпи имат си дизастър рековъри план имат си техническа помощ която може да помоля за помощ – както и се наложи за да импортират бекъпа на базата ми данни които е в скромния размер от около 1GB. За сега има още няколко дребни настройки да се довършат но това ще е като имм нерви да се боря с тъпия cpanel 😆
Около половин година след последния ми анонс по Dreambox monitoring ситестемата ми мога да анонсирам новата и вероятно някоя от последните си версии на Nuki. Версията беше готова още преди 2 месеца но къде от мързел къде заради дебъгване нещата се позабавиха с анонса. От няколко дни работи на 32 dreambox 500-s и общо взето резултатите са много добри. Промените са много – премахната е идиотската звисимост от Linuxserver на които да се прехвърлят логовете – вече е необходимо да имате apache + php, защото новата система за писане на логове е като се подава параметри към един php скрипт на сървъра. Отделно съм променил скрипта да работи и без сървърна част – ако имате малко сателитни приемници не е смислено да имате постоянно пуснат сървър от които да се взима инфото затова може да се нанесе хардкоднато в скрипта с 2 променливи информацията за CAM-а. Също така съм декларирал допълнителна променлива за debug – ако не искате няма да ви мята логове – отново малоумен пропуск в сравнение с преди 🙂 Леки поправики по кода бяха напревени, че приличаше като писан от полуграмотен олигофрен (не че несъм де). Остране ни бяха 2 критични грешки в кода водещи до прекратяване на работа на скрипта в някакъв случаен момент, отново олигофренски пропуски от моя страна. Общо взето писането не беше много просто трябваше да се помисли да се направи като хората, че busybox и ash не са най лесни неща за опитомяване. Тоя път мисля да спестя голямата тирада с кода и направо да обясня променливите коя за какво е и какви манипулации могат да се направят с нея (новите) 🙂
SERVER="192.168.100.1"
STANDALONE="FALSE" #using like stand alone app no server side depends ; )
HCAM1="" ## if starting like stand alone app give me CAM namezzz if HCAM1 is empty its means chanel is free
HCAM2="" ## CAM2 name
PORT="666" # port rockzzz : D : )))))))))))))))))
IP=$(ifconfig eth0 | grep inet | awk '{print $2}' | sed -e 's@addr:@@')
FILE='/tmp/debug'
INFO='/tmp/info_file'
NC=$(which nc)
WGET=$(which wget)
MAX_DAYS="10"
TIMEOUT="600"
MAX=70 #max cpu usage per process
DEBUGING="TRUE" #if u wanna script send debug information set DEBUGING to TRUE if SEVERLESS is set to true this var will be skiped
NEWDBGSTYLE="TRUE" #debuging new style sending info to apache derectly, old style using nc
Така очевидно имената на променливити говорят сами за себе си достатъчно но все пак и аз да кажа някоя и друга умна дума.
STANDALONE е една от най важните променливи ако е сетната на TRUE няма да се правят обръщения към сървъра и няма да изисква вече зависимост от сървър ако я използвате трябва да сложите стойности и на следната HCAM1 (незнам защо съм я кръстил така не помня вече но няма и значение). Ако няма стоиност в нея а скритпа е самостоятелен скрипта приема че ще работи на некриптиран канал и няма прави проверка за декриптиращ модул, ако има ще провери според зададената стоиност. HCAM2 е незадължителна ако декодиращия ви модул използва само 1 процес да речем CCcam например.
DEBUGING втората интересна променлива ще ви прлюе информация или ще пази мълчание според зависи каква стойност сте забили. Авотматично преминава в тих режи ако STANDALONE е TRUE
NEWDBGSTYLE трата важна променлива. Тя определя как ще се прехвърлят логовете към сървъра. Ако е TRUE ще е по новия начин без идиостката зависимост от netcat. Ако все пак си държите на стария метод слагате FALSE. В общи линии това са нещата на които трябва да наблегнете но мисля, че промените въпреки че са кардинални ще останат една идея прозрачни заради зададените стойности по подразбиране 🙂
Определено вече съм много доволен как се получиха нещата – скрипта стана достатъчно гъвкав отпднаха идиотките зависимост на допълнителни файлове за функции както и вече отпдна и зависимост на nc мисля или пък нуждата от сървър и прочие не всеки ползва 30+ box-a че да има и сървър или пък може да има само някакъв домаше router. Все още има какво да се подобри но засега мисля да се въздържам от таквиа неща защото не е наложително 🙂
Файловете както обикновено се намират в директорията а крипта за въвеждане на логовете може да свалите от тук
И по случай добрия скрипт едно ускорено парче за всички ускорители 😀
Преди да започна с глупостите искам да кажа, че не съм много напред с web hosting-а и всичко което ще напиша е опит които съм придобил в последните 2-3 месеца. Администрирам едни доста натоварен VPS по посещаемост според tyxo е в топ 80 но влиза в топ 70 ;). Та мисълта ми е, че вече след толкова време придобих разни навици и достигнах до добрите практики по един или друг начин (обикновено по трудния) :D. Няма да пиша или да навлизам в детайли на конфигурацията никак даже. По скоро ще споделя идеите над които да помислите.
Обновявайте софтуера редовно. Apache, php mysql всичко си иска обновления. Дали за да закърпите дупки в сигурниста, дали заради поправени бъгове или нови възможности. Винаги дръжте софтуера си в крак с времето. По принцип рядко се пробива един сървър през апликациите обикновено през дупки в кода на хостваните неща се пробива ама да не разчитаме само на това.
Apache – web server-а ви не е желателно да има активни повече модули от тези които реално ползвате. Колкото повече модули по- бавна работа.
Повече потребители на същия сървър – opcode cache. Преди време писах пък и zerdion направи доволно тестове и се вижда реално ползата от тая магия. В моя случай съм избрал eAccelerator защото в реална работна среда той показва най добри резултати с пуснати всички настройки към него. По бързо зареждане по малко ядене на ресурси което респективно означава повече потребители.
Притискат ви с трафика – gzip. Най лесния начин да намалите реални трафик които правите е с gzip компресия на http отговорите към клиента. Mod deflate е решението за apache. За други http server-и не съм проучвал въпроса :). Реално около 50% ми падна трафика при компресия върху html,css,js,xml. Трябва да проверя дали мога да компресирам и друг вид съдържание ще е интересно. Защото реално снимките са съдържанието което прави най много трафик в един сайт.
mysql serer – горещо ви препоръчвам ако не сте се наградили с версия 5.1 да го направите. Като цяло Oracle имат някакъв малък опит с бази данни 😆 и тоя опит са го вкарали добре в 5.1 версията не съм пробвал 5.5 но и това планувам да стане скоро. Определено се ускори работата на sql заявките може би леко падна натоварването но с не повече от 5-6% но a пък и новите функционалности за програмистите са прекрасни. Основаната такава partitions. При надграждане внимавайте какви настройки имате в my.cfg Не всички стари опции са валидни, също е добре да махнете старите библиотеки поне при CentOS 5.5 направиха проблеми при Debian нямах такива ядове. След това си вижте mysql log-а защото някои от опциите са с различни имена и е добре да ги промените ако след време минете към 5.5 да не се чудите защо не палва конфигурацията ви.
sql заявките. Задължително разрешете опцията за записване на slow query. По тези дневници можете да върнете информация на програмистите ако не сте вие за бавните заявки да се оптимизират. Колкото по малко такива заявки по малко натоварване за сървъра ви 😉
Малко защита – сменете подразбиращия се порт на ssh-а ви няма нужда смотани ботове да се опитват да ви хакват. Apache го подсигурете с mod_security доста полезен модул прави филтрация на доста шитни – sql inj, rfi DDoS и прочие. Няма да спре голям хахор ама поне ламерите ще ги отсее. PHP е добра идея да се защити с Suhosin. Може да се сложи като допълнително разширение или направо като пач в php кода. Аз лично предпочитам първия по изчистен ми се струва.
Като за начало това са нещата които се сещам. Не са много а като се замисля съм направил доста оптимизации по сървъра но много от тях са доста специфични според ситуацията и няма смисъл да ги обяснявам тях като например лимитации на кешове или пък колко процеса има вдигнато apache-то. Вероятно с времето ще се сещам и за още неща които са как да кажа част от малките неща които дават големия резултат. Машината е доста добре оптимизирана за сравнение ние правим на 20к уникални посещения на ден и сме на най ниския възможен vps план load time на страниците ние не надхвърля 1,5-2 сек или ако го надхвърля е заради външните източници на реклами иначе самата страница се изплюва за части от секундата. Хора с близки позиции до нас са с не оптимизирани сървъри с доста повече ресурси от нашия и имат същите резултати. Общо взето оптимизиране му е майката и пиенето на бира бащата 😆
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 е най грамотния избор. Нямам особено време за тестване затова се доверявам на хората 😀
