I guess everyone has heard of the recent news on WordPress 2.1.2, which was hurried out of the door because the WP 2.1.1 tarball was somehow altered by a cracker to include security exploits. Upgrading WordPress has been a monthly routine lately, and it is always advised to upgrade to the latest and greatest because (1) newer is (supposedly) better! (2) you like to live on the bleeding edge, right? (3) most point-upgrades contain security fixes. You don't want to wake up one day seeing your blog turning into a pr0n site, do you?
Upgrading WordPress is not hard -- just follow the simple 5 steps. However, if you happen to have a "WordPress farm" hosting more than a dozen blog sites, then upgrading this way can be very taxing, no matter how simple the 5 steps are.
I happen to run a smallish blog farm at FOCUSer.net, hosting around 20+ blogs for friends at church. Currently they are all running the latest WP 2.1.2, and installing new blogs and upgrading them are a breeze thanks to Gentoo's "webapp-config" (aka vhost-tools).
While 25 WordPress installations is probably nothing in comparison to many blog networks, but the method I am describing here should be able to scale to servers with hundreds of WordPress sites.
Installing Vhost Tools
I am using Gentoo Linux's "webapp-config" application to manage most my web-based applications installed in vhosts. It is tightly integrated with Gentoo's portage, so I am not sure whether it can be used on other Linux distributions. I like it because:
- Web-based applications can be installed by portage. Installing an app is as easy as typing in
emerge <app name>(provided the ebuild file for that app already exists).
- It can easily replicate installed apps into different "virtual hosts", and because hard links are used, the same app installed into 100 vhosts will only take storage space of 1.
- It records all files installed like all good package managers do, so it can then remove and upgrade packages cleanly.
While some people reckon Gentoo shouldn't be used in production servers, the flexibility of webapp-config in deploying web apps is hard to find equivalent in other Linux distributions.
To use "webapp-config", make sure
USE="vhosts" is in your
/etc/make.conf, and then
emerge webapp-config to install the webapp-config scripts.
Installing and Updating WordPress in Portage
To install WordPress on Gentoo, you just need to use portage to install it into a shared location. Note that currently WordPress is profile-masked in Gentoo due to "a long list of security bugs, e.g. check bug #168529" (taken straight out from the
package.mask file). You need to "unmask" WordPress first before you can install it.
$ echo 'www-apps/wordpress' >> /etc/portage/package.unmask $ emerge wordpress
I have just checked that WordPress 2.1.2 ebuild is already in the core portage, inside
/usr/portage/www-apps/wordpress. However what I usually do is having my own portage overlay, and roll my own WordPress ebuild files so I do not need to wait for Gentoo developers to commit new ebuilds -- I can get all my sites updated and running right after a new version of WP is available for download. Sorry I won't cover how to run your own overlay, nor how to create an ebuild file. Here is mine for example -- just rename it to
wordpress-2.1.2.ebuild or whatever the latest version is.
To keep your central WordPress installation up to date is easy.
emerge --sync to get your portage in sync, and then
emerge wordpress to download and install the latest version. Note that all web apps of different versions are installed in different slots, i.e. it does not remove old versions, so you can run two different versions in parallel.
Installing, Removing and Updating WordPress in Virtual Hosts
Because of the two-stage design of Gentoo's vhost tools, installing WordPress into portage does not set up a blog for you automatically. Instead, you need to take the second step to install WordPress into virtual hosts served by web servers. Gentoo Linux puts all virtual hosts in
/var/www/<hostname>/htdocs by default, but can be changed by the configuration file in
/etc/vhosts/. To set up a new blog at http://blog.example.com/ running WordPress 2.1.2 (presumable already installed by portage), you'll need to type in the following commands:
$ webapp-config -I -h blog.example.com -d / wordpress 2.1.2
It will set up everything in the right permission under
/var/www/blog.example.com/htdocs. Provided MySQL and DNS are ready, we are now ready to browse to that URL and continue the setup.
Removing a vhost installation is equally easy.
$ webapp-config -C -h blog.example.com -d /
To update WordPress involves (1) use webapp-config to update all the files (2) run the WordPress upgrade script. For example, to upgrade an old blog to WordPress 2.1.2,
$ webapp-config -U -h blog.example.com -d / wordpress 2.1.2 $ curl http://blog.example.com/wp-admin/upgrade.php?step=1 > /dev/null
Mass Upgrading WordPress Installations
Because of how scriptable webapp-config is, it is easy to write a simple shell script to upgrade all your WordPress installations. In my set up, all sites are running under
/var/www/<hostname>/htdocs, and the following script (
upgradewp.sh) upgrade all my sites in one go.
#!/bin/bash latest=`ls /usr/share/webapps/wordpress/ | tail` for dir in /var/www/* do if [ -f $dir/htdocs/.webapp-wordpress-* ] then sitename=`basename $dir` webapp-config -U -h $sitename -d / wordpress $latest curl http://$sitename/wp-admin/upgrade.php?step=1 > /dev/null fi done
So the procedures of upgrading to the latest WordPress are:
- Create/rename your own ebuild file (1 minute), or resync portage (5 minutes).
emerge wordpressto install the new version (1 minute)
upgradewp.shto upgrade all sites (1/2 second per site on my 256Mb VPS)
And you can have your blog farm all updated to the latest version of WordPress in under 10 minutes!
If you go back to WordPress' upgrade instructions, you'll see that my quick 'n' dirty script using Gentoo's webapp-config has skipped many important steps.
- It does not backup any database.
- It does not deactivate 3rd party plugins before upgrade.
- It does not reactivate 3rd party plugins after upgrade.
These steps are there "just in case". I do have daily backup of MySQL database on my servers, and deactivating a bad plugin after upgrade just requires deleting the file -- so not biggie for me. Your mileage might vary :)