The Register® — Biting the hand that feeds IT

Feeds

Server patching principles

The nirvana process

  • print
  • alert

Workshop In the imperfect world we live in, patching stuff, be it desktops, software or servers is a fact of life. We do it or we risk being exposed to the latest security threat, missing out on new functionality or suffering performance degradation.

We discussed desktop client patching over in the desktop management workshop. In this leg of the workshop we’re all about servers, but in practice, is patching just patching? Beyond the obvious - a server running a critical application is more important to the business than a single desktop - is what you patch the real issue or is it more important to have the right tools and processes in place?

I’m going with process. Anyway, nobody in their right mind spends money on tools without first working out to at least some degree where and how they will be used. Erm, right? So what does a patch management process look like?

In practice, a series of stages need to be worked though to create and operate a process for patch management. Like most processes, those for patch management span more than one domain. The development, operations and security groups are all involved. There’s a list of things you need a handle on: hardware and network inventory, asset management, change and configuration management, not to mention a degree of formalized planning for areas such as costs, maintenance and communications plans.

Needless to say, you can’t set up a ‘proper’ process without an audit somewhere: creating an inventory of what software runs on what machines and linking this in with asset, change and configuration management, will do nicely. Then you get everyone to agree on monitoring for new vulnerabilities and available patches, and that representatives from the three groups will work together to ensure patches can be rolled out to a timetable which includes testing, distribution, exception handling, tracking and reporting.

When you look at all the pieces, the effort required to get a ‘proper’ process in place might look a bit daunting. However, not having such a process in place is almost guaranteed to be even more problematic, with service interruptions and security breaches more likely to occur and then requiring considerable fire-fighting effort to put things right.

But where do you start if you do want to make improvements? For many IT shops, the area of asset and configuration management may be the biggest challenge, especially if things have been allowed, for whatever reason – resourcing usually – to drift out of date. However, if you don’t know what you have in your environment, don’t know what version of x is running or don’t know what the last change made to a specific item was, you can’t do proper patching.

It’s not going to get any easier either. The spread of virtualisation technology poses some interesting difficulties. For example, how do you ensure dormant machines are patched? It may be worth getting some plain and simple measures in place right now to govern the virtual stuff. A starter for ten might be: ‘If your VM isn’t worth patching, we’re not keeping it.’

With all this in mind, if your IT shop has moved from a chaotic or simply labour intensive patching regime to an altogether happier place, you’ve discovered the ‘best tool ever’ or virtualisation is playing havoc with your regime, we’d love to hear all about it. ®

Latest Comments

Oh, err...

"Anyway, nobody in their right mind spends money on tools without first working out to at least some degree where and how they will be used. Erm, right?"

Err, sure, mmm, yeah, I certainly don't do that, no way hosay...

0
0

WSUS and YUM

They are your friends.

As to app-specific patches...

*sob*

0
0

OpenVZ

We have a pair of OpenVZ servers running the containers from common NAS (meaning it's a matter of seconds to push a container from one to the other).

I wrote the following function:

clusterfuck () {

running=`vzlist| grep running| awk '{print $1}'`;

if [ -z "$*" ]; then echo $running;

else for i in $running; do

echo "### $i ###";

vzctl exec2 $i "$*";

done;

fi

}

(named because of what happens if you're careless with it), and made one of the OVZ boxes AptCacher proxy. All the updates get picked up, but only the template container (DAMP) updates automatically, so if an update causes problems the Nagios starts screaming about the template.

Updating all the containers on a box is a matter of

root@VZserver# clusterfuck "aptitude update && aptitude safe-upgrade && aptitude clean"

Updating the boxes themselves requires shoving the containers to the other box, updating, rebooting if there's a new kernel, checking everything, and bringing the containers back.

0
0

More from The Register

New Lumia 925: This, loyalists, is the BIG ONE you've waited for
Nokia veep drills high-end master plan for El Reg
Android device? Ooohhhh, you mean a Samsung phone
Koreans nabbed nearly all the Q1 profits – more even than Google
Review: HP Pavilion 14 Chromebook
All roads lead to Chrome?
Borked your iDevice? Pay EVEN MORE to have it fixed by Applecare
Or scream at their hapless techies on their forums
Euro PC shipments plummet into bottomless pit of DOOOOM
11th quarter of decline, 20pc drop on last year - Gartner
Report: AT&T dropping Facebook phone after dismal sales
Turns out folks won't buy that for a dollar
Notebook sales to surge, says notebook seller
'Intel and Microsoft will save us'