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 ·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

by ·0 Comments

Най- накрая успях да завърша работата си по скрипта които пиша толкова време 🙂 Вече NUKI е един доста стабилен скрипт. Подчертавам 1 защото премахнах допълнителния скрипт като го вградих в основния. Вече придоби монолитна структура, но лично според мен е по добре за демон вариант 🙂 Вече подобренията не са много, по скоро са фиксове на разни ситни бъгове и опити за подобряване на кода. Единственото осезаемо нещо което съм добавил е проверка за uptime-а на приемника. Нагласил съм го на всеки 10 дни да си прави рестарт сам.

Като погледна назад и първоначалната ми идея за скрипт които просто да следи приемниците какво се случава с тях мисля, че доволно добре съм реализирал идеята си много кратно. Единствения бъг които се надявам да избегна с 10 дневния рестарт е – има моменти в които приемника започва да се рестартира, но не успява. Избива повечето сервизи включително и мрежовия но неуспява да достигне до рестарт. За съжаление поради ограниченията наложени ми от боксовете неможях да направя рестарта да е от ядрото и по този начин да избегна и този момент. Може би някои ден за в бъдеще ще си компилирам мои си image за боксовете и по този начин ще успея да се справя с този проблем. Засега се надявма последното ми е решение да го замаже 🙂 Иначе всичко останало се получи изключително добре, дори много по добре от първоначалния ми замисъл. Особено при положение, че преимана през толкова метаморфози. Най бъгавата част си остана web интерфеиса, затова продължавам да не го давам 😆 след като седна да го пренапиша тия дни ще го кача и него за свободна консумация. Финални думи – вместо да протаквам просто искам да благодаря на всичките ми приятели, че търпяха глупавите ми въпроси за това и онова – имате важен принос в деизаина на кода. Признателност заслужава и човека на които е кръстен проекта и ми е служил като вдъхновение в повечето моменти на бездарно писане 🙂 … Дам заслужаваш го!

by ·0 Comments

Днес поработих малко над новата NUKI верси. Най накрая докарах ред и до нея, а ми се ще да я пооправя малко преди  да пусна последната стабилна, вероятно и финална версия. Та имах идеята да проверявам колко дни е uptime на приемник,  че повечето ми правят проблеми след като са били повечко време, затова реших да правя през 10 дни един прфилактичен рестарт. Набързо драснах конвеирче дето да ми изчиства дните от останалите променливи защото резултата откомандата uptime е доста неприятен за работа

# uptime
12:13:57 up 30 days, 20:07,  1 user,  load average: 0.00, 0.00, 0.00

Та въпросни ред се филтрира само от суперския конвеир 😛

uptime | awk -F'up' '{ print $2 }' | awk -F'days' '{ print $1 }'

Като ако работното време е дни резултат е цяло число с дните, а ако е часове резулататът е подобен на

neo2shyalien@neo2shyalien-box:~$ uptime | awk -F'up' '{ print $2 }' | awk -F'days' '{ print $1 }'
1:34,  5 users,  load average: 0.46, 0.39, 0.41
neo2shyalien@neo2shyalien-box:~$

Заради Което минава през проверка за вида на стойноста

if echo $days | grep "^[0-9]*$" > /tmp/null
then
   echo "Uptime in days is $days"
else
  echo "Uptime isnt in days"
fi

Просто лесно и ясно в if-а конструкцията проверява дали стоиснота съдържа само цифри с регулярни израз grep „^[0-9]*$“.

by ·0 Comments

Еее доживяхме го има NUKI 1.0 🙂 Защо от версия 0.6 скочих на 1.0 ще ме попитате ами много просто – вече имаме едно 100% универсално NUKI покриващо всички изисквания, с малки изключения кото ще фиксна за в бъдеще и по важното настоящата версия е реализирана по коренно различен начин. Върнах се към старата ми идея да е демон и с малко проби и грешки този път нещата сработиха отлично. Сървърното приложение е изкормено изцяло като изключим едно кратки php скриптче от което черпи информация NUKI-то 🙂

Е вече постигнах почти всичко с NUKI накъде повече? Ами ко трябва да съм честен винаги може и повече, например обмислям да направя инсталатор на самия скрипт да речем да направя нещата някак си по лесни и разбираеми дори и за не линукс потребител всичко да се случва с възможно най- малко проблеми за потребителя. Но за всичко си има време. Към момента в NUKI освен всичко друго съм добаваил модул които следи за връзка към сървъра, ако изчезне самия приемник се рестартира. За момента все още несъм установил дали работи хихихиихх 😆 Абе като цяло вианги ще има какво да се желае още или някоя свежа идея от някои все пак една глава неможе да мисли като 2-3-4 или повече, дори и моята 😈

ps Отново пускам с кодово име. Смятам че вече имам една изключително твърда основа за всичко което реша за в бъдеще да правя със скрипта ми