Posts Tagged bug

SpamAssassin 2010 bug

Posted by on Saturday, 2 January, 2010

From :

I use SpamAssassin to filter the spam out of my incoming email. Last night I noticed that a legitimate email had a particularly high spam score. On further investigation I found that a rule named FH_DATE_PAST_20XX was triggering:

* 3.2 FH_DATE_PAST_20XX The date is grossly in the future

I checked the Date header of the email and it looked totally fine to me. It had just changed from the year 2009 to the year 2010. Could that be a coincidence? A quick look in /usr/share/spamassassin/ turned up the rule:

header FH_DATE_PAST_20XX Date =~ /20[1-9][0-9]/ [if-unset: 2006]

Oops. That regex matches on any year between 2010 and 2099. I googled for the rule and came across this:

In the comments it mentioned the problem which I found: “Note: the current rule in 3.2 will start matching legitimate dates from 2010-01-01. See issue #5852.” Looking at issue 5852, the problem was first identified on 2008-Nov-05 and was “fixed” in CVS on 2009-Jun-30. I’m using the standard stable Debian package which doesn’t contain this fix yet so I had to stick the following in my file to apply a score of 0 to it:

score FH_DATE_PAST_20XX 0.0

I think a lot of systems will be experiencing false positives on their ham because of this at the moment. It is a particularly high scoring rule considering that the default threshold is 5.0.

As I understand it, rules aren’t distributed with SpamAssassin as of the next version (3.3) so hopefully problems like this wont happen in future. The “fix” which was supplied for this problem five months ago was to update the regex so it matches 2020-2099 instead.

You can read the thread I started about this issue on the SpamAssassin users list here. It’s the one started at “Fri, 01 Jan 2010 00:57:37 GMT” with the subject line “FH_DATE_PAST_20XX”

Ubuntu networking bug updating to Jaunty

Posted by on Thursday, 10 September, 2009

We had a customer email in after updating to Jaunty recently. They said the following

Hi guys, I upgraded my VPS a little while back to Ubuntu Jaunty (because I was several versions out of date and the apt repositories had gone away.) I never actually rebooted the machine afterwards though because it wasn’t a good time to potentially interrupt email. I finally got around to doing that, and the VPS won’t come back onto the network. Logging in over the console, it looks like there are no network interfaces configured. A few other things don’t feel right (eg, dmesg tells me that the current tls library or perhaps libc isn’t xen-friendly.) but mostly everything *looks* like it’s ok but doesn’t have a network interface.. services that want to resolve hostnames didn’t start up, etc. Trying to dig into the problem, it looks like there are no modules installed for the kernel, but this is where my expertise runs out.. I don’t know enough about Xen to know if everything was just precompiled into the kernel, or if I blew away my kernel modules during upgrade.

I was curious so logged in via the console .

I ran ifup and got the following errors

root@charon ~ # ifup eth0
ifup: failed to open statefile /var/run/network/ifstate: No such file or directory

so i checked and /var/run/network did not exist. I fixed this

root@charon network # mkdir /var/run/network/
root@charon network # ifup eth0
* if-up.d/mountnfs[eth0]: waiting for interface lo before doing NFS mounts
root@charon network # ifconfig
eth0 Link encap:Ethernet HWaddr aa:00:d6:a1:5e:e4
inet addr: Bcast: Mask:
inet6 addr: fe80::a800:d6ff:fea1:5ee4/64 Scope:Link
RX packets:56 errors:0 dropped:0 overruns:0 frame:0
TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:5447 (5.4 KB) TX bytes:1074 (1.0 KB)

The file system on Ubuntu in /var/run is a virtual filesystem on Ubuntu, I googled and came across this post here which clearly logs the bug, and a fix.

The fix i applied which was adding the following into /etc/init.d/networking

[ -d /var/run/network ] || mkdir -p /var/run/network

This checks if the dir exists and creates it if it doesn’t.

This does fix the problem but its a bit of a hack. I noticed a link later on down the post which took me to . This link had a bit more technical information. They said look for the following files and remove them.



Upgrading Virtualmin GPL to Virtualmin Pro Centos bug fix

Posted by on Wednesday, 1 July, 2009

Virtualmin is a fantastic piece of software which allows the not-so-techy run a full hosting server nicely,  however I’ve come accross a bug that seems to happen mostly in Centos 5 when trying to upgrade and you happened to have used the rpm to install

This is how you do it.

Login to Virtualmin. Click on System Settings . Click on “Upgrade to Virtualmin Pro” and enter your serial number etc.

Now if you get the following error

Failed to upgrade to Virtualmin Pro : No Virtualmin GPL repository was found in /etc/yum.repos.d/virtualmin.repo

Put this into /etc/yum.repos.d/virtualmin.repo

name=Red Hat Enterprise $releasever - $basearch - Virtualmin

name=Virtualmin Distribution Neutral

Then try again. It should all go well now for you and be able to update.