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 http://ftp.cyconet.org/debian/. 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 nagios-plugins.org 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 https://www.monitoring-plugins.org/download.html 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=http://archive.raspbian.org/raspbian 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"' >> \
    /root/.mk-sbuild.rc
cp -a /usr/bin/mk-sbuild /tmp/mk-sbuild
patch -p0<./mk-sbuild_raspbian.diff /tmp/mk-sbuild

mk-sbuild_raspbian.diff

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

/tmp/mk-sbuild --arch=armhf --debootstrap-mirror=http://archive.raspbian.org/raspbian 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

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! ;)

As some of you might have noticed, the Site PHP.net was infected yesterday with Malware.
If you are running a shared hosting environment, you are also be faced with similar Malware problems. Beside XSS attacks and compromised server systems on OS-level, very widely used attack szenarios are stolen user credentials.

A usefull mitigation strategy might be a web application firewall (WAF) like ModSecurity. Another way might be the Malware scanner Linux Malware Detect. The project describes itself:

**Description**
Linux Malware Detect (LMD) is a malware scanner for Linux released under the
GNU GPLv2 license, that is designed around the threats faced in shared hosted
environments. It uses threat data from network edge intrusion detection systems
to extract malware that is actively being used in attacks and generates
signatures for detection. In addition, threat data is also derived from user
submissions with the LMD checkout feature and from malware community resources.
The signatures that LMD uses are MD5 file hashes and HEX pattern matches, they
are also easily exported to any number of detection tools such as ClamAV.

**Features**
- MD5 file hash detection for quick threat identification
- HEX based pattern matching for identifying threat variants
- statistical analysis component for detection of obfuscated threats (e.g: base64)
- integrated detection of ClamAV to use as scanner engine for improved performance
- integrated signature update feature with -u|–update
- integrated version update feature with -d|–update-ver
- scan-recent option to scan only files that have been added/changed in X days
- scan-all option for full path based scanning
- checkout option to upload suspected malware to rfxn.com for review / hashing
- full reporting system to view current and previous scan results
- quarantine queue that stores threats in a safe fashion with no permissions
- quarantine batching option to quarantine the results of a current or past scans
- quarantine restore option to restore files to original path, owner and perms
- quarantine suspend account option to Cpanel suspend or shell revoke users
- cleaner rules to attempt removal of malware injected strings
- cleaner batching option to attempt cleaning of previous scan reports
- cleaner rules to remove base64 and gzinflate(base64 injected malware
- daily cron based scanning of all changes in last 24h in user homedirs
- daily cron script compatible with stock RH style systems, Cpanel & Ensim
- kernel based inotify real time file scanning of created/modified/moved files
- kernel inotify monitor that can take path data from STDIN or FILE
- kernel inotify monitor convenience feature to monitor system users
- kernel inotify monitor can be restricted to a configurable user html root
- kernel inotify monitor with dynamic sysctl limits for optimal performance
- kernel inotify alerting through daily and/or optional weekly reports
- e-mail alert reporting after every scan execution (manual & daily)
- path, extension and signature based ignore options
- background scanner option for unattended scan operations
- verbose logging & output of all actions

The recent development can be found at Github and in the last days I worked on packaging this into a Debian package ‘maldetect’.

If you want to give it a try on Debian, you could install the packages from our restricted repository:

    # wget "http://ftp.cyconet.org/debian/sources.list.d/restricted-cyconet.list" \
        -O /etc/apt/sources.list.d/restricted-cyconet.list
    # aptitude update
    # aptitude -t restricted install maldetect

For adding our archive key, you can just install the package “debian-cyconet-archive-keyring”

Today the Nagios Plugins Development Team released the long awaited version 1.5 of the Nagios Plugins. It contains several bug-fixes as well as new features. The project moved to a new home at nagios-plugins.org, the SCM and issue tracker moved to github. If you want to contribute to the project, please have a look into the updated development documentation. Many thanks guys, you rock!

The package was uploaded already into Debian unstable and it should hit the Backports repository soon.

If you are impatiently, you could install the package from our repository.

If you are often working with ‘git status’ and ‘git checkout/branch’ the following may a huge enhancement for you

.bashrc

Indeed, there is much crappy PHP appliaction code out there in the wild. Anyways … when you have to care about webservers you may have systems which are relying on PHP. Upgrading this systems to the next major PHP version may break projects hosted on those systems, cause there is deprecated code in them which is not supported by the new PHP version.

I just hacked together a smallish shell script to spot problematic functions and ini directives of the working directory. Enhancements and missing code fragments are welcome.

php54_deprecated_functions.sh