by ·0 Comments

Около половин година след последния ми анонс по Dreambox monitoring ситестемата ми мога да анонсирам новата и вероятно някоя от последните си версии на Nuki. Версията беше готова още преди  2 месеца но къде от мързел къде заради дебъгване нещата се позабавиха с анонса. От няколко дни работи на 32 dreambox 500-s и общо взето резултатите са много добри. Промените са много – премахната е идиотската звисимост от Linux server на които да се прехвърлят логовете – вече е необходимо да имате 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. Все още има какво да се подобри но засега мисля да се въздържам от таквиа неща защото не е наложително 🙂

Файловете както обикновено се намират в директорията  а крипта за въвеждане на логовете може да свалите от тук

И по случай добрия скрипт едно ускорено парче за всички ускорители 😀

Enhanced by Zemanta

by ·2 Comments
Tux, as originally drawn by Larry Ewing

Image via Wikipedia

Днес мисля малко да по размишлявам върху това извращение на природата CentOS. Вдъхновен от наскоро излязлата CentOS 6-та версия имам какво и аз да кажа. Само по себе си тая глупост е разработка RedHat и е сървърен форк на тяхната Red Had Enterprise Linux. Използва rpm пакетния им менаджер (които е ужасно велик, да ама не).

Нека да започна с това което ме накара да започна да пиша и да размишлявам що за изрод е това CentOS и има ли почва в моите сървъри. Преди около седмица излезе верися 6 и реших да ъпдейтна настоящата ми 5.6 инсталация на VPS хостинга ни. Бях доста неприятно изненадан като видях, че не ми отчете пакети ъпдейт. Реших, че нещо аз бъркам и проверих в Интернет. Бях шокиран като видях препоръката на производителя е да се прави чиста инсталация и дистрибутививен ъпгрейд от 5.6 не е препоръчителен и се прави с кила черни магии и затова не е възможно по стандартен начин. Хммм доста интересен момент. 😆 И това се води enterprise дистрибуция, много интересно. Не виждам как може дори да се класира в тази категория освен, че производителя и сложил това гръмко наименование. Да приемем следните 2 сценария – единия е правим нов инстал другия е не правим.

1. Сценарии – Свалям сървъра разкачам го спира всички услуги които поддържа. Инсталирам го за 1 час или повече бизнеса за които работя търпи големи загуби като парички. Аз си губя работата като системен админснитратор вероятно или ще отнеса солени глоби. Да не коментираме всички мъки покрай настройките и правилния архив на данни и настройки. Кила нерви резулатта е имаме чиста система. Очевидно варианта не е приемлив.

2. Сценарии – Не правим дистрибутивен ъпгрейд системата си седи така докато се пускат кръпки по сигурноста. Докато в един момент не и се прекрати подръжката след известно време бива хакната заради пробойна в някоя от услугите които предлага, заради невъзможноста да си да осигурява диструбутивно надграждане. Крадат се данни или просто само се компроментира сървъра – отновно солени глоби или си губиш работата.

Доста интересно и двата сценария завършват доста неприятно за системния им администратор заради капитална греша в дизайна на дистрибуцията подбора и  мързела на компанията която я разработва за да не осигури съвместимост между пакетите. Докато от друга страна има не чак толкова enterprise дистрибуции които се надграждат тихо и кротко, без да носят гръмки имена. Имам Debian сървър които е от версия 3 надграден до актуаланта версия 6 в момента сиреч преживял е 3 големи надграждания като не е имало отказ до достъпа на услугите. По принцип единия от основните принцип на админа е – „Ако работи не се пипа“ но затова хората откриват дупки пускат кръпки затова излизат нови пакети да подобряват стабилността или да ускоряват производителността. В заключение освен мое лично мнение но и мнение на много мои приятели къде по добри админи от мен е CenOS не струва.

Related articles
Enhanced by Zemanta

by ·2 Comments

Мале как ги мразя тия пичове от Mysql 😆 Днес си направих обновлението от mysql 5.1 до 5.5 версия и отново сървъра не запали, a в mysql log-а всичко умираше чисто и просто с:

110527  9:27:38 [ERROR] Unknown/unsupported storage engine: InnoDB
110527  9:27:38 [ERROR] Aborting

Хах се сети какво става 😀 След като почнах да забранявам настройки по my.cfg нещата палнаха чак след като забраних

skip-innodb

Луда работа 🙂 Без тази опция в конфигурацията всичко си работеше както хората, обаче това положение не ме устройваше, защото innodb не се ползва на тоя сървър и няма нужда да заема излишна памет, която така или иначе е оскъдна. След известно ровене открих проблема и съответното му решение. Ако не е зададена default storage engine сървъра няма да опознае командата и съответно няма да се стартира 😯 . Чини ми се че леко вече прекалиха в предишния си ъпгрейд от 5.0 към 5.1 нещата пак бяха с драми поне 10 от параметрите в my.cfg бяха с различни имена и поне 5 бяха драматично изрязани и не поддържани. Тоя път само един проблем 😀 Решението на проблема очевидно е задаване на default storage engine, което става с следната команда

default-storage-engine=MyISAM

От тук нататък всичко си работеше по старо му.

by ·3 Comments

Преди да започна с глупостите искам да кажа, че не съм много напред с 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 Песничката леко се връзва с тематиката 😀

by ·0 Comments

От близо година не бях работил по демочето ми NUKI. Днес ми остана време да пооправя нещата защото имаше доста неща които не си бяха съвсем добре. Добавих малко нова функционалност. Пренаредих кода, с повече функции така го скъсих и стана по прегледен.

Основната нова функционалност която вкарах е signal trap-а. В някои момент както си върти демона dreambox приемника решава да го убие и по този начин спиря мониторинг процеса ми, което само по себе си е доста неприятен момент. А няма как да разбера какво се случва тъй като мястото за логове е безбожно малко и трябва да правя правя сложни схеми с мрежови споделяния с които не ми се занимава. В обши линии signal trap-a е приятното свойство на bash скриптовете да прихващат сигнали от изходи или такива подадени им от kernel-a чрез kill да речем 😉 и по този начин можем да предотвратим някои от незабавно последващите събития. Само да вмъкна че SIGKIL или kill -9 не може да бъде прехванат и предотвратен, така е по дизайн в ядрото. То терминира директно подадения му PID. Сега и съответния код


#trapping signals I know -9 dosent work but we try it just in case ; )
trap on_exit 0 14 1 2 9 13 15 6 8 4 3 11 5
on_exit () {
make_debug 10 #unexpected error
#reboot now if we hawe trapped signal
reboot -d 0
exit 0
}

Първия ред ни декларира какво действие да се предприеме и при кои сигнали ще прихващаме повече за сигналите man signals 😉 В случая мен тези ме интересуват. Както се вижда водят до една проста функциика която прави дебъг съобщение и рестартира приемника. Несъм обеден, че ще доведе до резултата които очаквам, понеже мисля че всичко което пречи е избива с kill -9 но нищо не пречи да се пробва.

Другите кардинални промени са функциите повечето неща които се повтарят от кода ги наблъсках в функции, че беше малко неприятен за гледане не, че сега е де 😉 Имах една лека драма с return в bash-а – сложих си return в една функция и очаквам поведение като всички други познати ми езици за програмиране, но се оказа че return връща само integer стойности и то максимум 2 😀 а аз исках да ми върне string. Настана една грозна свинщина. Решението на проблема е елементарно


#---cuted---

if [ $T -eq $N ]
 then
 echo "Cam is down! Reboot..."
make_debug 4 # cam is down
 else
echo $rcam
 fi

# ---cuted----

#finding real cam1
 rcam1=$(find_cam $cam1)

Първата част е края на функцията ми и чрез echo изплювам резултата.  Взимането му е елементарно с последния ред в горния пасаж.

Хммм мисля, че това е интересната част от кода.

Искам да изкажа благодарност на вдъхновението 😉

http://www.youtube.com/watch?v=SilMJ0O13UI&feature=related