File sharing broke itself very quickly.. I enabled Public Folder sharing, disabled need for password, copied a few files into it.

Next I tried to copy the files to 2 different Vista 32 machines & an XP machine

The first Vista machine managed to successfully copy the files, the 2nd would show the folders but no files and the XP machine just failed completely citing “You might not have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions. Not enough server storage is available to process this command.”

After a bit of googling I ended up modifying the following registry key

HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\Size

Set it to: 3

Source: lamielle.net

Apache 2.2 with PHP 5.2.6-2 on Debian fails to shutdown properly on one of my servers

apache2ctl stop or /etc/init.d/apache2 stop or equivalents would result in “waiting…………….” until a timeout and then the new process is launched anyway which fails because the port is already in use, apache2 never finished shutting down properly

Not sure exactly what the problem is, but downgrading to PHP 5.2.6-0.dotdeb.1 via DotDeb mirrors solved the issue

Hopefully it will be fixed in the next version/patch

I wonder what’s caused this sudden surge in attacks

find . -type f -print | xargs -n 20 rm

I noticed in my mail server logs that some emails weren’t getting SA scanned and tagged and wondered why.. they weren’t internal emails and should have been scanned.. then I remembered that there’s a size limit to the scanning

spam subjects list

spam subjects top 100

On one of my servers, syslog-ng takes care of the syslog.. the edits to this (syslog-ng.conf) comprised:

Before:

filter f_syslog { not facility(auth, authpriv); };

After:

filter f_syslog { not facility(auth, authpriv,mail); };

and also comment out this:

#log { source(src); filter(f_mail); destination(mail); };

On another one of my servers, the default syslog is in use.. the edits to this (syslog.conf) comprised:

Before:

*.*;auth,authpriv.none; /var/log/syslog

After:

*.*;auth,authpriv.none;mail.none; /var/log/syslog

and also comment out this:

#mail.*                         -/var/log/mail.log

now restart the daemons and your log files won’t have a shedload of duplicated information!

I’ve been trying to debug a problem with the zone transfer of a certain domain (turns out I had input the wrong secondary nameserver). I wanted get Bind8 to log basically everything.. so I stuck in a custom “logging {}” section in named.local.options but for some reason, the file was never created.

Unfortunately, it took me quite a while to realise that there was already a logging section in named.conf and that my section was being read but ignored (would give syntax errors if they existed in the new section but wouldn’t make my damned log file!)

I merged the two logging sections together in named.conf and it actually worked, the file being created in /var/cache/bind/

I decided to create a script which would scan the mail logs and list clients that tried to send SPAM, so that I could add them to a blacklist.

A brief spell of messing about trying to implement this made me realise that the easiest way for me to parse the log would be for AMAVIS to output the actual client IP. However, since the source can be faked in the mail envelope, I wanted Postfix to pass the client IP onto AMAVIS, which brings me to XForward.

XForward is an SMTP extension which allows a trusted client/server to pass on the original client IP to a destination server (which could pass this on further, etc.)

I spent a while wondering why AMAVIS wasn’t getting the XForward’d IP, eventually realising that it wasn’t implemented in the version that I was running.. trying up apt-get the latest unstable/testing version yielded a nice message telling me that e2fsprogs needed to be updated (which is not something trivial).. I therefore decided to manually update amavis to a version which didn’t require the Perl library update which relied on the e2fsprogs, etc, etc being updated (see here for more details)

Eventually I got the whole thing working but then I realised a small problem – spammers often don’t care about which prority MX they use, i.e. they’ll use a backup MX sometimes, trying to bypass filters, etc.

I decided to try to get Postfix on the backup MX to XForward the original client to the primary mail server. This turned out to be a complete ball-ache.. After hours of pissing about trying to get it to work, I decided to install the very latest version of Postfix on the backup MX – even though 2.1 onward (according to all the Postfix documentation) supports XForward… lo and behold it worked! So either the documentation is wrong or there’s a bug in the version of Postfix I was using… very annoying

Thankfully, it’s all working fine now and my blacklist is growing

However I have discovered that although the function is custom, Courier also has a method to produce the exact same digest using an 8 character salt (md5cryptredhat)

So that’s how it works!