GNU/Linux

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.

For the sake of documentation, I list the enhancements I configured for SpamAssassin since February:

• I use SA’s internal sa-update script nightly to update the standard rules that are changed between the releases of new versions. The standard channel is updates.spamassassin.org. The files automatically go into /var/lib/spamassassin/$VERSION and Debian automatically finds it, as can be seen from a call of spamassassin -D --lint.
• In addition to the previous, I call sa-compile to compile the body rulesets into binary form. This makes checking of body rules more efficient. To enable SA using these binary rules in /var/lib/spamassassin/compiled/$VERSION, I have to activate the Rule2XSBody plugin in /etc/spamassassin/v320.pre.
• I don’t update the SARE rules against stock spam manually anymore, but also use the provided sa-update channel for it.

Recently, PDF spam has become “popular”. Therefore I enabled some more things to accomplish this:

• The ClamAV virus scanner provides inofficial databases by Sanesecurity to catch various sorts of spam. So there’s actually some kind of redundancy, as the virus scanner and the anti-spam filter are now sharing some responsibility. As not a single virus occured at my site in the recent months, this has now changed in some way.
• I installed the PDFInfo plugin from SARE and enabled it in /etc/spamassassin/init.pre.

Sure, as soon as we catch enough of that new PDF spam, spammers might change to some other document file format, such as DOC or RTF or even ODF, and we are forced to scan those attached documents for spam text or even for contained images that contain spam text, what we are already considering with FuzzyOCR. There must be some better way, actually.

However, I had to reduce the score of the Botnet plugin, as the default value of 5 points is way too high. Maybe I should add the plugin that checks the operating system such that only botnet clients using that Windows crap get high scores.

The fight continues.