Did the last things that needed to be done before the old servers could be shut down. Currently experiencing some domain resolution issues, which is hopefully related to propagation.

Spent time today tracking down an issue on the VPS where Apache would become unresponsive, and time out. Everything else seemed to be working.
Thought it was a property of being on the VPS, so was looking for exotic things like TCP connection limits. It was simply MaxChildren being set at a sane default of 10, which was not enough for the traffic we were getting at the time (possibly exacerbated by everyone clicking refresh when the site failed to load). Upping this from 10 to 100 allowed all the sites to load, spiking up to approximately 60 worker processes, but dropping back within a relatively short period of time.

Set up Nagios monitoring for the number of Apache2 processes running. If this exceeds 70 processes, I get a warning, if it exceeds 90, a critical.

Moved an early version of Joomla over to the DS VPS.
Ran into problems with the old mysqldump not back-ticking field names that became keywords in new versions of mysql. Also, under the old version/build of MySQL, character fields were latin1, with one byte per character. On the new host, characters are utf-8 (unless otherwise specified) which has a worst-case of three bytes per character, and this increase is size broke the 1000 byte width limit for MySQL indexes.
Additionally, the old host was a Win2K server, so MySQL table names were not case sensitive (as this is exposed from the underlying FS). The new host is a linux box, so Gallery2 broke when the tables were imported in all lower-case names.

Moved this blog (running Simple PHP Blog over to the DS VPS.
Ran into a problem when moving, was getting "Zero Sized Reply" errors. This was due to an error occurring, but due to this system using ob_start to capture the theme generator output, the error messages were being captured, then the script would time out, and the messages never displayed. I fixed this by removing the ob_start from theme.php and scripts/sb_utility.php (the second one being related to using gzip compression). This showed me the error message, and the big looping spam of knock-on errors. The new server had (by default) no write access to a file the blog system tried to open (config/users.php, no idea why it would want to open that).
Also ran into a problem when making this post, that the /config folder is used for holding a cache, and needs to be writable as well.

Moved the Mailman mailing lists from the old server to the new one. Fortunately this was very easy as we had a good Mailman backup system in place. config_list is used to export/import the list configuration (sans password), and list_members/add_members for the members.

Found some peculiarities with how Plesk handles mailing lists, it doesn't allow you to put them on a subdomain, such as list@lists.example.com, although it does put the Mailman web interface on lists.example.com . Since we were porting existing lists, keeping the same email address was important. I solved this by adding the lists to the example.com domain, bringing the configuration and member lists over, then adding lists.example.domain to /var/mail/control/rcpthosts and virtualdomains . This change may get wiped out if/when I upgrade the Plesk control panel, but I see little reason to do that at this point.

Migrated the mail accounts to the VPS, found out that Plesk (the VPS control panel) considers SpamAssassin to be a premium feature. Fortunately that's just the control panel for it, removing then re-adding the psa-spamassassin package through the normal Debian package management will apply the SpamAssasin integration to any existing mail accounts. You can't configure it through the control panel, but the text config files are all in place.

Also set up a .qmail address to feed into sa-learn, which is the Bayesian learning for SpamAssasin.