Drupalgeddon? Again? Yup, it happens, with Drupal or any software exposed to the internet. Hackers are smart and want to park on your lawn, or steal your bike. For agencies or busy freelancers, when an urgent security update is announced, and it applies to all your clients, you need to be prepared to take care of it fast. Attackers were exploiting Drupal sites within hours of the most recent update.
Fortunately, Pantheon and other hosting platforms provide tools to make the update work easier.
This post covers basic Drupal sites on Pantheon. Taking care of multidevs or sites using composer-based workflows is not covered.
Many tools and Terminus plugins are available. The examples below show some of our favorites and how they might be used.
Benefits and risks
While the benefits might be obvious — you need to update all of your sites fast and with confidence, there is one potential risk. Sometimes you may not have time to use your normal QA process if it’s not built into whatever your using for integration and deployment. This post assume you’ll fit that in where you need to.
Updates on Pantheon are different
Pantheon uses a forked version of Drupal. When Core is updated, Pantheon must merge those changes into its forked version before making it available to sites. The forked version is called the “upstream”. Once the new upstream is available, sites can be updated manually through the Pantheon dashboard, individually using Terminus, or in bulk using Terminus and a couple of helpful Terminus plugins.
Updating Multidevs
Multidevs should not be ignored, but are not handled with the bulk commands below. Usually a merge or rebase from the master branch will be required. Or, the security patch could be applied to the multidev branch locally and pushed up to Pantheon. Use your normal multidev workflow, and make sure that they are locked until you can apply updates.
Composer based sites
Sites using composer workflow are not handled with the instructions below.
Patches
The processes below may blow away applied patches or other changes to core. This depends on which files the update touches, and what you’ve patched. If you’re patching core, use your preferred process to handle that, not the outline below.
Before starting
Read the manual on the Terminus commands and plugins used below. Learn how to install plugins.
Individual site update
For reference, here’s one way to update a site from the command line.
Step 1: Backup
$ terminus backup:create <site>.<env>
For example:
$ terminus backup:create mysite.live
Step 2: Merge the upstream
This will merge the new upstream into the dev environment. –accept-upstream resolves merge conflicts in favor of the upstream. Upstreams are always merged into the dev environment.
$ terminus upstream:updates:apply --accept-upstream -- mysite
If you are sure the updated upstream is available, and the above command doesn’t list the update, then you may need to clear the upstream cache as follows.
$ terminus site:upstream:clear-cache mysite
Step 3: Deploy to test and live.
$ terminus env:deploy mysite.test && terminus env:deploy mysite.live
Add these flags to the above command if cache clear or update.php is needed: --cc --updatedb
Finally, log in to the site, or use drush @pantheon.mysite.live status
to confirm that the update applied correctly.
Bulk Site Updates
Step 1: Bulk backup all sites
If you have a security release window in the future, it’s a good idea to grab a fresh backup while you’re waiting for the update to come out. Use the Backup All plugin and run this command. The async flag will kick them off all at once.
$ terminus ball:create --env=live --async
Step 2: Merge the upstream
After the update is available, use the Terminus Mass Update Plugin to merge the new upstream into all dev environments. –accept-upstream resolves merge conflicts in favor of the upstream. Only sites with a new upstream will be updated.
$ terminus site:list --format=list | terminus site:mass-udate:apply --accept-upstream
If you are sure the upstream is available, but the above command doesn’t list the update, then you may need to clear the upstream cache as follows. Terminus Genie is a plugin that can run commands on all sites.
$ terminus genie -- site:upstream:clear-cache
Step 3: Deploy to test and live.
Genie is used again. $ terminus genie --env=test -- env:deploy
Use these flags if cache clear or update.php is needed: --cc --updatedb
$ terminus genie --env=test -- env:deploy
After all the test environment deploys are finished, use the same command on live.
$ terminus genie --env=live -- env:deploy
Or if updatedb
is needed needed
$ terminus genie --env=live -- env:deploy --updatedb
Check your work like your site depends on it
This script produces a report of any security updates needed on live environments.
/** #!/bin/bash echo 'Updating site list now.' terminus site:list --field=name > ~/sites.txt IFS=$'\n' # make newlines the only separator for j in $(cat ~/sites.txt) do message=$(drush @pantheon.$j.live pm-updatecode -n --strict=0 2> /dev/null | grep SECURITY) if [ ! -z "$message" ]; then echo '-----------------' echo "$j".live echo '-----------------' echo $message fi done
Remember to double check that the updates applied to all sites. Things can go wrong, especially when everyone who manages a Pantheon site is backing up and updating at the same time. You’re not the only one ready to spring into action when the security advisory comes out — the hackers are also ready and waiting. Having a plan in place, and confirming it worked as expected, can save hours of trouble.