MailScanner not working after upgrading from etch to lenny

I was just upgrading a spam filter from Debian etch to lenny. After the upgrade, MailScanner seemed to be running but wasn’t processing the queue.

When running MailScanner in debug mode I noticed these errors:

Variable "$FIELD_NAME" is not imported at /usr/share/MailScanner/MailScanner/Message.pm line 6064.
Variable "$FIELD_NAME" is not imported at /usr/share/MailScanner/MailScanner/Message.pm line 6067.
Global symbol "$FIELD_NAME" requires explicit package name at /usr/share/MailScanner/MailScanner/Message.pm line 6064.
Global symbol "$FIELD_NAME" requires explicit package name at /usr/share/MailScanner/MailScanner/Message.pm line 6067.
Compilation failed in require at /usr/sbin/MailScanner line 79.

To fix it, open the Message.pm file and this code to line #7852 (pico /usr/share/MailScanner/MailScanner/Message.pm):

our $FIELD_NAME = '[^\x00-\x1f\x7f-\xff :]+:';

so that lines 7852 – 7854 should be like this:

package Mail::Header;
our $FIELD_NAME = '[^\x00-\x1f\x7f-\xff :]+:';
 
sub extract

Restart MailScanner and everything should be fine now.

Hobbit doesn’t recognize last apt-get update

After installing the hobbit-plugins package, all my lenny servers were marked red on the hobbit server and the error message was: “Last apt update: 175.7 day(s) ago”.

The reason is that the hobbit-client relies on the file: /var/lib/apt/lists/lock but apt isn’t updating that anymore.

To fix this I created a cron job to update apt-get every night and update the /var/lib/apt/lists/lock file (crontab -e)

0 4 * * * /usr/bin/apt-get update 1>/dev/null && touch /var/lib/apt/lists/lock

Debugging logrotate issues

If your log files aren’t automatically rotated by the logrotate program there are probably some errors in the config files located in /etc/logrotate.d.

To find out where the error is, run this command:

logrotate -d -f /etc/logrotate.conf

You will see some debug messages on the console and hopefully a error that will lead you to the faulty lines in the config. In my case there were duplicate entries for /var/log/mail.log shown in the debug like this:

error: rsyslog:13 duplicate log entry for /var/log/mail.log

Re-map user to login in SQL server after restoring or attaching database

Re-map database user to a login in SQL server after restoring or attaching database

When restoring or attaching a database to a new or different Microsoft SQL server the logins and mappings to the database users are lost. If you create the logins again you’re not able to map the users because they already exist in the database:

User, group, or role '{login}' already exists in the current database.

Continue reading