HOWTO: Upgrading Drupal

Fen Labalme's picture

Drupal Security Upgrades - prepare-drupal-upgrade.sh

(This documents management of our legacy SVN-based sites.)

Most security upgrades can be eased by using the prepare-druapl-upgrade.sh script. General usage looks like:

cd drupal/nobackup
prepare-drupal-upgrade.sh 5.7 5.8

This script:

  • copies the 5.7 Drupal core install to a 5.8 directory
  • runs svn switch to update the 5.7 instance to 5.8
  • runs fixwebperms.sh on 5.8

You may still need to run update.php and, of course, update the symlinks in public_html:

  • update symlink PROJECT-dev first, then PROJECT-qa and (after testing) PROJECT

Note that the .htaccess file for all instances of Drupal core points to sites/PROJECT-dev.civicactions.net/htaccess which is under source code control along with client-specific code. This enables quick changing/updating of the .htaccess file without needing to e.g. push a new tag to the live site, but beware: a mistake made in the .htaccess file while working on the dev or qa sites could adversely affect the live site.

Quality Assurance

Update only the public_html/PROJECT-dev first the make sure things still work. Most security updates are relatively minor - usually all that needs to be checked is

  • the site is visible
  • you can log in
  • the qa/dev sites are protected by Basic Authentication

Check the site (better: have someone else check the site - make sure there is a clear handoff if you do so, so that the other person knows and understands their responsibility).

Notes when Manually Updating Drupal

The following considerations are generally handled by the prepare-drupal-upgrade.sh script, but they are worth repeating:

Special files: don't forget to copy to the new Drupal installation.

  • .htaccess
  • robots.txt (if it exists)

Check for symlinks, other site-specific mods: do ls -ltra (reverse time-ordered long listing of all files) of the old Drupal install and look for recently added/changed files (at the bottom of the listing - basically anything following the ".svn/" directory). For example, links to other directories, robots.txt, etc.

Repeat after me: run fixwebperms.sh !!


Notes from Thu, Nov 4, 2010 Re: [ca-dev] security updates

The 'prepare-drupal-upgrade.sh' script still works and is useful for installing a new Drupal (minor update) into ~w_PROJECT/drupal/nobackup, e.g. if the site is currently running 6.17:

cd ~/drupal/nobackup
prepare-drupal-upgrade.sh 6.17 6.19
cd ~/public_html
rm PROJECT-dev
ln -s ../drupal/nobackup/6.19 PROJECT-dev
cd PROJECT-dev/sites/PROJECT-dev.civicactions.net
drush updatedb

Then test the dev site. If it looks good, try on QA with a fresh production DB. Finally, schedule a time to upgrade the LIVE site.

If upgrading modules, it gets trickier and our general best practice is to not upgrade modules unless they have a critical security issue for which the module - as configured on the site - is vulnerable. If the module does need to be upgraded, using drush from your sandbox is the easiest:

cd ~/workspace/PROJECT.6
drush upc
...

Test in you sandbox. If it looks good, then:

svn ci -m "security upgrade ANNOUNCEMENT-#"

(Drush, if properly configured, has already done the "svn add" commands.) Then again, you test first on DEV, cut a tag and test on QA with a fresh LIVE DB, and finally schedule a time and push to LIVE.

One thing not mentioned yet is: how is the client paying for this? If the client is under a current development contract, then these upgrades are a standard part of the process. If the site is complete and in "maintenance mode" then it depends upon the contract we have with the client - always best to check in with the PM for clarification.

To clarify two points that sometimes gets missed:

  1. The 'prepare-drupal-upgrade.sh' script can be run directly on the PROJECT vhost as it cleanly places a new Drupal core install next to the existing one, making no other changes. No SVN commits are needed. But to update a PROJECT's modules or themes - e.g., with `drush upc` and associated SVN commits to the repository - the work must initially be done in a sandbox as the rule is "no SVN commits from a vhost". Then use "svn up" (in DEV) or "svn switch ..." (on QA and LIVE) to update the PROJECT code.
  2. When making site updates (of any kind) always remember to follow the standard DEV/QA/LIVE process, testing first on DEV (trunk), then cutting a tag and testing on QA (with a freshly pushdb'd database from LIVE) and finally moving to LIVE with coordination of the PM and client when necessary. (This process is described in more detail at Dev QA Live - though this page needs some updating.)

Tags: 

Groups audience: 

- Private group -

Openness: 

Public - accessible to all