VHost Changes
This week, I started the long-ish process of upgrading my websites from a very backlevel Drupal 4 to Drupal 6. With 6 domains on Drupal 4 (and a new one already on Drupal 6), this augers to be a time-consuming project. But, I've got the time.
First off, I look at what I can drop. One of my domains is useless; I had built it for my nephew, as he wanted to have a website, but he never used it. Two other domains are redundant; they are aliases for a third domain that, while not in use today, will likely receive content over the next few months. And, that leaves three domains that I must spend time on.
In general, I plan to
- drop the useless and redundant domains,
- rebuild the one domain that is currently content-free, and
- migrate the remaining two domains to Drupal 6, one at a time.
First off, we get rid of the three domains that I no longer want.
For my nephew's site, I start by removing the DNS entry that points his domain at my server. Now, his site is unreachable from the Internet. I also delete two of the three DNS entries that point to the content-free site, and it can now only be reached through the one remaining URL.
Next, I remove from my Apache configuration the <VirtualHost> stanza that defines my nephew's website. While I'm there, I remove the two (now useless) ServerAlias lines from the <VirtualHost> stanza that defines the content-free website. A quick Apache restart (/etc/rc.d/rc.httpd restart) and b'bye websites. Yes, that Apache restart gave me a few seconds of downtime, but I doubt that anyone noticed. Did you?
Finally, in MySQL, I DROP databasename and REVOKE privilegelist to get rid of the database that made up my nephew's unused website. And my system is cleansed of all traces of the three dropped sites.
Now, at this point, I have a choice: either rebuild the one content-free website, or try my hand at migrating one of the other sites. If I successfully migrate a site, then I might just migrate the content-free site instead of rebuilding it. The site I have in mind for this initial migration has content, but does not have anything special in the way of modules or themes, so migration should be pretty straight-forward. Both of the other sites (the content-free site, and the other working site) have themes and modules, and I don't want to migrate them yet.
So, rather that worry about the content-free site, I decided to migrate my one simple, content-filled site. I reviewed both the Drupal 5 and Drupal 6 UPGRADE.txt documents, and found that (as I expected), they were written to cover an in-place upgrade of the Drupal code, rather than a migration of a Drupal database. I took what I could from them (primarily, the URLs for the database reorganization logic), and had to extemporise the rest of the upgrade procedure.
Drupal 6 uses a significantly different database structure from Drupal 4 and Drupal 5, and the installation includes a database migration tool. Unfortunately, it only migrates from Drupal 5 to Drupal 6, so I first have to get my site databases into Drupal 5 format. I mysqldump my Drupal 4 site's database, and with that dump, build a mirror database, which I then point a Drupal 5 internal website at. When I visit this internal URL, the Drupal 5 "update.php" URL takes care of re-organizing the database for me, and it leaves me with a usable mirror of the original site, in Drupal 5 format.
Now, I point a Drupal 6 internal website at the Drupal 5 database, and go through the same process once again. Again, the "update.php" URL worked like a charm, and I wound up with a working Drupal 6 site, identical to the original (and still live) Drupal 4 site. Once I had massaged this new site to my satisfaction, I went back to the Apache configuration, and changed the DocumentRoot entry of my live site's <VirtualHost> stanza to point to the Drupal 6 directory, and (with another Apache restart), the switch was made. Now, I could clean up the site's old Drupal 4 database and permissions, using the standard MySQL tools.
With this, I found that I had to "rewrite" the Drupal UPGRADE.txt for my migration:
- Don't put the original site into "Offline" mode before you copy the database. You won't be able to log onto the "new" site, if you do.
- Use a single internal website URL for both the Drupal 4 to Drupal 5 and Drupal 5 to Drupal 6 upgrade; this permits you to remain "logged on" to the site throughout the process; you 'can't run the "upgrade.php" script if you aren't logged on as an administrator
- In the Drupal 4 mirror site, disable all added modules and fall back to one of the default themes. You don't do this in the Drupal 4 live site. And, don't forget to record which modules and themes you used; you'll have to find replacements for them when you get the databases up to Drupal 6 format.
OK, so migration wasn't too difficult, but it's not something that's worth doing to an empty site with lots of modules and an unusual theme. That means that the next step is to rebuild that content-free site in Drupal 6, rather than migrating the databases over. And that's a long process. I've got that job half-way done, and I worked on it for most of the evening. Another day or so, and I'll switch the public face of that site over to the Drupal 6 version with a simple change to the Apache DocumentRoot entry for that virtual host.
That leaves one site unmigrated (that's for this week), and one site being built (again, for this week). In the next update, I should be able to report that the migration is complete. But, let's wait and see.