Today early in the morning my monitoring system notified me about unusual high outgoing traffic on my hosting plattform. I traced the problem down the webserver which is also hosting this abondened website.

Looking into this with iptraf revealed that this traffic is coming only from one IP. At first I thought anybody might grabbing my Debian packages from But no, it was targeting my highly sophisticated blogging plattform.

$ grep /var/log/nginx/vhosts/access_logs/ | tail -2 - - [23/Mar/2015:08:20:12 +0100] "POST /wp-login.php HTTP/1.0" 404 22106 "-" "-" - - [23/Mar/2015:08:20:12 +0100] "POST /wp-login.php HTTP/1.0" 404 22106 "-" "-"
$ grep /var/log/nginx/vhosts/access_logs/ | wc -l
$ grep /var/log/nginx/vhosts/access_logs/ | wc -l
$ grep /var/log/nginx/vhosts/access_logs/ | grep -v wp-login.php | wc -l

It makes me really sad to see, that dictionary attacks are smashing with such a high power these days, even without evaluating the 404 response.

Three months ago version 2.0 of Monitoring Plugins was released. Since then many changes were integrated. You can find a quick overview in the upstream NEWS.

Now it’s time to move forward and a new release is expected soon. It would be very welcome if you could give the latest source snapshot a try. You also can give the Debian packages a go and grab them from my ‘unstable’ and ‘wheezy-backports’ repositories at Right after the stable release, the new packages will be uploaded into Debian unstable. The whole packaging changes can be observed in the changelog.

Feedback is very appreciated via Issue tracker or the Monitoring Plugins Development Mailinglist.

Update: The official call for testing is available.

For an actual project we decided to use Redis for some reasons. As there is availability a critical part, we discovered that Redis Sentinel can monitor Redis and handle an automatic master failover to a available slave.

Setting up the Redis replication was straight forward and even setting up Sentinel. Please keep in mind, if you configure Redis to require an authentication password, you even need to provide that for the replication process (masterauth) and for the Sentinel connection (auth-pass).

The more interesting part is, how to migrate over the clients to the new master in case of a failover process. While Redis Sentinel could also be used as configuration provider, we decided not to use this feature, as the application needs to request the actual master node from Redis Sentinel much often, which will maybe a performance impact.
The first idea was to use some kind of VRRP, implemented into keepalived or something like this. The problem with such a solution is, you need to notify the VRRP process when a redis failover is in progress.
Well, Redis Sentinel has a configuration option called ‘sentinel client-reconfig-script’:

# When the master changed because of a failover a script can be called in
# order to perform application-specific tasks to notify the clients that the
# configuration has changed and the master is at a different address.
# The following arguments are passed to the script:
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
# <state> is currently always "failover"
# <role> is either "leader" or "observer"
# The arguments from-ip, from-port, to-ip, to-port are used to communicate
# the old address of the master and the new address of the elected slave
# (now a master).
# This script should be resistant to multiple invocations.

This looks pretty good and as there is provided a <role>, I thought it would be a good idea to just call a script which evaluates this value and based on it’s return, it adds the VIP to the local network interface, when we get ‘leader’ and removes it when we get ‘observer’. It turned out that this was not working as <role> didn’t returned ‘leader’ when the local redis instance got master and ‘observer’ when got slave in any case. This was pretty annoying and I was short before giving up.
Fortunately I stumpled upon a (maybe) chinese post about Redis Sentinal, where was done the same like I did. On the second look I recognized that the decision was made on ${6} which is <to-ip>, nothing more then the new IP of the Redis master instance. So I rewrote my tiny shell script and after some other pitfalls this strategy worked out well.

Some notes about convergence. Actually it takes round about 6-7 seconds to have the VIP migrated over to the new node after Redis Sentinel notifies a broken master. This is not the best performance, but as we expect this happen not so often, we need to design the application using our Redis setup to handle this (hopefully) rare scenario.

You may wonder why the old good nagios-plugins are not up to date in Debian unstable and testing.

Since the people behind and maintaining the plugins <= 1.5 were forced to rename the software project into Monitoring Plugins there was some work behind the scenes and much QA work necessary to release the software in a proper state. This happened 4 weeks ago with the release of the version 2.0 of the Monitoring Plugins.

With one day of delay the package was uploaded into unstable, but did hit the Debian NEW queue due the changed package name(s). Now we (and maybe you) are waiting to get them reviewed by ftp-master. This will hopefully happen before the jessie freeze.

Until this will happen, you may grab packages for wheezy by the ‘wheezy-backports’ suite from or ‘debmon-wheezy’ suite from Feedback is much appreciated.

It seems to be a great time for monitoring solutions. Some of you may have noticed that Icinga has released it’s first stable version of the completely redeveloped Icinga 2.

After several changes in the recent past, where the Team maintaining the Plugins used for several Monitoring solutions was busy moving everything to new infrastructure, they are now back on track. The recent development milestone is reached and a call for testing was also sent out.

In the meanwhile I prepared the packaging for this bigger move. The packages are now moved to the source package monitoring-plugins, the whole packaging changes can be observed in the changelog. With this new release we have also some NEWS, which might be useful to check. Same counts for upstream NEWS.

You can give the packages a go and grab them from my ‘unstable’ and ‘wheezy-backports’ repositories at Right after the stable release, the packages will be uploaded into debian unstable, but might get delayed by the NEW queue due the new package names.

As Jan has previously announced, the Debian project is maintaining a booth at Chemnitzer Linux-Tage 2014, which is also organized by him.

This year we will have merchandising at the booth, which is provided by Alexander Wirt and of course a demo system with Debian wheezy BabelBox as the past years. I’ll drop it tomorrow, as I have a conflicting appointment on Saterday, maybe I can attend later on Sunday.

In case you have spare time at the weekend ahead, it may be worth to spend it with great lectures and meet nice people over there.

Last night it seems the so called ‘Nagios Plugins’ project was cut off. The story started a decade ago when development of the plugins compatible with Nagios was taken over by an independend group of developers.

Some time later, the domain of the ‘Nagios Plugins’ project was handed over to ‘Nagios Enterprises, LLC.’ due trademark reasons. To get an idea about that, I suggest to read on the ’Nagios Trademark Truth’ and ’Nagios Trademark Triumph Provides Promise To Open Source Developers, Shows Power of Community’. In the latter Mr. Galstad is cited with “This violation took more than four years and thousands in legal fees before it was finally resolved. My hope is that this can serve as an example to Open Source developers worldwide that they can overcome infringements and protect their brands if they are persistent and engage their respective communities.”.

Yesterday in the evening the project members recognised that the DNS of was moved to a different location. Now there seems to be a hosted (some may call that ‘hijacked’ or ‘pirated’) ‘mirror’ of the old site. Anyhow … the content is already different from the original one or maybe changed even more in the future. From my point of view this can serve as an example to Open Source developers worldwide that they can be obstructed by (trademark holding) companies even if those companies profit from the work of them. So please don’t use downloads from there, even the release tarballs maybe modified.

The news all about that: ‘Nagios Plugins are dead, we now have Monitoring Plugins in place!”

Be sure you download your tarballs from and verify your checksums!

You can follow the Monitoring Plugins Development Team also via Twitter.

Yesterday I asked myself, how to setup a crossbuild environment on a Debian wheezy/amd64 to build binary packages compatible for Raspbian.

After digging around it seemed to be the easiest way to use mk-sbuild to setup such a build environment.
We just need to install sbuild (>= 0.64.0-1) and ubuntu-dev-tools (>= 0.146), both packages are available since jessie:

aptitude install sbuild ubuntu-dev-tools

Some more packages are needed for crossbuilding:

aptitude install qemu-user-static binfmt-support linux-image-amd64

Setting up the chroot is quite easy with:

mk-sbuild --arch=armhf --debootstrap-mirror= jessie

Unfortunately you get thrown an error about bad signing key:

Release signed by unknown key (key id 9165938D90FDDD2E)

This happens cause debootstrap is using per default /usr/share/keyrings/${DISTRO}-archive-keyring.gpg, which doesn’t ship the Raspbian signing key indeed. After looking how to solve that problem, I decided to use a quik&dirty fix:

echo 'DEBOOTSTRAP_KEYRING="--keyring=/usr/share/keyrings/raspbian-archive-keyring.gpg"' >> \
cp -a /usr/bin/mk-sbuild /tmp/mk-sbuild
patch -p0<./mk-sbuild_raspbian.diff /tmp/mk-sbuild


Now you should be able to setup your Raspbian sbuild chroot via:

/tmp/mk-sbuild --arch=armhf --debootstrap-mirror= wheezy

At first we need to install Icinga and lighttpd:

aptitude install icinga lighttpd

We need to enable the lighttpd cgi and authentication module:

lighttpd-enable-mod cgi && ighttpd-enable-mod auth

Let’s create a config for Icinga (in a subdir of the default vHost). As you can see, you don’t need any ‘setenv.add-environment’ on wheezy (at least):

vi /etc/lighttpd/conf-available/50-icinga.conf


Let’s create a config file with credentials for the user icingaadmin:

htpasswd -c /etc/icinga/htpasswd.users icingaadmin

Now we just need to enable the icinga config and reload the lighttpd:

lighttpd-enable-mod icinga && /etc/init.d/lighttpd force-reload

At this point you should find a working Icinga setup at http://yourip/icinga

P.S. Does anybody know how to setup a buildenv (preferable as crossbuild on amd64) for Raspbian, as the Debian armhf packages are not compatible to raspbian and so there is no access to the Backports repository? Cool would be to get a sbuild env running, so it can be integrated into a buildd.

After running a QNAP TS-459 Pro+ for the last 3 or 4 years at home, my monitoring was alerting me about memory warnings cause I upgraded my SqueezeBox Server to the latest nightly version. So I looked into how to upgrade the shipped Adata SU3S1333B1G9-B.

It seems that the KVR1333D3S8S9/2G should work, so I ordered one. After plugin it in, it revealed that the module wasn’t working while it worked for others. After digging around, it seems essentially that the modul has a 8-chip design. Indeed, my modul just has only 8 memory chips, but the design is a 16 chip. So I thought it would be a nice try to order the one from amazon that worked for others.

And like expected it’s not the same module but has the same Kingston Part Number.

As you can see, the 16 chip design module has printed ‘9905428-189.A00lf’ on and the 8 chip design ‘9931712-009.A00G’. It’s something like in the Wireless LAN USB dongle business where they sell totally different hardware with the same Part Number but different Revisions.
I also ordered a Samsung M471B5773DH0-CH9 cause that’s also a 8 chip design.

To make it short, both 8 chips design modules worked like a charm, the M471B5773DH0-CH9 and the KVR1333D3S8S9/2G (9931712-009.A00G). - Please avoid the Adolf one from Kingston! ;)