About half a year after my last announcement on Dreambox monitoring system I can announce the new and probably one of my latest versions of Nuki. The version was ready before 2 months but out of laziness where due to debugging things were delayed with the announcement. Has been working on for several days 32 dreambox 500-s and overall the results are very good. The changes are many – the idiotic dependence on Linux server to which to transfer the logs – you already need to have apache + php, because the new system for writing logs is by passing parameters to a php script on the server. I have separately changed the script to work without a server part – if you have a few satellite receivers, it doesn't make sense to have a server running from which to get the info, so you can put the hardcode in the script with 2 variables CAM information. I also declared an additional variable for debug – if you don't want it I won't throw logs at you – again a stupid omission compared to before 🙂 Slight corrections to the code were made, that it looked like it was written by a semi-literate oligophrenic (not that I'm not). They were away from us 2 critical code errors leading to the script crashing at some random moment, again oligophrenic omissions on my part. In general, writing was not very simple, you had to think about doing it like people, that busybox and ash are not the easiest things to tame. This time I think to save the big tirade with the code and directly explain the variables what it is for and what manipulations can be done with it (the new ones) 🙂

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 '[email protected]:@@')
 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

So obviously the names of the variables speak for themselves enough, but still I have to say some clever words..

STANDALONE is one of the most important variables if it is set to TRUE no calls to the server will be made and will no longer require server dependency if you use it you have to put values ​​on the following HCAM1 (I don't know why I named her that way, I don't remember anymore, but it doesn't matter). If there is no value in it and the script is independent, the script assumes that it will work on an unencrypted channel and does not check for a decryption module., if there is it will check according to the set value. HCAM2 is optional if your decoder module only uses 1 process let's say CCcam for example.

DEBUGING the second interesting variable will give you information or keep silent depending on what value you have scored. Automatically switches to quiet mode if STANDALONE е TRUE

NEWDBGSTYLE waste is an important variable. It determines how the logs will be transferred to the server. If it is TRUE it will be in the new way without the idiotic dependence on netcat. If you still stick to the old method, put FALSE. Basically, these are the things you need to emphasize, but I think, that the changes, although cardinal, will remain an idea transparent because of the default values ​​🙂

I am definitely already very happy with how things turned out – the script became flexible enough idiots departed dependence on additional files for functions as well as already departed and dependence on nc I think or the need for a server and so on not everyone uses 30+ the box to have a server or it can only have some kind of home router. There is still something to improve but for now I think I should refrain from such things because it is not necessary 🙂

The files are usually found in directory and the crypto for entering logs can be downloaded from here

And in the case of a good script, one accelerated track for all accelerators 😀

Enhanced by Zemanta

I hadn't worked on my demo for almost a year NUKI. Today I have time to fix things because there were a lot of things that were not quite good. I added some new functionality. I rearranged the code, with more features so I shortened it and it became clearer.

The main new functionality I introduced is the signal trap. At some point as the demon rotates the dreambox the receiver decides to kill it and thus stops monitoring my process, which in itself is a rather unpleasant moment. And I can't figure out what's going on because the space for logs is ungodly small and I have to make complex schemes with network sharing that I don't care about.. In general, the signal trap is a nice feature of bash scripts to intercept signals from outputs or those sent to them by the kernel via kill say 😉 and thus we can prevent some of the immediate subsequent events. Just insert that SIGKIL or kill -9 it cannot be intercepted and prevented, so is the design in the kernel. It terminates the PID submitted to it directly. Now the corresponding code

#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
}

The first line tells us what action to take and at which signals we will intercept more for the signals. man signals 😉 In this case, I am interested in these. As you can see, they lead to a simple function that debugs a message and restarts the receiver. I'm not having lunch, that will lead to the result I expect, because I think all that interferes is killing with kill -9 but nothing prevents it from being tried.

The other drastic changes are the features most things that are repeated by the code I pushed them into functions, that was a little awkward to watch no, that is now de 😉 I had a slight drama with return in bash – I put my return in one function and expect behavior like all other programming languages ​​I know, but it turned out that return returns only integer values ​​and that maximum 2 😀 and I wanted to return my string. There was an ugly pig. The solution to the problem is simple

#---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)

The first part is the end of my function and through echo I spit out the result. Taking it is elementary with the last line in the upper passage.

Hmmm I think, that this is the interesting part of the code.

I want to thank her for her inspiration

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

The most- I finally managed to finish my work on the script I've been writing for so long 🙂 Already NUKI is one quite a stable script. I emphasize 1 because I removed the additional script by embedding it in the main one. It has already acquired a monolithic structure, but personally I think it's better for a demon option 🙂 There aren't many improvements anymore, rather, they are fixes for various minor bugs and attempts to improve the code. The only noticeable thing I've added is a check on the receiver's uptime. I have set it for everyone 10 days to restart alone.

Looking back and my original idea for a script that just tracks the receivers what happens to them I think, that I have quite well realized my idea many times. The only glitch I hope to avoid with 10 the daily restart is – there are times when the receiver starts to reboot, but fails. It kills most services, including the network one, but fails to restart. Unfortunately, due to the restrictions imposed on me by the boxes, I could not make the restart be from the kernel and thus avoid this moment.. Maybe some day in the future I will compile my image for the boxes and thus I will be able to deal with this problem.. For now, I hope my last decision is to blur it 🙂 Otherwise, everything else turned out extremely well, even much better than I originally intended. Especially in a situation, that imitated through so many metamorphoses. The most buggy part remained the web interface, so I still don't give it 😆 after I sit down to rewrite it these days I'll upload it for free consumption. Final words – instead of procrastinating I just want to thank all my friends, that they tolerated my stupid questions about this and that – you have an important contribution to the code design. The person to whom the project is named deserves gratitude and served as an inspiration for me in most moments of incompetent writing 🙂 … I deserve it!

Today I worked a little on the new NUKI versions. Finally, I brought order to her, and I want to fix it just before I release the last stable one, probably the final version. So I had the idea to check how many days is uptime on the receiver, that most of me have problems after being around for a long time, so I decided to do through 10 days a prophylactic restart. I quickly drew a conveyor to clear my days of other variables because the result of the uptime command is quite unpleasant to work with.

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

So the order in question is filtered only by the super conveyor 😛

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

As if working hours are days the result is an integer with days, and if it is hours the result is similar to

[email protected]:~$ uptime | awk -F'up' '{ print $2 }' | awk -F'days' '{ print $1 }'
1:34,  5 users,  load average: 0.46, 0.39, 0.41
[email protected]:~$

Because of which goes through a check for the type of value

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

Simply easily and clearly in the if the construction checks whether the value contains only digits with a regular expression grep “^[0-9]*$”.

Ehh, let's just say I've seen better NUKI 1.0 🙂 Why from version 0.6 I jumped on 1.0 you will ask me very simply – we already have one 100% universal NUKI covering all requirements, with a few exceptions which will be fixed for the future and more importantly the current version is implemented in a radically different way. I went back to my old idea of ​​being a demon and with a little trial and error this time things worked great. The server application is completely gutted, except for a short php script from which the NUKI draws information 🙂

Well I have already achieved almost everything with NUKI far more? Well, if I have to be honest, I can always do more, for example, I'm considering making an installer of the script itself, let's say to make things somehow easier and more understandable, even for a non-Linux user, everything should happen with the most- little problems for the user. But there is time for everything. At the moment in NUKI, among other things, I have added a module that monitors the connection to the server, if the receiver itself disappears, it restarts. At the moment I have not yet established whether it works hihihihihh 😆 Abe in general viangi will have something to wish for more or some fresh idea from some still a chapter can not think like 2-3-4 or more, even mine 😈

ps I play again with a code name. I think I already have an extremely solid foundation for everything I decide to do with my script in the future