As it was announced on December 6th 2011, support for Debian Lenny will end on February 6th 2012. This means, no future updates will be released for Lenny systems. Time to upgrade.

The affected machine is a virtual machine (VPS) running as a Xen guest. Installed services are Apache2, MySQL, Nagios (compiled from source), PHP (compiled from source), OTRS (from source).

Will everything go smooth? I was especially worried about the kernel part, as Xen guests have their kernel pushed from the Xen host. In the Debian Upgrade Guide it is mentioned to upgrade the kernel manually BEFORE having the automatic apt-get script updating udev...

I will show my upgrade steps, based on the official Debian upgrading steps, and also what I did in case of problems.

1. Stop services. Nothing to comment here...

2. Backup! This is strongly encouraged. I backuped everything into /home/backup. Why? As mentioned in the Debian documentation, the /home directories won't be touched by the upgrade script.
The backup of /etc/ is very important. Besides that applications and user data should be backed up as well (e.g. dump of database otrs in my case).

3. Verify that the system is up to date and that no packages are on hold. This would break the upgrade process.
You can verify this by launching aptitude in the interactive mode and hit the key 'g'. If you get the message 'No packages are scheduled to be installed, removed, or upgraded.', then you're good to go.
To check the system for held packages, launch these commands. If you don't get an output, that's good!

myvps:/home/backup# dpkg --get-selections | grep hold
myvps:/home/backup# aptitude search "~ahold

Important note: The package 'splashy' mustn't be installed! In case you have this installed, remove it with 'apt-get purge splashy'.

4. It's time to update the /etc/apt/sources.list file. Just in case, make a backup of this file.
Since Debian Squeeze, there are is no 'debian-volatile' option anymore. So if you have an entry with debian-volatile, you must remove it from your sources.list.
Now replace all 'lenny' strings by 'squeeze'.
In my case, here's how my sources.list looked BEFORE:

deb ftp://ftp.hosteurope.de/mirror/ftp.debian.org/debian lenny main contrib non-free
deb ftp://ftp.hosteurope.de/mirror/ftp.debian.org/debian-volatile lenny/volatile main contrib non-free
deb ftp://ftp.hosteurope.de/mirror/ftp.debian.org/debian-security lenny/updates main contrib non-free

... and AFTER the modification:

deb ftp://ftp.hosteurope.de/mirror/ftp.debian.org/debian squeeze main contrib non-free
deb ftp://ftp.hosteurope.de/mirror/ftp.debian.org/debian-security squeeze/updates main contrib non-free

5. Now to the serious part! The upgrade!
In previous Debian versions, it was always recommended to use aptitude for the update, since the upgrade Lenny to Squeeze, apt-get should be used.
First update the packages list with all the new versions, so the system knows what to upgrade, then launch a minimal upgrade:

myvps:/# apt-get update

myvps:/# apt-get upgrade

The next step should be a manual upgrade of the kernel (linux-image). In the documentation this step is recommended so that the new version of udev (which will come in the next step) is compatible with the new kernel. But since this is a virtual xen server, there is no such kernel, so I skipped the manual kernel upgrade.

6. Once the minimal upgrade is completed, the distribution upgrade (dist-upgrade) follows:

myvps:/# apt-get dist-upgrade

And during this process, the following message appeared:

You are currently upgrading udev to a version that is not compatible with the currently running kernel.

You MUST install a compatible kernel version (2.6.26 or newer) before upgrading, otherwise the system may become UNUSABLE. Packages with a name starting with "linux-image-2.6-" provide a kernel image usable with this new udev version.

If you choose to upgrade udev nevertheless, you should install a compatible kernel and reboot with that kernel as soon as possible.

Proceed with the udev upgrade despite the kernel incompatibility?

YES                     NO

And this is exactly what I was afraid of at the beginning....
First I tried to select No - but then the dist-upgrade process is stopped and the upgrade not completed. So I relaunched the dist-upgrade and answered this question with YES.

The upgrade process continued and did finish after a couple of minutes. There's only one way to know, if there isn't a problem with udev and the xen kernel: A reboot ;-)

The machine booted just fine and was back after a couple of seconds, without any warnings or errors concerning the kernel or udev! Great! So far...

7. After the successful upgrade and reboot, the installed services had to be checked and to my big surprise, MySQL didn't run anymore. It couldn't even be started anymore:

myvps:/# /etc/init.d/mysql start
myvps:/# /etc/init.d/mysql status

As one can see, there isn't any output after the commands. Something's strange... A manual check confirmed the 'strangeness':

myvps:/# /usr/bin/mysqld_safe
-bash: /usr/bin/mysqld_safe: No such file or directory

Seems the upgrade script didn't do something that well. I checked, what is still installed or if everything was gone, and I found that the previous MySQL 5.0 was still installed, combined with some newer packages of 5.1:

myvps:/# dpkg -l | grep mysql
ii  libdbd-mysql-perl                     4.016-1                      Perl5 database interface to the MySQL database
ii  libmysqlclient15-dev                  5.0.51a-24+lenny5            MySQL database development files
ii  libmysqlclient15off                   5.0.51a-24+lenny5            MySQL database client library
ii  libmysqlclient16                      5.1.49-3                     MySQL database client library
ii  mysql-client-5.0                      5.0.51a-24+lenny5            MySQL database client binaries
ii  mysql-common                          5.1.49-3                     MySQL database common files, e.g. /etc/mysql/my.cnf
rc  mysql-server-5.0                      5.0.51a-24+lenny5            MySQL database server binaries
rc  php5-mysql                            5.2.6.dfsg.1-1+lenny13       MySQL module for php5
ii  python-mysqldb                        1.2.2-10+b1                  A Python interface to MySQL

To solve that problem, I simply launched a new installation of mysql-server-5.1:

myvps:/# apt-get install mysql-server-5.1
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libio-compress-base-perl libts-0.0-0 libltdl3-dev g++-4.3 libdns58 libmpfr1ldbl libdirectfb-1.0-0 libtool libbind9-50 libstdc++6-4.3-dev
  libtest-deep-perl libisccfg50 tsconf libio-compress-zlib-perl libossp-uuid15
Use 'apt-get autoremove' to remove them.
The following extra packages will be installed:
  mysql-client-5.1 mysql-server-core-5.1
Suggested packages:
  tinyca
The following packages will be REMOVED:
  mysql-client-5.0
The following NEW packages will be installed:
  mysql-client-5.1 mysql-server-5.1 mysql-server-core-5.1
0 upgraded, 3 newly installed, 1 to remove and 0 not upgraded.
Need to get 16.7 MB/20.8 MB of archives.
After this operation, 33.2 MB of additional disk space will be used.
Do you want to continue [Y/n]? y
Get:1 ftp://ftp.hosteurope.de/mirror/ftp.debian.org/debian/ squeeze/main mysql-client-5.1 amd64 5.1.49-3 [10.1 MB]
Get:2 ftp://ftp.hosteurope.de/mirror/ftp.debian.org/debian/ squeeze/main mysql-server-5.1 amd64 5.1.49-3 [6598 kB]
Fetched 16.7 MB in 0s (29.8 MB/s)
Preconfiguring packages ...
(Reading database ... 58764 files and directories currently installed.)
Removing mysql-client-5.0 ...
Processing triggers for man-db ...
Selecting previously deselected package mysql-client-5.1.
(Reading database ... 58708 files and directories currently installed.)
Unpacking mysql-client-5.1 (from .../mysql-client-5.1_5.1.49-3_amd64.deb) ...
Selecting previously deselected package mysql-server-core-5.1.
Unpacking mysql-server-core-5.1 (from .../mysql-server-core-5.1_5.1.49-3_amd64.deb) ...
Selecting previously deselected package mysql-server-5.1.
Unpacking mysql-server-5.1 (from .../mysql-server-5.1_5.1.49-3_amd64.deb) ...
Stopping MySQL database server: mysqld.
Processing triggers for man-db ...
Setting up mysql-client-5.1 (5.1.49-3) ...
Setting up mysql-server-core-5.1 (5.1.49-3) ...
Setting up mysql-server-5.1 (5.1.49-3) ...
Installing new version of config file /etc/init.d/mysql ...
Stopping MySQL database server: mysqld.
Starting MySQL database server: mysqld.
Checking for corrupt, not cleanly closed and upgrade needing tables..

Once this was done, a quick check of the MySQL init script and everything was in order again:

myvps:/# /etc/init.d/mysql status
/usr/bin/mysqladmin  Ver 8.42 Distrib 5.1.49, for debian-linux-gnu on x86_64
Copyright 2000-2008 MySQL AB, 2008 Sun Microsystems, Inc.
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL license

Server version          5.1.49-3-log
Protocol version        10
Connection              Localhost via UNIX socket
UNIX socket             /var/run/mysqld/mysqld.sock
Uptime:                 22 sec

Threads: 1  Questions: 997  Slow queries: 0  Opens: 1445  Flush tables: 2  Open tables: 64  Queries per second avg: 45.318.

So to summarize the whole experience: The upgrade script did a good job, even though this is a VPS server without a real kernel installation. The 'udev' incompability turned out to be nothing but a warning (thank god!). The only thing to put a question mark to was the upgrade of MySQL; something clearly didn't work there as it should have. But the tables were untouched, the application OTRS was working fine again once the manual installation of MySQL 5.1 was done.

On Terminal Servers or Citrix servers the remote connection sessions are inevitable important. Therefore it is strongly recommend the number of the sessions, not only for licensing purposes but also to be aware when users don't log off their sessions correctly (and for other reasons of course).

To monitor the current active sessions, there is already a plugin for Nagios which is called 'Count number of terminal server sessions'. This plugin (actually a Windows batch file) uses the command 'query session' to find users which have an active RDP-Session (found by rdp-tcp#).

Unfortunately, this plugin doesn't output performance data and every Nagios administrator loves the graphs. But don't worry, it's very easy to add this. Another additional information I wanted to know through the plugin was not only the number of active connections, but also the number of disconnected sessions. Citrix admins might know that problematic....
As I mentioned, the plugin looks by default for the sessions with 'rdp-tcp#' mentioned. By changing this to 'ica-tcp#', Citrix sessions can be found as well.

So here we go, this is the modified plugin:

@ECHO OFF
SET /a COUNTA=0
SET /a COUNTD=0

FOR /f "TOKENS=1 DELIMS= " %%G IN ('query session ^|find "ica-tcp#"') DO SET /a COUNTA+=1
FOR /f "TOKENS=1 DELIMS= " %%G IN ('query session ^|find "Disc"') DO SET /a COUNTD+=1

ECHO Active sessions = %COUNTA%, Disconnected Sessions = %COUNTD%^|usersconnected=%COUNTA%;usersdisconnected=%COUNTD%
exit 0

To explain it's function in some words:
First two variables are defined, COUNTA (which represents the number of Active sessions) and COUNTD (for the number of Disconnected sessions).
Twice the command 'query session' is executed. The 'find' (equivalent to grep on Linux) looks for opened ICA (Citrix) sessions. These are all marked with 'ica-tcp#'.
The second query session looks for the string 'Disc' which marks disconnected sessions.
For each entry found, the defined variables COUNTA and COUNTD are incremented by one.
At the end follows the output (echo), followed by the pipe which represents the performance data to create graphs.

And this is how the graphs look like:

Believe it or not, this is exactly why I needed the graphs. To prove that the Citrix users didn't do a correct logoff, but rather disconnected their session ;-).

Credits go to the developer of the original plugin, briandent. You may also download my modified version here: check_user_count.bat

This month I've already had two cases where a Joomla website has been attacked and hacked. 

A security vulnerability was used to upload a PHP shell, which then was used to upload complete fake websites. These fake websites turned then out to be Phishing websites (what else...).

This PayPal Phishing website has been uploaded through a PHP shell which itself was uploaded through a vulnerability in the Joomla module com_fabrik

But how did the hacker upload the PHP shell?

After checking and comparing both hack attempts two conclusions could be made:
- The hack-attack was automated, both logs showed the EXACT same way of uploading the PHP shell, just from different IP addresses.
- The vulnerability must come from a module called com_fabrik which allows to upload CSV files. A forged CSV file must have been uploaded or the upload form was 'tricked' to upload a non-csv file.

Here some lines from the log:

41.233.160.99 - - [02/Jan/2012:01:27:31 +0100] "GET /index.php?option=com_fabrik&c=import&view=import&filetype=csv&tableid=1 HTTP/1.1" 200 9297 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0"

41.233.160.99 - - [02/Jan/2012:01:27:50 +0100] "POST /index.php?option=com_fabrik HTTP/1.1" 303 - "http://www.example.com/index.php?option=com_fabrik&c=import&view=import&filetype=csv&tableid=1" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0"

41.233.160.99 - - [02/Jan/2012:01:27:56 +0100] "GET /index.php?option=com_fabrik&c=import&view=import&fietype=csv&tableid=1&Itemid=0 HTTP/1.1" 200 9557 "http://www.example.com/index.php?option=com_fabrik&c=import&view=import&filetype=csv&tableid=1" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0"

41.233.160.99 - - [02/Jan/2012:01:28:03 +0100] "GET /media/ASS.php HTTP/1.1" 401 54 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0"

After a quick research, this vulnerability seems to be the one described in the vulnerability report #342 of 2011-11-26: Joomla com_fabrik - Remote File Upload Vulnerability. But what is even more intriguing is the fact, that there have been other exploits before and there will probably be others in the future.

On the developer website (www.fabrikar.com) the latest version mentioned on the blog is 2.1 and and mentions important security fixes - but that post was in July 2011.
On the download page several versions exist (3.0.3 from January 25th 2012 and 2.1.1 from September 26th 2011). Unfortunately there is no Changelog attached, so it is not known whether this particular vulnerability has been fixed or not.

My advise: Don't use this module. It seems to be too insecure for production environments.

Another update has been made on the Nagios/Monitoring plugin/script check_equallogic.

The volume names no longer show up with quotes in the output ("vol1" appears now simply as vol1) and performance data was added to the output, so graphs can be created for all discovered volumes.

As always, feedback is welcome!

There has been a small bugfix in the Nagios/Monitoring plugin check_equallogic. The 'volumes' check had an error in the logic how to handle the volumes, once the system-volumes were successfully ignored. This could cause that some volumes were not taken in account at the output.

The new version (20120123) has fixed this issue. Please use the newest version from now on. Existing versions should be replaced. Thanks to Laurent Colonges for his patience and for the tests with the new version.

To my very big surprise one of the oldest original Nagios plugins (check_procs) doesn't seem to have performance data integrated in the output.

Here's a typical launch of the plugin on the command line, done with two different versions:

# ./check_procs --version
check_procs v2019 (nagios-plugins 1.4.13)

# ./check_procs -w 150 -c 300
PROCS OK: 97 processes

# ./check_procs --version
check_procs v1.4.15 (nagios-plugins 1.4.15)

# ./check_procs -w 150 -c 300
PROCS OK: 110 processes

None of them show the perfdata, which is followed after a pipe character (|) after the output.
To create graphics with Nagiosgraph, at least some output in the perfdata 'field' is necessary.

A quick research on the Nagios Plugin Sourceforce page shows that several patches have already been supplied to add perfdata to this plugin. The first was submitted in 2005, the newest as of now just a month ago in December 2011. But bummer, they never made it into the plugin.
So that means that the good Nagios admin has to take matters in his own hands. I show you now in a step-by-step tutorial how you can enable perfdata yourself, and this is very easy, believe me!

1. First download the Nagios plugin source file from the SourceForge website.

2. Untar/Unzip the file, I'm doing this in /tmp:

/tmp # tar -xfz nagios-plugins-1.4.15.tar.gz

3. Change dir into the newly created folder:

/tmp # cd nagios-plugins-1.4.15

4. Open the check_procs source file which is called 'check_procs.c' and is located in the 'plugins' subfolder with your favourite editor (like vim):

/tmp/nagios-plugins-1.4.15 # vim plugins/check_procs.c

5. Go to line 295 where this line should be (as of version 1.4.15):

printf (ngettext ("%d process", "%d processes", (unsigned long) procs), procs);

Just one line below it add the following line:

printf ("|procs=%d;%d;%d;0", procs, wmax, cmax);

So it looks like this at the end:

        printf (ngettext ("%d process", "%d processes", (unsigned long) procs), procs);
        printf ("|procs=%d;%d;%d;0", procs, wmax, cmax);

What we did is simple: To the standard output we add another output (not as a new line, but directly followed after the original output) by using the variables procs (The number of processes found), wmax (the defined warning threshold) and cmax (the defined critical threshold).

Once done, save the changes.

6. Still in the nagios-plugins folder, the plugins need to be compiled (or re-compiled):

/tmp/nagios-plugins-1.4.15 # ./configure
/tmp/nagios-plugins-1.4.15 # make

7. The new check_procs plugin can now be found in the plugins folder and you can copy it to the other plugins:

/tmp/nagios-plugins-1.4.15 # cp plugins/check_procs /usr/local/nagios/libexec/

8. Test it on the command line and you'll find the performance data output:

/usr/local/nagios/libexec # ./check_procs -w 150 -c 300
PROCS OK: 133 processes|procs=133;150;300;0

Hurray!

What's missing now is the Nagiosgraph map entry for check_procs. Here you go:

# Service Type: check_proc
# Regex by Claudio Kuenzler
# Nagios Output: PROCS OK: 114 processes
# Perfdata: procs=114;150;200;0
/perfdata:procs=(\d+);(\d+);(\d+);0/
and push @s, [procs,
        ['active', GAUGE, $1 ],
        ['warn', GAUGE, $2 ],
        ['crit', GAUGE, $3 ] ];

Enjoy!

I'm currently working on a new website for my father, who will be a candidate for the local parliament in the canton (state) of Thurgau in Switzerland. The main goal is to deliver some basic information of the political views and ideas but it shouldn't be a "boring" website with tons of text which nobody's gonna read.

We came up with the idea of using a dynamic Gallery Slideshow which doesn't require Flash, so it will also be working on mobile devices. This way impressions can be given to the visitor through pictures and some text as descriptions. The technical solution for this gallery is a JavaScript solution called fadeslideshow.

The gallery doesn't need interaction, automatically changes pictures (fade-effect) and shows an embedded description in a layer above the image.

Here are two other pictures showing the general design of the website and the navigation, which uses CSS3 for the effects:

The website will be available soon on http://www.frischer-wind-im-thurgau.ch.

A new version of the monitoring plugin check_equallogic has been released yesterday. Two bugs were fixed in the 'temp' and 'info' checks which occured, if only one controller was working (discovered by Laurent Colonges).

The new version (20120104) is since yesterday evening available for download on the plugin page.

On a Debian Lenny server I changed the default locale from en_US.UTF-8 to en_US.ISO-8859-15 to be able to edit some files with European Umlauts. 

The setting has changed on the fly and I was able to view and edit such files perfectly with vim. But some scripts couldn't find that new locale, as they showed perl errors like this:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = (unset),
        LANG = "en_US.ISO-8859-15"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

This error comes from the command update-locale and as it points out, the file or directory for the defined locale couldn't be found.

It can be resolved by installing the package locales-all (by default only 'locales' is installed) which downloads additional locale files. The command update-locale worked fine just after.

On a new Roundcube (0.7) installation I recently did, something strange has happened: The defined plugins were not loaded and the error log was full with errors like these:

PHP Error: Failed to load plugin file /var/www/roundcube/plugins/lang_sel/lang_sel.php in /var/www/roundcube-0.7/program/include/rcube_plugin_api.php on line 196 (GET /)
PHP Error: Failed to load plugin file /var/www/roundcube/plugins/authenticate_by_confixx_email/authenticate_by_confixx_email.php in /var/www/roundcube-0.7/program/include/rcube_plugin_api.php on line 196 (GET /)
PHP Error: Failed to load plugin file /var/www/roundcube/plugins/persistent_login/persistent_login.php in /var/www/roundcube-0.7/program/include/rcube_plugin_api.php on line 196 (GET /)

At the begin I thought it could be a problem with the path, but it was correct (roundcube is a symlink to roundcube-0.7). Even by manually changing the vhost this didn't change the problem.
Another fact is that I use the exact same installation with the same configuration and plugins on another host, but one which is running on PHP 5.2.x.

Even by googling for this problem didn't find any clues, most of the hints were due to wrong paths or include path definitions.

But then it hit me! Just out of the blue I thought, what the heck, I check the permissions again and look at that:

/var/www/roundcube/plugins # ll
total 128K
drwxr-xr-x 4  501   80 4.0K Dec 22 10:20 acl
drwxr-xr-x 2  501   80 4.0K Dec 22 10:20 additional_message_headers
drwxr-xr-x 4  501   80 4.0K Dec 22 10:20 archive
drwxr-xr-x 2 root root 4.0K Nov  4 12:45 authenticate_by_confixx_email
drwxr-xr-x 2  501   80 4.0K Dec 22 10:20 autologon
drwxr-xr-x 2  501   80 4.0K Dec 22 10:20 database_attachments
drwxr-xr-x 3  501   80 4.0K Dec 22 10:20 debug_logger
drwxr-xr-x 2  501   80 4.0K Dec 22 10:20 emoticons
drwxr-xr-x 6  501   80 4.0K Dec 22 10:20 enigma
drwxr-xr-x 2  501   80 4.0K Dec 22 10:20 example_addressbook
drwxr-xr-x 2  501   80 4.0K Dec 22 10:20 filesystem_attachments
drwxr-xr-x 5  501   80 4.0K Dec 22 10:20 help
drwxr-xr-x 2  501   80 4.0K Dec 22 10:20 http_authentication
drwxr-xr-x 4  501   80 4.0K Dec 22 10:20 jqueryui
drwxr-xr-x 2  501   80 4.0K Dec 29 11:41 lang_sel
drwxr-xr-x 6  501   80 4.0K Dec 22 10:50 managesieve
drwxr-xr-x 4  501   80 4.0K Dec 22 10:20 markasjunk
drwxr-xr-x 3  501   80 4.0K Dec 22 10:20 newmail_notifier
drwxr-xr-x 3  501   80 4.0K Dec 22 10:20 new_user_dialog
drwxr-xr-x 2  501   80 4.0K Dec 22 10:20 new_user_identity
drwxr-xr-x 4  501   80 4.0K Dec 22 11:42 password
drwxr-xr-x 4 root root 4.0K Dec 27 13:12 persistent_login
drwxr-xr-x 2 root root 4.0K Oct 16 13:21 qtip
drwxr-xr-x 2  501   80 4.0K Dec 22 10:20 redundant_attachments
drwxr-xr-x 4 root root 4.0K Dec 22 11:38 settings
drwxr-xr-x 2  501   80 4.0K Dec 22 10:20 show_additional_headers
drwxr-xr-x 2  501   80 4.0K Dec 22 10:20 squirrelmail_usercopy
drwxr-xr-x 3  501   80 4.0K Dec 22 10:20 subscriptions_option
drwxr-xr-x 3  501   80 4.0K Dec 22 10:20 userinfo
drwxr-xr-x 4  501   80 4.0K Dec 22 10:20 vcard_attachments
drwxr-xr-x 2  501   80 4.0K Dec 22 10:20 virtuser_file
drwxr-xr-x 2  501   80 4.0K Dec 14 14:01 virtuser_query

Now isn't that something. All the plugins which were mentioned in the error log are the ones owned by root (I added them manually as they are not part of the original Roundcube installation).
As soon as I corrected the ownership of these plugin folders (and their files) / set them to the same user as the others, the plugins were loaded fine and no errors appeared in the error logs anymore.

Like I already mentioned, this worked fine on PHP 5.2.x but on PHP 5.3.x it seems to cause troubles.