Wesnoth.org post-migration status report

I posted a rather extensive report of the results of the asheviere.wesnoth.orgbaldras.wesnoth.org migration to the developers’ ML because Ivanovic wanted me to post updates to the ML for some weird reason. I am fairly sure the people who are actually subscribed to it skip them entirely.

Here’s a link to the email message.

Because I care about transparency and stuff, I pointed out an important thing there:

[…] the migration process went smoothly and now the wiki is running MediaWiki 1.21.2 instead of 1.16.1. Look up 1.16.1's release date and the branch's EOL date and you'll understand why I've been saying "not really optimal" and "deplorable" when referring to the wiki.

(Only after sending the mail I realized that I wrote MW 1.16.1 instead of 1.15.1. The version that was running on wesnoth.org is indeed 1.15.1, not 1.16.1.)

I don’t really have anything to add here, but I am providing a verbatim copy of the email after the break anyway, only because it’s a wall of text and I like those.

Hello there,
By now I estimate that pretty much everyone has the new DNS
information and is connecting to the new server, a.k.a. baldras. The
downtime window for all facilities other than units.wesnoth.org ended
around 18:00 CLST (21:00 UTC), meaning the raw downtime window lasted
approximately four hours (I did hold the forums hostage for a tad
longer than that, though). This is certainly nowhere near the
worst-case scenario I had predicted, and it is nearly the same amount
of time I estimated for the best-case scenario in the original forum
announcement [1]. The post-migration announcement was posted some
minutes after the downtime window ended [2].
[1] http://forums.wesnoth.org/viewtopic.php?t=39455
[2] http://forums.wesnoth.org/viewtopic.php?t=39466
Other than some unexpected disk performance drops in asheviere (old
server) while transferring units.wesnoth.org (a task I had originally
postponed because I thought units.w.o's generation task would be fixed
by the point the migration commenced) and the wesnothd replays archive
for 1.8, 1.10, and 1.11, the migration process went smoothly and now
the wiki is running MediaWiki 1.21.2 instead of 1.16.1. Look up
1.16.1's release date and the branch's EOL date and you'll understand
why I've been saying "not really optimal" and "deplorable" when
referring to the wiki. Because of this situation, I'm taking over the
wiki software maintenance until a new candidate who actually
understands MediaWiki at the system administration level appears.
Incidentally, I had to do some minor fixes to the Glamdrol skin during
the pre-deployment testing stage. It is really starting to show its
age. There are still some minor aesthetic problems (sectional Edit
links are float:right because the shared CSS that fixes various box
layout issues covers even more stuff than it should) and I can't
guarantee that non-trivial functionality is working correctly. All I
normally do at the user level is editing, deleting, and moving pages,
so if there is more advanced functionality used somewhere, I
definitely wouldn't know whether it's broken or not.
Glamdrol's navbar now uses wiki.wesnoth.org links instead of
www.wesnoth.org/wiki/, since it's what everything else uses.
I also dropped the NukeDPL extension thing that nobody seems to use. I
was unable to find an updated supported version for MW 1.21 at the
time -- not that I spent much time investigating in the first place.
The pre-deployment testing weeks leading up to the migration also saw
the fixing of some issue with the gettext.wesnoth.org codebase's
support of WesCamp-i18n. All the credit for that fix goes to AI086.
The forums were upgraded to the latest phpBB version during the
deployment phase. There's nothing noteworthy to say about this task,
and we forum admins don't really use ML for coordinating forum
operations anyway.
All wesnothd (master, 1.10, 1.11, 1.8, 1.6) and campaignd (master,
1.10, 1.11, 1.8) instances were rebuilt on baldras prior to the
deployment stage. If there's some serious bug with either in master
that I haven't heard of before, this is the right time to send me
links to the bug tracker entries so I can rollback to a previous
commit or something.
The stats.wesnoth.org and wesstats.wesnoth.org infrastructure was not
migrated since it was disabled at some point because it sucked. Or
something. I don't remember. The only references I could find in the
server configuration indicate that it generated too much load and it
was killing the server, so I chose to skip its migration altogether.
The associated SQL databases and CGI scripts will end up in a private
archive for historical preservation purposes, I guess.
We haven't decided exactly how to receive email on baldras, so
asheviere continues to occupy the MX record for wesnoth.org for the
time being. Also, SSL support for wesnoth.org is currently missing
while I, er, we figure things out. Not that this is particularly
important, since only the main vhost had SSL support on asheviere, and
that pretty much only serves the static frontpage, gettext, and other
minor things that people neither use frequently nor have any need or
method for authenticating or otherwise transferring sensitive
information.
units.wesnoth.org is frozen in time because that's how it was on
asheviere since the CT in charge of generating unit trees has severe
disk space utilization problems, presumably due to some rogue add-on
or a bug in the u.w.o codebase itself. Elias will look into it.
So this is really all there's to say on the matter. Again, my
"contract" wasn't very specific in regards to what kind and amount of
information had to be relayed to this mailing list, probably on
account of its absolute nonexistence. I mostly wanted to save this
report for posterity in everyone's hard disks and brains because I
love reading my own walls of text.
It's probably worth noting that the following hasn't stopped being the case.
> NOTE: for the legal organization people reading this, we still need
> asheviere around for a while until we have packed and moved all the
> cruft that's not currently part of the user-facing facilities. I hope
> to be able to get us rid of that load before December but I don't have
> a solid estimate yet.
I'll take a look at this eventually -- still before December, though.
Errata:
Where I said MediaWiki 1.16.1, I actually meant 1.15.1