Bah, back to Rails! (by alaric)

Gah. I was happily thinking that I was slowly getting rid of my last Ruby on Rails projects, when I've ended up on another one. Despite extensive hype, Rails is a bit of a dog... Ruby has some niceties, but also has a lot of misfeatures, and the implementation is still maturing. But Rails is dreadful, dreadful code. It helps you if you're working within its limited model, but as soon as you come across a problem that doesn't fit into that model, you're quickly working at pretty much the same level as PHP and everything else: writing Ruby code that is called upon an HTTP request and has to output some HTML back, albeit with access to a reasonable template language... And it's full of bugs and gotchas that keep you up all night screaming "Why doesn't this wooooorrrkkkkk?!?!?!?".

You see, the project is a major extension of a Rails project we'd mainly finished. We had the choice of rewriting the whole thing in something else (which would involve some time spent catching up with where we already are rather than producing anything new), continuing with Rails, or making a hybrid system, writing the new parts in something else while reusing parts in Rails (which would be a bit ugly).

Since the client wants to see interesting new things appearing after the first week or two, sadly, it had to be Rails...

Samuel Pepys (by alaric)

I'd always been vaguely aware that Phil Gyford, an interesting fellow I had the pleasure of meeting through my time with UpMyStreet.com nearly a decade ago, ran a web site that told you what the famous diarist Samuel Pepys was doing three hundred and forty three years ago today.

However, it wasn't until I saw his blog posting about it today that I realised just how much work he's put into it.

WOW.

Well worth a visit, even if you're not into history...

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 😉

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!