I actually began the process of migrating my domains (willfe.com, willfe.net, and willfe.org) over to a different registrar that supports dynamic IP addresses in their DNS service last week, but because of a screwup at the current registrar (sigh … so nice of their “protected domain services” to “forget” to forward mail to me…) I had to cancel that transfer and start it again, but this time the confirmation mails actually arrived and so the move is officially in progress.
I’m told that the registrar switch doesn’t actually kill anything in DNS but I don’t completely trust this; it is entirely possible that the site, or mail to it, or the domain itself might temporarily vanish if something goes wonky. Because we live in a world occupied by humans, something is likely to go wonky 
Consider that fair warning that there might be an outage over the next couple of days.
Right, sorry, my nearly-nonexistent readers, for the outage this afternoon/evening. I made one tiny little change in my server’s Apache configuration:
ServerName willfe.com
…which proceeded to completely piss it off for reasons I will likely never fully comprehend. I’d normally never admit that, but since changing the directive to read
ServerName willfe.org
totally fixed the problem, I am officially confused, and it made one of my eyeballs fall out.
Jumping on the bandwagon about 3 years too late (heh) I’ve installed the Pingback module into this Drupal site to enable Willfe.com to receive and send pingbacks. With a bit of luck the installation has actually gone right (it seems to have gone just fine) and things are running smoothly. This post is mostly just being made to test the thing and to provide the very first Pingback from Willfe.com — to the module author’s post about the module (very recursive, I know
).
Edit: Heh. Figures. I broke something
The module runs but reports an error (technically a “warning,” but the warning essentially says “sorry, buddy, this ain’t happening today!”) when it sends a pingback. I’ve asked the author for a whack from his clue-by-four for guidance 
Well, it sure didn’t take long for Dreamhost’s servers to buckle under the FastCGI-based “performance upgrades” on Willfe.com. Others have complained about it before, so I’ll just reiterate it here that sticking MySQL and the PHP front end on separate servers might sound like a good idea, but in effect it just really slows things down.
I’ve moved Willfe.com and the gallery to different hosting. I actually couldn’t move the gallery, and in fact I had to recreate it, which means graphics referenced in old posts are again broken until I find and update them. Sigh. Stuff should generally be much, much faster now, pretty much all the time. Unless a damned outage kills the box or the network 
Note: Spammers and such, beware — all the same anti-spamming and DoS stuff is still up and running, so don’t think a host switch means free reign to blast the site with comment spam 
This is the site’s 2,000th “node,” and barring a few management bits (categories, mostly), that means this is just about the two thousandth blog entry here on Willfe.com (gallery.willfe.com was also updated). Conveniently, this milestone comes as I successfully completed the arduous task of custom-building PHP for FastCGI on this DreamHost server, and to my surprise things actually are a decent amount faster. I haven’t managed to get APC (the caching beastie for PHP) working just yet, but should have that going shortly. Once that is working, things should go even faster.
Here’s to two thousand more posts on Willfe.com without a lawsuit! 
Update: After much futzing around, FastCGI is properly enabled now and brought APC along for the ride. Holy shit, things are much faster now. Go play around in the gallery; it’s enough to bring a tear to your eye 
I’m simultaneously impressed and annoyed with DreamHost (current home of Willfe.com). Their control panel is top-notch, their flexibility is astounding (as I’ll discuss further a bit on in this post, I’m even permitted to roll my own PHP builds and shove a cache like APC behind it), and on the whole performance has been pretty good for shared hosting.
But it’s still shared hosting. Shared hosting means my domain lives on the same physical server as a few hundred other accounts, and quite possibly a few thousand other domains. DreamHost separates MySQL from web servers, so the database sits on another machine (two points of failure, yay!). This is a good-in-theory kind of thing — in practice, if the web server slows down, my site slows down; if the database server slows down, my site (and every other site that uses that database server) slows down which ultimately slows the web server down.
Heh, whoops; so I updated the color scheme but forgot to snag a new photograph of something colorfully green and bright to go along with it. That leaves a fun blue/orange sunset up there in the corner in the site logo that looks like complete crap compared with this green scheme. As punishment, I will leave it there to stick its tongue out at me until I install a better shot to go along with the theme. Bad willfe! Bad!
Update: Fixed.
Just some fair warning — I’m upgrading this beast from Drupal 5.5 to Drupal 5.7, which involves the usual clusterfuck process of backing up the database and current source tree, deactivating all the external modules, moving the old stuff out of the way, moving the new 5.7 tree into place, copying the configuration file over, running the Drupal database upgrade script, unpacking the latest versions of every extra module, reactivating them one-by-one and running their upgrade scripts. Sigh.
So you may see errors or a “site not available” notice for a brief period as I get all this crap set up. All should be well again by this evening, though.
Update: All done. Drupal 5.7 happiness abounds.
Update 2: Changed the site’s color scheme to a disturbingly green motif. It’s friggin’ springtime; enough with the depressing dark blue!
), the band’s music was great, and the sets were impressive.
It was pretty easy to forget we were watching a performance by a high school cast and crew — apart from a lackluster Belle and some minor problems with two wireless mics (apparently a flap of fabric on two of the costumes cover up the little mics, but fortunately the two actors with the problem had strong enough voices that they projected just fine without the mics), this is the caliber of show you could expect to see on Broadway. The $10-per-seat ticket price was a steal for this 
My congratulations to the cast and crew! My buddy Shannon snapped some shots backstage with my camera (hehehe — nobody said the cast couldn’t snap a few pictures behind the scenes!); they’re available right here, or right here on a separate page in case the “embedded” version goofs up. Standard procedure for both: click the thumbnails for bigger versions; a little magnifying glass w/plus sign icon in the bottom-right corner zooms in even more.
This probably won’t be very interesting to the majority of my readers, but I throw it out there just in case anyway. If you’ve noticed that it’s suddenly taking forever and a day to submit a new node or save an edit to an existing one on a Drupal installation, check out the “Search Engines” page of the settings panel for a module called “XML Sitemap.” Naturally, if you’re not using that module, this doesn’t apply. Anyway, turn off “Submit site map when updated” and turn on “Submit site map on cron run.” This stops a rather painful process from slowly killing your server every time you update the sitemaps by adding or editing nodes — instead of updating them every time anything changes, that process gets moved to the cron runs, so your edits and adds run at normal speed.
Whew. I was beginning to think something was wrong with my installation or my webhost.