A quick adaptation of Nebri’s straightforward blog post is to first shortlist rain related codes into 15 of them and changing from forecast to latest measurement instead. Bridging Nebri and my smartwatch are Twitter and IFTTT recipe–the watch merely mirrored my phone, you don’t need it actually. Why (again) Twitter? Well, rather than the “then that” side–the watch enabler, the “if this” side of IFTTT for Twitter recipes is quite powerful given so many tweet filtering options.

Key-value pairs as trigger for event driven Nebri OS workflow

Many things already taken care by Nebri, hence unseasoned programmer should easily cope with writing simple Python rule and focus on the automation, nevertheless complex rule should also be accommodated. I was having trouble on using previous KVP from different PID though–moved them to comment in the script, but they seem to be working on it. Check their YWeather blog post on how the basics work and compare what I did in Github. I embed an example tweet from @twithujan below. Yahoo! Weather frequency of measurement and accuracy are of different topic by the way.

Bogor is Light Rain with temperature at 23 °C. Taken at Thu, 28 May 2015 7:00 pm WIT

— Twit Hujan (@twithujan) May 28, 2015

PS: “hujan” means “rain” in Indonesian

If this than that recipes alert for Commuter Train trouble

The ingredient is tweet, Twitter Search use case is no longer just sentiment analysis, its function extends to alert, even close to real time–I’m pretty optimistic given the number of Commuter Line users joining the conversation. Now, the no-code part of our recipe, a Twitter search query, that is

(to:krlmania OR @krlmania OR from:CommuterLine)
AND (gangguan OR pantograf OR wesel OR patah)
-semoga -smoga -moga

and a brief explanation is that it queries for some keywords for potential trouble within mentions/replies to @krlmania and official announcements of @CommuterLine. Exclusion added to the search, the sentiment part of tweets, expressing wishes to shoo trouble away–I’m sorry, but keep praying online anyway.

When Twitter launched Twitter Stories in 2011, I read about Ravi Pina running the crowd sourced @Caltrain. Later now I see that official accounts like @SMRT_Singapore is also a model of service disruption info center. We can go deeper to better stats from the API web service that shows real time position (an app is out there showing that the location data API is working), but until its open data status is known, crowd sourcing stays as the most reliable solution, independent to regulation, and easiest to implement. Does the recipe work? During the first week of testing, alerts were flooding–within limit of course–as trouble really happened. So, cook your own ingredients or get my recipes served here.

Eltek Smartpack Controller rear view (type that comes with SNMP support)

It is presumably in its default configuration and I can snmpwalk through its corporate specific OIDs (under 12148 tree) to find i.e. output voltage, current, battery temperature, etc. Doing it without translating against the MIB will retrieve all the values perfectly fine. However, I want to show you a mistake in practice related to how the MIB is written and put to place, which is a version 4 by the name of ELTEK-DISTRIBUTED-PLANTV4-MIB. It has tabular part as clipped in the following tree (see previous post on how to write such part in your own MIB):

            |     +--eltek(12148)
            |        |
            |        +--eltekDistributedPlantV4(9)
...
            |           |
            |           |     |
            |           |     +--rectifierStatusTable(2)
            |           |        |
            |           |        +--rectifierStatusEntry(1)
            |           |           |  Index: rectifierStatusID
            |           |           |
            |           |           +-- -R-- Integer32 rectifierStatusID(1)
            |           |           |        Range: 1..100
...
            |           |           +-- -R-- Integer32 rectifierStatusOutputVoltage(4)
            |           |           |        Range: 0..65535

Looking at the above rectifierStatusEntry branch, it marks a tabular entry expected to range from 1 to 100 as defined by rectifierStatusID. Hence, putting 0 as one of the output voltage index will confuse the OID reported by GET as

1. belong to the scalar type (a misconception that is)
2. belong to the tabular type but out of index range

GET against the MIB will return the following error

$ sudo snmpget -m +ELTEK-DISTRIBUTED-PLANTV4-MIB -v 1 -c public raddlex ELTEK-DISTRIBUTED-PLANTV4-MIB::rectifierStatusOutputCurrent.0
ELTEK-DISTRIBUTED-PLANTV4-MIB::rectifierStatusOutputCurrent.0: Unknown Object Identifier (Index out of range: 0 (rectifierStatusID))

while the item (output current) actually has value in it as found below

$ sudo snmpget -v 1 -c public raddlex .1.3.6.1.4.1.12148.9.5.5.2.1.3.0
SNMPv2-SMI::enterprises.12148.9.5.5.2.1.3.0 = INTEGER: 1

By this time the MIB is already the latest to be used with firmware version 4.3.

I decided to install in RedHat 5.2. Maybe it is easier in Ubuntu (Nagios 3 already listed in the repository, but I haven’t tried it). As pointed out by the quickstart (it is meant for Fedora by the way), requirements are:

1. php, httpd
2. gcc, glibc, glibc-common
3. gd, gd-devel

After getting those, the configure-make-install procedure runs well, except that I don’t check the warnings. It turns out that only some of Nagios core components are installed. It can be seen from the content of /usr/local/nagios/libexec directory. There is no check_snmp etc. Error also appears in statusmap page of Nagios.

Compile More Nagios Core Components

I run through ./configure once more, check out all warnings, and begin to evaluate requirements (found this text inside nagios-plugins-1.4.14 tarball)

MySQL

For check_mysql functionality, mysql (MySQL client for linux) must be installed. ./configure also test this client, by default config, to the local MySQL socket, hence mysql-server must also exist.

Radius Client

Client from freeradius package doesn’t meet Nagios requirements. It must be the ones from original radiusclient, I found RPMs for radiusclient-0.3.2-0.2.el5.rf.i386.rpm and radiusclient-devel-0.3.2-0.2.el5.rf.i386.rpm.

GD

It is quite tricky to get statusmap.c to be compiled for the .cgi of Nagios status map. Compilation needs gd library from http://www.libgd.org/. gd requires zlib, libjpeg, and libpng. On first attempt, I installed from RPMs. This appeared to be not working as I could still see warnings about gd2 during ./configure.

So, I choose to compile from the source gd-2.0.33.tar.bz2. This tarball was found in the older section of current gd2 web. I chose this version because the RPM used was gd-2.0.33-9.4.el5_1.1.rpm. I removed this RPM first which made me to remove also libmwf and ImageMagick.

After straightforward  configure-make-install the library will be installed under /usr/local/lib i.e libgd.so.2.0.0. Header files will also be available in /usr/local/include i.e gd.h. These are different from the situation when I installed from RPM where libgd.so.2.0.0 is under /usr/lib/ and no gd.h found under /usr/include.

So, I make devclean and rerun

./configure --with-gd-lib=/usr/local/lib --with-gd-inc=/usr/local/include --with-command-group=nagcmd

I configure the /usr/local/nagios/etc/cgi.conf but status map page is still empty. Next workaround is to install back  gd-2.0.33-9.4.el5_1.1.rpm. (which also bring back libmwf and ImageMagick) and point the gd library to the ones created from RPM. I make devclean and rerun:

./configure --with-gd-lib=/usr/lib --with-gd-inc=/usr/local/include --with-command-group=nagcmd

At this point I regret not to have Ubuntu implementation in the first place. Just a small regret.

Other library needed for check_smtp, check_http, etc. don’t seem to trouble me much, I need openssl, openldap, etc. and simply get them from RPMs.