stblogs.org is over the hump, with regard to our technical troubles this summer.
A word of apology to commenters and blog authors who were inconvenienced by them. Our web hosting provider at the time, page-zone.com, had enabled the Apache web server mod_security feature in a way that I consider indiscriminate, causing us trouble, and gave up all too easily on an attempt to diagnose the cause.
Commenters and blog authors were frequently getting "no access" errors from the www.stblogs.org server, and it took me a while to understand the source of our troubles, let alone to take corrective action.
To resolve the problem I moved the web server to a home-based machine and dropped PZ's service. The home server has its own weaknesses (e.g., occasional disruptions to my DSL service), but is bringing results definitely better than the service we were getting from PZ in July and August.
For you fellow web admins, here's where the problem was: the package of rule sets that comes standard with mod_security aims to protect the web server by aggressively blocking user actions that might attempt to upload malicious code (Javascript, etc.) to the web site, and even blocks many uses of HTML tags in user-entered data. A few of the rules are a problem for a content management system (CMS) whose very purpose is to create web pages containing HTML and Javascript.
The mod_security documentation actually includes a warning about using those rules on a web server running a CMS, so if only the well-meaning folks at PZ had read the friendly manual, as we say in the IT biz, and followed it, we'd still be their customer. Maybe.
Two benefits from running stblogs.org on a home server instead of that commercial hosting provider: (1) although this server is a modest machine, we no longer have to suffer performance troubles from other customers' activity; (2) I can now modify the system firewall and mod_security rules to block spam-commenters more effectively and quickly. I'm also running the server on a system with redundant disks now, which should help us keep going in the event of an occasional disk failure.
For the curious, the server is a 32-bit Athlon XP 2200+ (1800 MHz) with 512 MB memory, running Mandriva Linux 2006.
Leave a comment