This year I take care of organizing of the Debian booth at Chemnitzer Linux-Tage 2014 which has been approved a few days ago. The CLT is a yearly (mostly) german speaking Free Software community event which takes place on the weekend of 15th/16th march in Chemnitz (Germany). On the Linux-Live pages you find a lot of projects that will have a booth there and the talk schedule contains many interesting topics. There will also be a key signing event for which you can register until 11th of march. The Wiki page for the Event is already in a good shape. Many things are already organized, but we still have some items left. A lot of people from the Debian community have already told me that they will be there. We will have a Debian Wheezy BabelBox demonstration running on a VirtualBox host that Jan Wagner will provide as well as merchandising (Thanks to Alexander Wirt). Two talks from people on our Wiki page have been accepted by the CLT organizers too:

• Methoden zur Gewinnung neuer Teammitglieder by Andreas Tille
• Das Debian-LAN Projekt: Installation eines Debian-Netzwerks einfach gemacht by Andreas Mundt

I am happy to meet many nice people from the Free Software community in Chemnitz soon.

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.

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

Unfortunately ownCloud is not available in Debian wheezy. Even if it was promised to provide a package via backports, this seems never to happen. As I don't like the idea of adding source lists of testing/unstable/experimental to production systems, I walked the long and painfull path of backporting all (build-)dependencies and pushed them into our wheezy-backports repository. If you want to give it a try on Debian wheezy, you could install the packages from our wheezy-backports repository:

    # wget "http://ftp.cyconet.org/debian/sources.list.d/wheezy-backports-cyconet.list" \
        -O /etc/apt/sources.list.d/wheezy-backports-cyconet.list
    # aptitude update
    # aptitude -t wheezy-backports install owncloud owncloud-mysql

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

Some of you might have noticed there is a new nagios-plugins version in the row. To support upstream in evaluating bugs and bringing the code to a wider audience, I uploaded the latest development version into Debian unstable. Since this package version contrib/ is dropped by upstream. But we stopped shipping the latest plugins of contrib/ with Debian wheezy. We also removed perlmods/ from the upstream tarball, as this was never used by our package. The packaging changes are:

* New upstream git snapshot (b15adb7762)
  - Adjust debian/copyright
* Droped the following upstream integrated patches
  - 05_fix_gets_undefined_in_iso_c11.dpatch
  - 10_check_apt_perfdata.dpatch
  - 11_check_nt_npe.dpatch
  - 12_check_smtp_double_threshold.dpatch
* Fix removing empty /usr/include
* Add new check_dbi into nagios-plugins-standard
* Remove whois from Recommands, as check_bgpstate is removed
* Cleanup debian/rules from unused stuff
* Provide information about repackaging
  - Extend debian/README.source
  - Add debian/bin/repack.sh
* Updating standards version to 3.9.4 (no changes needed)
* Add libfreeradius-client-dev to build-deps and remove libradiusclient-ng-dev
  (Closes: #721621)
* Remove traces of contrib/ from debian/copyright
* Remove command.cfg from examples in nagios-plugins-common, it was removed
  upstream

The Debian Nagios Maintainer and Upstream Developer are asking you to try out this new package on non production systems. Not that we think there might be a high risk for damage, but you know .. :) The latest version of the plugins are running on several systems already, but it is nearly impossible to test all scenarios even automated. If you find bugs, please report all packaging bugs into the BTS. Upstream bugs you might consider to report in the upstream bugtracker. If you want to give it a try on Debian wheezy, you could install the packages from our wheezy-backports repository:

    # wget "http://ftp.cyconet.org/debian/sources.list.d/wheezy-backports-cyconet.list" \
        -O /etc/apt/sources.list.d/wheezy-backports-cyconet.list
    # aptitude update
    # aptitude -t wheezy-backports install nagios-plugins

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

Roundcube is one of the well known OpenSource solutions for accessing Mails via webinterface. Unfortunately the package in wheezy is ~2 years old.
In Debian unstable the package was updated, but #714727 is blocking the migration to jessie. In the meanwhile I backported the package to wheezy. For everybody still using the sqlite (v2) backend, see here. There is no automatic migration from sqlite to sqlite3 backend.
For everybody using the package roundcube-plugins-extra, I created an updated package for roundcube 0.9 and submitted my changes to the Debian Roundcube Maintainers. If you want to give it a try, you could install the packages from my wheezy-backports repository:

# wget "http://ftp.cyconet.org/debian/sources.list.d/wheezy-backports-cyconet.list" \
    -O /etc/apt/sources.list.d/wheezy-backports-cyconet.list
# aptitude update
# aptitude -t wheezy-backports install roundcube-mysql roundcube-plugins roundcube-plugins-extra

For adding my archive key, you can just install the package "debian-cyconet-archive-keyring"

Since 2 weeks I'm faced with some problems at a Xen hosting environment based on Debian wheezy. The issue is, that one specific domU is regularly failing network. The investigations showed, that no network packets from and to this system are seen on the the network interface in the domU and on the bridge interface in the dom0.
The funny part is, that the firewall on the dom0 now is logging packet rejects on the interface of the effected system and one interface of an other specific domU for the destination address. One pack and rejects on both interfaces ... really strange!
Shutting down the domU and recreating them doesn't help. Even if restarting other domUs, those are also effected by now. The only way to fix is to reboot the entire dom0. After several investigations I stumpled upon the following in the dmesg:

vif-xm116: Frag is bigger than frame.
vif-xm116: fatal error; disabling device
xenbr0: port 4(vif-xm116) entering disabled state

A quick search at the famouse search engine revealed, there seems something bigger. Even a Debian bug is open since February. Unfortunately this problem is still unfixed in wheezy and squeeze.
But ... there is hope in sight! Ian Campbell provided packages based on top of the latest kernel packages with a call for testing. Installing them seems to fix the issue in my environment. So we just have to hope this will get fixed soon, as this regression is really annoying. Thanks to all who make this happen in advance!

Mailscanner is an e-mail security and anti-spam solution for e-mail gateways. In combination of postfix it uses a very ugly way messing around in postfixs queue directories. Anyways .. if you are still interested, keep reading. Mailscanner was removed from Debian, so it's not available in wheezy. Anyways ... there is a web 2.0 Frontend for Mailscanner, called Baruwa, which provides mailscanner packages for Debian. Add the baruwa sources file

cat > /etc/apt/sources.list.d/mailscanner.list << 'EOF'
deb http://apt.baruwa.org/debian wheezy main
deb-src http://apt.baruwa.org/debian wheezy main
EOF

Optional, install the GPG key for the reprosority

wget -O - http://apt.baruwa.org/baruwa-apt-keys.gpg   apt-key add -

If you're running squeeze with Mailscanner, you should do this before upgrading to wheezy. If you are installing Mailscanner on a fresh wheezy, just:

aptitude update && aptitude install mailscanner

As of Version 4.78 and above, you can place you local changes into /etc/MailScanner/conf.d/, no need to mess directly around into /etc/MailScanner/MailScanner.conf

If you updated recently your system to Debian wheezy and you are using vsftpd with enabled chrooted local users ...

[~] # grep -i  ^chroot_local_user=yes /etc/vsftpd.conf   tail -1
chroot_local_user=YES

... you maybe faced with the following problem:

500 OOPS: vsftpd: refusing to run with writable root inside chroot()
Login failed.

This problem raised already in Bug #656900 and it was fixed by adjusting the documentation. Beside that there maybe configurations you want to relax such a strict check. Unfortunately this feature was implemented in version 3.0.0 which is not part of Debian wheezy:

- Add new config setting "allow_writeable_chroot" to help people in a bit of
a spot with the v2.3.5 defensive change. Only applies to non-anonymous.

The Frontier Group created a patched package of vsftpd for Ubuntu. After reviewing the patch we decided to also create a Debian package for wheezy. You can easily install the package by the following sniplet:

echo "deb http://ftp.cyconet.org/debian wheezy-updates main non-free contrib" >> \
/etc/apt/sources.list.d/wheezy-updates.cyconet.list; \
aptitude update; aptitude install -t wheezy-updates debian-cyconet-archive-keyring vsftpd && \
echo "allow_writeable_chroot=YES" >> /etc/vsftpd.conf && /etc/init.d/vsftpd restart

Updates, in case of bugfixes in Debian wheezy, should be also available through this distribution channel.

Also this year the Debian project was present at Chemnitzer Linuxtage, this time right next the debianforum.de booth. The booth folks arriving on friday organized a flashmob at Expitas after booth setup. Unfortunatly our second planned flashmob at the mensa was boycotted by much more students, so we ended up in the Turm-Brauhaus, which is a great location with good drinks but the service was very harshly. On the next two days at the booth we chatted and discussed with visitors and other exhibitors a wide variety of questions, including 'When will be (the next Debian version) released?' and 'Are there installation disks available?'. The answers was as always 'When we are ready and we will have reached the quality-level we defined', 'No we don't have installation medias, as they are always outdated. Do you have an USB-dongle with you?'. Merchandising was requested by visitors as always, but we just had some leftovers of fosdem, brought by Axel. The demonstration was as usual a small box running Babelbox and xpenguins which worked out the last years too. This year there were three lectures held by Debian related people, about Debian GIS, Aptitude - known but even unknown and SSH and unreliable network connections. The organisation team did a really great job. The social event at saturday night was very exciting and we left it early in the morning. The whole event was indeed fun and a pleasure to find new friends and meet old ones of the Free Software community. Many thanks to Florian Baumann, Jan Dittberner, Andreas Tille, Christian Hoffmann, Axel Beckert, Markus Rekkenbeil, Daniel Schier, Jonas Genannt, Jan H rsch and kurio for taking care and running the booth, which worked out this year extreme smoothly from my point of view. Likewise as the last years a special thanks to TMT GmbH & Co. KG, which kindly donated additional boothtickets, the equipment, its transportation and accommodation for almost half of the booth staff.

Also this year I registered a booth in the name of the Debian Project at Chemnitzer Linux-Tage. Unfortunalety this is the second time in the row, that we seem to be short of manpower while preparing the booth. Actually just one person was able to commit his available time. A general offer was announced by 3 people (including me). This makes me a little sad, cause CLT is a very community driven event which is really nice organized. I always liked to chat and discuss with very interesting people from other projects and visitors. As the CLT runs a 6 track lecture program with commonly very good lectures, it is not possible to get the booth running into good shape with such a small amount of volunteers. If you feel you are interested into visiting the Chemnitzer Linux-Tage and want to make our booth a success like last years for the Debian Project, please have a look into my announcment and our coordination wiki. So please ... let come more brave people into our band wagon! Don't wait to long! Registration period for (possibly sponsored) Booth tickets (read here) ends on 4th March, many thanks!

Some of our customers are using central CUPS systems for managing their printer infrastructure. In the last years the demand for support printing (called Airprint) from mobile apple products increased. This worked well for us on Debian squeeze as documented here (updated scrips). I tried this on a fresh installed Debian wheezy amd64, but no printer was found on any IOS device. Hmm .... let's see if the printer is announces via avahi:

$ avahi-browse -a   grep -i print
+   eth0 IPv6 Kyocera FS-1020D @ service                    Internet Printer     local
+   eth0 IPv6 AirPrint Kyocera @ service                    Internet Printer     local
+   eth0 IPv4 Kyocera FS-1020D @ service                    Internet Printer     local
+   eth0 IPv4 AirPrint Kyocera @ service                    Internet Printer     local

WTF?!? Fortunately we have an Ubuntu 12.04 running in our office and printing from IOS devices works without problems (without copying any files to /etc/avahi/services/):

$ avahi-browse -a   grep -i print
+   eth2 IPv6 Ricoh Aficio MP C2800 @ printing              Internet Printer     local
+   eth2 IPv6 Ricoh Aficio MP 171 @ printing                Internet Printer     local
+   eth2 IPv4 Ricoh Aficio MP 171 @ printing                Internet Printer     local
+   eth2 IPv4 Ricoh Aficio MP C2800 @ printing              Internet Printer     local

I just copied the whole configuration over to my wheezy system, but it didn't worked out. I tried this all on a kfreebsd-i386 system again without success. Sorry, but I don't understand the source of this issue. Cups on wheezy has the same upstream version as on precise. Avahi-daemon on wheezy is just one minor version ahead off precise. Is this a bug/incompatibility in cups and/or avahi? A missing patch compared to the packages of precise? Is this a configuration problem? Update: Looking into LP #1054495 and the debdiff of cups 1.5.3-0ubuntu6 indicates, that there seems modifications beside simple changes of mime configurations files. Update: The fix for LP #1054495 does really fix the problem on wheezy too. With the help of Didier Raboud I was able test a binary package with this fixapplied on our test setup. The good news is, there are no extra modifications needed beside just configuring cups to export it's printers for enabling support for iOS devices. I opened #700961 and hopefully release managment will accept this fix for wheezy. Hints, rants and comments could be send to 'blog - at - waja - dot - info' or via @blogwajainfo.

If you are comming from an old SCM like subversion, you may have difficulties to internalize the new workflow. Peter Cottle created Learn Git Branching which is really nice.

Server management on daily basis in a growing environment could be a challenge. Most of the tasks is here done with ClusterSSH in help with a homebrew mail notification. Unfortunately this workflow is not scaling well for 200+ systems. I had a look into apt-dater but this seems not to fit our workflow. FAI looks a bit overengineered at the first glance. Maybe Puppet is an option? There seems to be many extensions for it, unfortunately ruby is needed on every single node. Is there a CTO-compatible overview about puppet, any other alternatives? ;) Update: Many thanks for the hints from Andr Lu s Lopes, Stig Sandbeck Mathisen, Phil Miller, Steve Kemp, Andrew Latham, Bob Proulx and Natxo Asenjo

• Chef
  • Packaged in Debian
  • Upstream Debian packages (no recent one)
• CFEngine3
  • No ruby/perl/python dependencies
  • Light, fast
  • (A bit) harder to understand
  • Packaged in Debian
  • Upstream Debian packages
• Salt
  • Very young
  • Packaged in Debian
• Ansible
  • Very flexible
  • Easy to understand
  • Relies on ssh
  • Open ITP
  • PPA
• MCollective
  • Framework for building server orchestration and parallel job execution
  • Could extend for example Puppet or Chef
  • Packaged in Debian
  • Upstream Debian packages (no recent one)
• Foreman
  • Puppet dashboard and node classifier
  • Open ITP
  • Upstream Debian packages

Old but conceptual still valid: www.infrastructures.org, for example Bootstrapping an Infrastructure Other thoughts: push- or pull-infrastructure? Software footprint (on nodes and your central instance)! Hints, rants and comments could be send to 'blog - at - waja - dot - info' or via @blogwajainfo.

Server management on daily basis in a growing environment could be a challenge. Most of the tasks is here done with ClusterSSH in help with a homebrew mail notification. Unfortunately this workflow is not scaling well for 200+ systems. I had a look into apt-dater but this seems not to fit our workflow. FAI looks a bit overengineered at the first glance. Maybe Puppet is an option? There seems to be many extensions for it. Is there a CTO-compatible overview about puppet, any other alternatives? ;) Hints, rants and comments could be send to 'blog - at - waja - dot - info'.