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.