Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We have three main servers on ec2, web, database, and search. I logged in today to find:

77 packages can be updated. 45 updates are security updates.

which scares the crap out of me so I want to update these machines asap but I'm scared to just run the updates on a live running system. Is this safe to do, what's the best approach when it comes to doing security updates on production machines?

share|improve this question
Your next question to ServerFault should be how to make better contingency plans. It is not ok to have such hard restrictions that make you so afraid to make a simple update on your server. If the site is so important, design it with some fallback in mind (multiple frontend servers, multiple backend servers, etc). Then, you can update one at a time without worrying if something goes wrong. Keep in mind that a failed update is not your main concern, there are other problems too. – Juliano Feb 23 '11 at 15:51

You should also understand what the updates are and if they are cause for concern. If a patch fixes a security flaw in a service you don't run, you don't need to worry about it.

You're being prompted to patch because you've got the package installed; if you just did a 'full' install without deciding which packages you actually need most of these updates could be redundant for you.


share|improve this answer
Good call. That's fine for packages like: openssh-client openssh-server openssl passwd that I know I should upgrade but there are some that I have no idea what they are that could be important. – Ryan Detzel Feb 23 '11 at 14:59

If you use only Ubuntu repository package, then upgrade is very safe.

Also you can stop EC2 instance, make snapshot and then make update. If you have problems you can rollback.

share|improve this answer
Yeah, everything is direct from the package manager. I can't really stop the instance since it's our main website so I need a way to do it live. – Ryan Detzel Feb 23 '11 at 15:01
@Ryan Create and save image from a running instance, create new an instance, associating an elastic IP address with a new instance, update instance. – ooshro Feb 23 '11 at 15:09

It doesn't really matter that it's an EC2 machine in this case. You should apply the updates as you would to any other production machine- testing each one in a test environment before applying to your live environment!

share|improve this answer
Well, the advantage of ec2(I'm hoping) is I can take a snapshow, do the upgrades and rollback if something goes wrong. Either that or take a snapshow to build a duplicate system, run upgrades, test and if that works do it on the live system too. – Ryan Detzel Feb 23 '11 at 14:53
It totally depends how you setup your ec2 instance, do you have everything mounted on an EBS? If so, a snapshot in this instance will be very useful. – AliGibbs Feb 23 '11 at 14:59
Yes, everything is an ebs. – Ryan Detzel Feb 23 '11 at 15:07
Ah, that's excellent news. Take a snapshot of the EBS, then create a new instance and mount this snapshot to it- preform the upgrades to the packages you want/use (or just do all of them), and then test and ensure that everything is working as you expect. Once your statisfied, then you can do it on live! :) – AliGibbs Feb 23 '11 at 15:12

Welcome to build and patch management. Most of it is 99% the same as physical servers, ec2 just let you get this far without hiring a sysadmin.

The answer is to know your distro's packaging tools and policies well and use that to make case by case evaluations of what packages are non-issue's you can do real quick, and which packages are maybe-issues you can handle case-by-case (and then how to handle ones that turn into real-issues).

It also fits into your overall cluster/availability design to be able to shift whatever live services you provide off a given server, do your patching, test/validate somehow, then shift workload back onto the server.

Sorry thats really high level, but you didn't tell us anything about your cluster or its workload.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.