I had an interesting discussion yesterday, with a senior technologist, about the recent Drupal security update (that some members of the tech community are unkindly calling ‘a fiasco’).
Oh, I understand the bitterness around the short-notice of the security update.
And I understand the raised hackles around the ‘do this within six hours or consider your systems to be compromised’ message.
But there’s a wider point about how we update our critical systems (and make no mistake, for a very large number of organisations, Drupal is a critical system).
And that’s where I’d like to go with these thoughts.
Mature (and that’s a key word) organisations require their suppliers to produce a release schedule.
Each release schedule will generate, for the users/customers, a full set of release notes, prior to release publication.
A good set of release notes will contain full details of all functional (and non-functional) changes.
But that’s the release schedule model for routine updates.
When urgent fixes are released (let’s assume we’re talking about infrastructure fundamentals here; operating systems and core application products such as databases, mailservers etc), they too should contain a good set of information about the change(s).
Whether we, as decision-making technologists, choose to have our systems automatically process these updates (i.e. before we have read the release notes), or not, is up to us.
It’s about how much control we choose to retain over our infrastructure.
Do we want to read the release notes before we install the updates?
It’s a personal thing.
The critical point, though, is that we ensure we take a whole-system backup, before we apply the updates.
I’m slightly OCD about my infrastructure.
I like to read the release notes before I apply a fix – even if it’s an urgent fix – I like to know what I’m applying, and what changes it will make to my systems.
And I’ll take an extra whole-system backup; everything from the operating system (but including the operating system) upwards, will get backed up and copied to a contingency location.
My core infrastructure is RAIDed.
So I’ll keep one compressed whole-system backup on the RAIDed infra.
And I replicate that backup to an off-system location.
But lately I’m wondering if I should introduce another layer.
Maybe I should consider having my system back itself up to an external product?
2TB.
Hmm.