3.1. Stay Current with Code Updates

It's a sad but true fact that most major worms and exploits over the years have targeted known and fixed vulnerabilities. Table 3-1 provides evidence of this unfortunate trend. These issues were large enough to cause significant economic damage to companies and countries, and yet the patches to prevent these worms were released months or even years before the worm was released.

Therefore, one of the most important things you can do to protect your site is stay up to date with new releases of the code you use. Keeping your site up to date is a two-step process:

• Learning about the updates

• Applying the updates

Learning about updated code may seem simple, but the Drupal project often suffers from too much information on a subject, which makes it hard to find the information you need. There are also probably a few dozen ways that you can update your code, which can be confusing. The next sections present some best practices to keep on top of the rapidly changing Drupal project.

3.1.1. Staying Informed about Code Updates

There are three primary ways to stay informed about code updates, and I have listed them in the order in which I recommend them (least recommended to most):

• The email newsletter available at http://drupal.org/security

• The RSS feed from http://drupal.org/security/rss.xml

• Enabling the Update Status module and making sure cron runs regularly

Email from drupal.org can be delayed or get lost in transit from message filters. A message about the security of your site shouldn't be trusted to such an unreliable mechanism. The RSS feed is a much more reliable means to get information, but both the email and RSS feed include announcements about all contributed modules, which means that some of them will be about modules you don't use. The RSS feed is still valuable in general because it provides notifications in a reliable manner.

The Update Status module is probably the best solution because it displays a message to admins of the site about any modules that need to be updated. As long as you visit your site on a regular basis you will see the warning in Figure 3-1. In addition, it can be configured to send email alerts to administrator accounts. The basic process for configuring the Update Status module is the same in Drupal 5.x and 6.x, though the location has changed from Administer Logs Available Updates to Administer Reports Available Updates, with similar URL changes. On this screen you should enter an email address and then set the rest of the configuration options based on your personal preference. Emails from within a site to the site admin are more likely to be delivered.

Figure 3.1. The Update Status Report screen showing an available update

3.1.2. Updating Your Site's Code

Once you've learned about the availability of updated code, you have to actually install those updates. This process continues to get better but is still cited as one of the most difficult parts of maintaining a Drupal site. You can make this process easier through a variety of techniques, though some of them can be difficult to learn.

Several practices in building your site will help you when you have to update the site:

• Use a test site. Creating a separate test site and doing the upgrade on that site will make the real update much easier.

• Choose modules and module versions from a site where you are confident that the maintainer will provide stable updates. One signal that a maintainer will provide stable updates is the use of drupal.org's Official Release system. Beyond that you often must just read the project page and release notes for the module to understand the site's commitment.

• Try not to modify the code (commonly called hacking core), but if you do, be sure you contribute the patch back to the community. Drupal is based on a modular and easily overridden system, which makes it easy to change things without having to edit code. If you edit code directly and don't merge your change into the code on cvs.drupal.org, you are simply creating pain for yourself in the future when you update and lose all the changes you made.

Beyond that, you simply must get the updated code and install it on the server. There are many different techniques for doing this, but following are steps for two valuable methods. The standard documentation for updates is available in every installation in UPGRADE.txt.

3.1.2.1. Manage Drupal via CVS Checkout

CVS is a revision-control system used by the Drupal project for Drupal core and all of the contributed code for the project. It's possible to use the command-line tool to easily create, update, and verify your Drupal installation. First, use this command to get a copy of the code to create an installation:

cvs -d:pserver:anonymous:[email protected]:/cvs/drupal 
  co -r DRUPAL-6 -d path/to/webroot/ drupal

This command will download the latest copy of Drupal core from the DRUPAL-6 branch. There are several benefits to this technique, such as the ease of updating Drupal when a new version comes out. You can choose between updating to the latest version on the DRUPAL-6 branch or taking the more reliable route of updating to a specific version of core, such as 6.4 with the version tag DRUPAL-6--4

cd path/to/webroot
cvs up -r DRUPAL-6--4

By updating this way you rely on the revision-control system to merge together the changes from drupal.org with any changes you may have made locally. While hacking core is generally not recommended, it is occasionally necessary, and cvs up makes it easier to manage. There is also a simple command to see if your site has been changed:

cd diff -up

This handy command creates a diff of all of the changes that you have made. A diff is a comparison of your local copy and the corresponding files on the server, which can be used to identify changes. These changes can be output into a patch file and then shared with other users. Patch files form the basis of improvements to Drupal and are used in the Drupal issue queue. If you make a change to your installation that is generally useful for other sites, you should add that patch file to the Drupal core issue queue at http://drupal.org/project/issues/drupal. If your changes are included into core, then you no longer need to worry about them when you upgrade.

These commands and practices also apply to Drupal's contributed modules and themes, though the repository location, paths, and branch names are slightly different. You can find more information about using CVS at http://drupal.org/handbook/cvs.

3.1.2.2. Manage Drupal with drush

The drush module aims to provide useful commands for Drupal (dru) to power users who often work on the command-line shell (sh). To use drush, you need command-line access to your server and a command-line-enabled version of PHP. drush provides one very handy command to update modules installed on your site:

drush -l d6.example.com pm update

This command will update any of your modules if there are new versions of the module available on drupal.org. To use drush you must enable Update Status and several additional drush modules, such as the drush package manager and one of the helpers for the package manager such as wget support. While drush has many more features that are worth exploring, this module update feature is very handy for updating a site with a large number of modules. You still need to run update.php manually and to configure and test your site based on the updated modules, but it automates a lot of the tedious work.

The major benefit of these approaches is how they can reduce the busy work of finding the module page, finding the link to the tar file, downloading it, unpacking the tar file, and placing it into your Drupal installation. The easier that this process can be, the sooner you are likely to do it. The sooner you do it, the safer the site.