Excessive mail filtering (by alaric)

I've been taking advantage of some Christmas downtime to bring the Warhead mail system up to scratch.

We now have many layers of defence.

1. When a remote mail server tries to connect to us to send email, if they are a known blacklisted spammer or have a wrongly configured mail server, we reject them up front.
2. If they get through that, then unless they are a known good mail server, they are told to go away and come back later. Many spammers don't bother retrying mails if asked to, so this cuts out a lot of spam.
3. If they are a known good mail server or they do come back later to redeliver the email, then the message is accepted.
4. It's then sent through a content filter, which checks it for known bad signatures (viruses, scams, some spam, and phishing attempts). If it matches any, it's bounced back to the sender.
5. The content filter then runs it through SpamAssassin's battery of message scoring tests, which rate the chances of the message being spam. If it looks spammy, it's marked as looking spammy with ***SPAM*** in the subject line, but still delivered (since SpamAssassin's tests are statistical in nature, they can snag false positives)
6. Finally, the message is forwarded on, or delivered to a local mailbox, depending on the recipient.

From my existing statistics, I know that of about 15,000 messages a day, 13,000 are stopped by the first step alone (which is good, since blocking at this stage saves a whole lot of resources on our mail servers).

I'm looking forward to seeing how many of the surviving 2,000 make it past the rest of the filters 😉

the fatal error (by sarah)

I thought that as Al had been doing his own luandary here in London that it would be safe to entrust basically all the cloths I have with me to him to wash - there is an inbuilt washer dryer and I wanted nice fresh cloths for tonight.

As a pair of my cords where in there I asked that the tumble dryer be put on for a bit longer as they have a nasty tendency to stay damp. Several hours later I notice that the cloths are still tumbling. They are baked they are screwed - he also put tooo much stuff in so they all wrapped around each other baking the creases in.

So I now have no cloths to wear tonight - great start to the new year - I'm not sure if at least one pair of the trousers is actually salvagable.

Sigh - haven't decided if this is more of a disastor than last time he did something similiar :/

Not really sure what I am going to do about to night now at all :'( Oh and in writting this post I have just found another bug thing in the blog - so bare with us whilst it all resumes back to normal.

Making custom power cables (by alaric)

I take great pleasure in making custom power cables for things. It's very satisfying.

Lately, I've been having fun with this. Firstly, I was frustrated when visiting a datacentre that had only IEC power connectors, rather than UK standard 13A sockets - there was nowhere to plug my laptop in.

So, I've made a special adaptor cable:

Job done!

Nextly, at work, we have two 16A managed power distribution units, which have 24 outlets on them, each individually controllable via the network. They're lying around, surplus to requirements. We also have two 32A units in use in the racks - and more than 24 devices that need plugging into each.

Now, the outlets are mainly IEC C13 ten amp ones, but there's a small number of IEC C19 sixteen amp outlets, so we struck upon the crazy idea of attaching the 16A units to the 16A outlets on the 32A units. Thing is, the 16A units have 16A industrial plugs on them - not C20 plugs that go into C19 outlets.

So, once again, I made an adapter cable:

Well, two identical adapter cables, to be precise.

Lots of fun.

Fixed network access from PHP apps – but broke WordPress even more… (by alaric)

I upgraded to PHP5 from PHP4, in desperation, and lo, PHP apps can now once more connect to the network.

I'd gone as far as to ktrace an httpd process running a PHP app, and found that it produced an identical syscall trace to PHP run from the command line - up until it tried to read back from the socket, whereupon it gave a one-byte buffer, so read only the first byte, then hung thereafter. While when run from the CLI, the same PHP code gives a buffer of 0x2000 bytes and works fine.

So, I tried the one last thing I could think of (having failed to manage to convince gdb to attach to a running httpd child process) and moved to PHP5.

And, wow, it worked!

At the cost of breaking all our WordPress blogs. They don't show article bodies any more, and output endless complaints to the error log.

Still, now outgoing network access is fixed, webmail works again, my RSS aggregrator works, and it's just occured to me that the recent overwhelming flood of blog spam I've had has probably been due to Akismet being unable to reach its server!

Big server upgrade! (by alaric)

Whew. I'm just in the final stages of migrating love.warhead.org.uk's backend storage over to a new (much bigger and faster) server.

This stage consists of poking at the things that aren't working right, and finding out why.

For example, my blog seems to be showing the very first posts we ever made to it on the front page...