Table of Contents
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
- 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.
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.
- 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:
- 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.
- 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.)