Stephan Paukner :: syslog

Fotobuch-XXL.de is one of the few providers (if not the only one) that has a native Linux app to create and order photo books. It is annoying that most services only provide versions for Win or Mac, and even web apps are rare. Unfortunately, Fotobuch-XXL only provide their app for the Ubuntu and OpenSuse distributions. But, as Ubuntu is just a derivative of Debian, it should actually not be too complicated to also install the package on Debian. Indeed, it isn’t:

One just has to take care that the Python version in Debian ‘lenny’ is 2.5, and not 2.4, thus forcing you to choose the corresponding package source for Ubuntu Feisty (7.1) and upwards:

After updating your package list, you can already find fotobuchxxl-studio. However, it also depends on python-wxgtk2.8, which is only available in Debian’s own experimental section. After activating this source, you’re finally able to install fotobuchxxl-studio.

Note that I just tried whether the app actually launches, I neither really used it nor did I order a photo book. Yet.

Recently I wondered why Google Earth stopped working on my 64-bit Debian machine when I upgraded Google’s app to version 4.3. It claimed to find no internet connection (“Error code: 29”), although everything was working fine before. The web finally unveiled the solution: The app needs the lib32nss-mdns package. Installed that, problem resolved!

CUDA is a technology by NVIDIA to accelerate scientific computations by the help of GPUs. Unfortunately, Debian isn’t supported officially yet. The toolkit for Ubuntu should come closest to it. First, the toolkit has to be installed, e.g. to $HOME/share/cuda, and then the SDK, e.g. to $HOME/share/NVIDIA_CUDA_SDK. These two paths shall be referred to as $CUDA_PATH and $SDK_PATH in the following. GCC and g++ have to be downgraded to version 4.1 (from ‘etch’), as 4.2 (from ‘lenny’) doesn’t work with CUDA yet.

Like described in $SDK_PATH/ReleaseNotes.html, $CUDA_PATH/bin has to be in the $PATH and $CUDA_PATH/lib in the $LD_LIBRARY_PATH. Unfortunately, this isn’t enough for Debian to successfully compile the examples (via cd $SDK_PATH && make): The $CUDA_INSTALL_PATH in line 38 of the Makefile $SDK_PATH/common/common.mk has to be corrected to the $CUDA_PATH.

To compile the GLUT code, the development package freeglut3-dev has to be installed. With that it’s now possible to compile the examples; the binaries go into $SDK_PATH/bin/linux/release.

In short: Debian lenny’s current libc6 version 2.7 doesn’t work on kernel 2.6.9 with SMP enabled. Downgrade to libc6 2.6 if you can’t change the kernel. You might have to do this on a non-2.6.9 (or >2.6.9) system.

Here’s the story: I use to maintain a duplicate system (on real hardware) with the same package structure as my virtual private server to be able to run through the upgrade procedures in advance. Yesterday, the regular upgrade included a new libc6 package going from 2.6.1 to 2.7. As everything worked well on the duplicate system, I started the apt-get upgrade on the virtual machine. But then dpkg crashed with an “Unknown error 530”. I could still navigate through the file system, but directory listings returned e.g.

and the system slowly began to “fade”. I tried a reboot, but the system didn’t come up again, showing a problem with the quota in the log (“Running vzquota off failed... vzquota: (error) Quota off syscall for id 12345: Device or resource busy”).

I opened a ticket at my provider, and the guy was telling me that the system were completely broken and had to be reinstalled! I was shocked and didn’t believe him. The virtualization engine provides a repair mode, but as I chroot’ed into the mounted root directory of my system, those errors came up again.

I asked the support guy to have a look at that article, but he didn’t seem to find it useful. As it became late afternoon and their support went off duty, I synced the mounted repair directory to my duplicate system overnight (about 5.6GB; I had to install rsync into the temporary system). This should enable me to chroot there and make experiments.

As I finally chroot’ed into that directory this morning, the system was working perfectly! So it couldn’t be completely broken. Another inquiry on Google unveiled this new posting. So the problems are really due to the new libc6 version! It worked on the duplicate system as it runs on kernel 2.6.22, and the virtual server depends on a custom 2.6.9! And that’s also why I couldn’t repair it with their repair system, as it uses the same kernel! On the duplicate system I looked into /var/log/dpkg.log what the previous version of libc6 was, and downloaded the libc6_2.6.1-1+b1_i386.deb from a Debian mirror. I did the downgrade and synced the directory back to the virtual server’s repair directory. I went out of repair mode and—lo and behold!—the system came up again! I also had to downgrade the locale package to match with the old libc6 version.

The support guy was glad that I provided them with a solution for a problem that could emerge for other customers as well. I’ll better stick to Debian ‘stable’ as soon as it is out.

Addendum 12/08: The correct way to fetch previous package versions is via the Debian snapshot archive, as they’re removed from the official mirrors within a short time.

I wanted to do a regular upgrade of xserver-xorg-core in Debian ‘testing’. Unfortunately, dpkg complained about a file ./usr/lib/xorg/modules/extensions/libglx.so not being present, although Nvidia’s installer had placed it right there and it was still present. Because of that broken upgrade my X server couldn’t start anymore. Removal of Nvidia or xorg didn’t change anything on this situation. With Google I saw that someone found a solution by installing nvidia-glx-legacy temporarily. Here’s what to do:

1. Remove Nvidia by calling sh /path/to/NVIDIA-$SOMETHING --uninstall.
2. Install nvidia-glx-legacy. This package depends on a linux-image-2.6.18-n-486, what will therefore be installed and will replace your current symlinks /vmlinuz and /initrd.img.
3. Install/upgrade xserver-xorg-core. (The top-dependency would be xorg).
4. Remove nvidia-glx-legacy and the above mentioned linux-image-$SOMETHING again and purge their configuration files (Key “_” in aptitude).
5. Restore your original symlinks /vmlinuz[.old] and /initrd.img[.old]. You’ll have to run lilo. Run lilo. Did I mention to run lilo?
6. Reinstall Nvidia and restart gdm.

Recently, I had another issue with the Nvidia installer: It didn’t work anymore due to the activated paravirtualization feature in Debian’s default kernel what conflicts with the GPL-incompatible module nvidia.ko. Here’s a solution I found in the web:

1. Install linux-source-2.6.xx-n-686.
2. Uncompress /usr/src/linux-source-2.6.xx-n-686.tar.bz2.
3. Delete the symlink /lib/modules/2.6.xx-n-686/build and make it new by ln -s /usr/src/linux-source-2.6.xx /lib/modules/2.6.xx-n-686/build.
4. Copy .config from headers to sources by cp /usr/src/linux-headers-2.6.xx-n-686/.config /usr/src/linux-source-2.6.xx.
5. In the sources dir make menuconfig and disable paravirtualization in section ‘processor features’.
6. make prepare.
7. make scripts.
8. Now compile and install Nvidia with its own installer.

I want to keep track of the spam scores that show up in my /var/log/mail.log on my Debian Etch machine. My idea was to run a shell script grep’ing the wanted info out of the mail.log right before that file is to be rotated. logrotate provides configuration options for how and when log files should be rotated. This includes a possibility to run a script right before and after the rotation is done. So, I created a configuration /etc/logrotate.d/mail like

sysklogd is Debian’s package containing syslogd and klogd. The syslog itself already cares for rotating the basic log files, and this includes /var/log/mail.{log,info,warn,err}. sysklogd contains the cron-jobs /etc/cron.daily/sysklogd and /etc/cron.weekly/sysklogd, both of which contain logic for rotating the system’s log files. To obtain the list of the log files, the command syslogd-listfiles is issued in both of the scripts—the weekly script uses the option --weekly. When I issue syslogd-listfiles, I only get /var/log/syslog as answer, whereas with --weekly I get:

So I have to use the -s switch to exclude mail.log and mail.info such that logrotate can take care of them. As I also have a separate config for /var/log/messages in /etc/logrotate.d/messages, I modified the call of syslogd-listfiles --weekly in /etc/cron.weekly/sysklogd to

I finally wanted to enable my users to relay mails via my own MTA, as it’s quite comfortable to be able to use the same outgoing mail server no matter what computing device you currently use or where you currently are. About three years ago there were no solutions enabling SMTP AUTH for Postfix without recompiling packages, so I had to wait until today where such features are now officially available within Debian. I found several HOWTOs about configuring SMTP AUTH with Postfix on Debian Woody or Debian Sarge, but things have changed (or will change, as Etch hasn’t been released yet). The Postfix version in Sarge is 2.1, whereas in Etch it’s 2.3. This is how I did it:

First, note that you don’t have to patch or (re-)compile anything. Etch’s Postfix package already supports TLS! First, I cared about configuring authentication with SASL, and after that I restricted authentication to TLS only. This makes debugging easier during the process. Because encryption already happens at the TLS-layer, I don’t need MD5 authentication and can stay PLAIN.

Today I finished migrating my server to a new system. The LAMP-site consisting of 3 domains, which also runs an MTA and mailing list software, has been moved from Debian ‘woody’ to Debian ‘testing’ (alias ‘etch’). Insiders know that this is quite a big jump, leaving out the ‘sarge’ release. The main reason for this move was dying hardware: I expect either the graphics board or the SCSI-controller to be the cause, as they both are from 1998. Once in a while some system processes ended up in a segmentation fault, so I looked for a new (used) PC, which should become the successor.

It was a good opportunity to clean up the system, as the old one had its roots in a time when I made my first steps with Debian and wanted to maintain everything using ./configure && make && make install. Now, I want to avoid this and use the original Debian packages, because these days some commonly used additions are now officially available. Also, with Debian ‘testing’, there won’t be so gigantic delays between new releases of packages.

The interesting increments in the version numbers are: MySQL 4.0.20→5.0.18, Postfix 1.1.11→2.2.9, Courier-IMAP 1.4.3→3.0.8, Apache 1.3.31→2.0.55 and PHP 4.3.8→5.1.2.