After yet another mysterious Perl-related SNAFU, I decided that it’s time to say goodbye to the venerable “Blosxom” engine. As of this entry, I don’t plan to add any new entries to this blog, and I have kludged blosxom.cgi into working, however temporarily, just so that I can do one last final static HTML rendering of all the posts.

The result is that all the existing content should stay where it is, and all links should remain unbroken. I have a terrible hatred for people who break links or pull content down out of sheer laziness; as it costs very little to keep a bunch of static HTML files around, I see no reason not to do so — without the live CGI running, there’s very little security issues, and it just seems like The Right Thing To Do, on the off chance anyone finds some of my old posts useful or interesting.

Going forward, I plan to spin up a new site using Jekyll, and may in fact import all the old entries from this blog into it (making them instantly a lot less ugly, since I don’t plan to roll my own HTML and CSS this time around). However, those will end up, at least in my current plan, in a different URL namespace (perhaps /blog/ instead of /weblog/ — the latter seems a bit dated by modern standards anyway), so that all the old links will continue merrily onward until either the SDF goes down for good, or the heat death of the universe.

Anyway, if there’s anyone else out there using Blosxom in 2017… good luck. My recommendation, given modern hardware and storage capabilities combined with the hostile security environment the Web has become, is to use it as a static site generator (similar to Jekyll) rather than a live CGI with mod_rewrite as most of us start off using it originally. If you wanted to give a little nod to modern conveniences, you could certainly trigger the static regeneration via a Git hook, just like Github does with Jekyll.

When I first started this blog, the idea of a dynamic site without a database seemed pretty cool. Today, the idea of a site without a database is still cool, but I’ve become gradually less and less enthused about the idea of dynamic sites in general, largely because of the security/maintenance tradeoffs. If you don’t have time to maintain a secure dynamic site, you don’t have time to maintain a dynamic site. Static HTML, in contrast, is much easier as long as your webhost is reasonably competent.

But there’s not much compelling about Blosxom today, given that Jekyll and a variety of other static site generators exist, and have a much more robust ecosystem of themes, plugins, and documentation available.

I can’t say that Blosxom owes me anything at this point. It ran this blog for more than a decade, and that’s longer than most pieces of software ever get to exist in production.

Well, another month has gone by, and I still haven’t migrated this pile of bits to a better blog engine. And yet again, Perl + Blosxom + the plugins I’m using shit the bed.

The issue this time, for future reference, was:

File is not a perl storable at
/usr/pkg/lib/perl5/vendor_perl/5.24.0/x86_64-netbsd-thread-multi/Storable.pm
line 383, <FILE> line 628, at
/blosxom-plugins/calendar line 322.

The solution, for the moment, was to simply delete the Calendar plugin’s cache (that’s what’s being referenced on line 322) and allow it to regenerate.

Why this keeps happening, I’m not sure. I hate to invest the effort to figure it out, when I may well be the only person left on the Internet using this particular combination of software, and the proper solution is clearly a migration to another platform.

But if you happen (by some chance) to run into this yourself, and this blog hasn’t crashed (or you’re reading somebody’s helpful cache of this page!), that is seemingly a temporary fix. A hacky fix would be to set up a cron job to periodically clear the Calendar plugin cache, which would at least put an upper bound on the amount of downtime that the problem can cause, but that’s … pretty ugly, even for me, and I’m largely immune to opposition to solutions on aesthetic grounds these days.

I realized today that this blog had crashed, again. It’s becoming obvious that I’m going to need to find some other hosting / server-side engine solution, because the downtime and associated maintenance (mostly due to Perl’s constant non-backwards-compatible changes, from what I can tell) are really not working for me anymore. I will try, as a Good Internet Citizen, to keep all the posts up and keep the URLs stable, but who knows what will happen. I may well just render the existing blog corpus to static HTML pages and call it quits. It has been a fairly good run at this point.

I’m already getting penalized by Google for not being “mobile friendly” enough, which I think I’ve decided I don’t really care about (in fairness, the blog pages look mostly OK on my Android device), but it’s yet another task that one has to do now if you want to put content online. The bar has gotten a lot higher from when I started this thing, at least it seems.

Anyway: the culprit today was a corrupted cache file used by the Blosxom Calendar plugin. Chasing this down was made more complicated than it needed to be, because by default the Calendar plugin stores its cache in a dotfile, which most of my other plugins don’t. No clue why; that seems like slightly unfriendly behavior.

I tweaked the configuration a bit so that the file is now regularly visible. Anyone else using Blosxom+Calendar may or may not be interested in the change.

Apparently I’m one of the few people still using Blosxom to run their blog, the rest of the world having moved on to shinier solutions in the intervening decade or so, but I’m a curmudgeon who hates change. So here we are.

Quite a few of the sites that used to host various Blosxom plugins have gone offline, and finding new modules and their documentation is becoming challenging. Most of them aren’t being actively maintained, either.

To fix a few problems that I’ve run into myself, I created GitHub projects for two plugins, in order to make them more accessible and also perhaps encourage other people besides the original maintainers to work on them and contribute fixes. It seems like a low-effort way to keep the platform as a whole a bit more healthy than it would otherwise be.

• “Feedback” plugin, originally by Frank Hecker.
  Used to provide the feedback / comment form at the bottom of each article page, which are moderated via email messages sent to the site owner for approval. I have modified the latest ‘master’ version in order to prevent errors with newer versions of Perl; these changes are currently in the ‘dev’ branch, and feedback (ha) on them is welcome.
• “Calendar” plugin, originally by Todd Larason.
  Provides the small calendar in the site’s navigation bar, allowing access to past articles by month and year.

In addition, there are some large collections of Blosxom plugins on Github; the biggest is maintained by Blosxom Fanatics in the Plugins repository. However, the repo only has a single commit, and seems to be more of a historical archive than a basis for continued development.

As part of making comments great again, I did a little hacking on Frank Hecker’s Feedback plugin for Blosxom in order to make it work with Perl 5.22, which is what the SDF currently uses by default.

It’s not exactly great moments in software engineering or anything, but in case anybody else was running into the same problem, I put the changed — I won’t go so far as to say “improved”, since I’ve barely tested it yet — version up on Github.

For now, the changes are only in the “dev” branch, while “master” contains Hecker’s original:
https://github.com/kadin2048/blosxom-feedback/tree/dev

Anyone else still using Blosxom and the Feedback plugin is encouraged to play with it and test it out. The most important change is probably this one, which may or may not fix a parameter-sanitization vulnerability. I have no evidence to suggest that Feedback actually had the vulnerability; the problem was discovered in Bugzilla, which also uses the Perl CGI module, which led to the addition of a security warning.

The (potential) issue that this solves is discussed in the article “New Class of Vulnerability in Perl Web Applications” by Gervase Markham, and the change to CGI.pm is mentioned in the comments.

Some other changes made to Feedback include adding support for SMTP Auth, and the ability to specify a port for SMTP mail submission. These are useful if you need to use a standalone mailhost that requires authentication and use of port 587, which is increasingly common in shared-hosting environments.

While poking around in the blog’s configuration files in order to fix the error that Perl had decided to throw with the feedback plugin, I noticed that Google was apparently unhappy with the lack of “mobile friendly” features. (In other words, it looked like shit.)

Not being one to argue with Google, I did the bare minimum required to make the site not-quite-terribly offensive when viewed from a phone or tablet. Not really because I think many people will actually use it that way, but mostly because Google now dings you in your search rankings if you don’t, and it’d be nice if some of the problems and solutions I’ve documented here were at least visible to people who are searching with the right terms.

So, there you go, Google. Progress.

Do try to contain your excitement. The fact that comments had been failing silently for so long, and nobody seemed to notice and/or care (least of all me) is probably suggestive that it wasn’t really a problem that needed to be solved.

Nonetheless, it was easier to solve the problem than it was to just remove comments, and once or twice in the past I’ve had comments that were actually useful and insightful, so what the hell. They ought to work now.

If for some reason you get an error when you’re trying to comment (on an article that’s less than 90 days old), feel free to drop me an email.

I finally got around today to making some minor tweaks to the site; I changed the front page a bit, to make it clear that most content is here in the blog and not anywhere else, and I monkeyed around with the CSS that’s behind the scenes a little, to try and make the site look less ugly on mobile browsers.

Unfortunately it’s still pretty ugly on mobiles, and I should really do a lot more, but that would involve digging into the blog templates that I haven’t looked at in a couple of years, and that just seems a bit too much like work for a hobby project that I’m pretty sure nobody reads anyway. So for now, it is what it is.

Eventually I may stick a “Contact Me” link on the main index page, if I ever get around to putting together a decent webform that won’t get me spammed, allow others to use it to send spam, or be too onerous for casual drive-bys to use. What I’m thinking of is something that automatically encrypts messages sent via the form to me, using my PGP public key; that would make it pretty useless for most kinds of spam, as well as giving it some security (if the encryption were done in JavaScript, on the client side). Maybe sometime later this month or next, if work is slow.

If anyone happens to notice any bugs in the CSS, please let me know by posting a comment below; I have tried to test it on a few browsers (and it’s pretty dead simple to boot), but I’ve heard IE has some strange bugs in its CSS rendering that can make even simple layouts barf.

Since I think the probability that anyone out there actually reads this thing is fairly low, at least right now, I haven’t bothered to do much in the way of making it easy for readers to contact me. I realize this is semi-obnoxious behaviour, and I’m working to fix it.

I so far have hesitated from putting an email address up because I know it would just become flooded with spam anyway, and because people coming to this site from Slashdot.org can already get an email address for me fairly easily there, and SDF members can simply send me an email address within the system.

But just in case there’s anyone out there who isn’t a member of those two groups, and would like to drop me a message, here’s a ROT-13 encoded address you can feel free to use: “oybt1.xnqva@fcnztbhezrg.pbz”. (Yes, it’s a Spamgourmet address.)

In the very near future, I may set up comments here on the blog. If all goes well and I don’t get too inundated with spam, that will probably be the best way for random passers-by to comment or respond, should they want to.