This morning’s spectacular time-waster was an accidental DDOS attack, which was probably intended to be a comprehensive trackback-spam attack. The designers of the attack actually weren’t even hammering the box nearly as hard as an intentional DDOS attack would have – it appeared that there were about four IPs involved, and the actual frequency of post requests sent to tb.cgi was under five per minute.

What they couldn’t know is what happens to perl on my creaky old antique here when even one page-rebuild request hits MT. The processor pins for about 30 seconds; so for each request sent that actually got through, the estimated time to completion is greater than 30 seconds. As the requests piled up, the machine began to buckle, with GUI input crawling and eventually displaying lag of up to four minutes from click to event and shell commands queueing up for a similar wait time.

Initially I began disabling sites and web-side apps that I regarded as unlikely suspects just to get them out of the way, but as soon as I looks at the MT apache logs I could see what was going on. I eventually just physically removed the comment and trackback scripts from the served directory, which immediately removed the load on perl and eventually allowed the server to settle down.

So, I guess, tonight I look for a widget to allow me to deal with trackback more effectively. The best solution would be to globally turn off trackback and then turn it on for a few appropriate entries. Setting expiry on old posts would also be great.

Any of you out there with MT3.x who have implemented some kind of trackback control mechanism, feel free to, uh, email me.

Comments should be restored and operational this evening.