[TriLUG] Approaches to Linux Patch Management

Cristóbal Palmer cmp at cmpalmer.org
Tue Jun 12 10:57:55 EDT 2012


On Tue, Jun 12, 2012 at 1:46 AM, John Wheeler
<jwheeler at etherealfringe.com> wrote:
> The idea being that our test systems run the latest patches for a period of time before those patches are applied to production.

This can be done without managing repositories or even having a local
cache of remote repositories. You just control when package updates
get applied and which subset of the updates are applied when you apply
them. All of that can be done with standard apt (or yum, depending on
the distro) tools.

As Igor mentioned, you could use pinning, but that would be most
useful to guarantee that specific packages (eg. the smtpd and its
dependencies if the machine is a mail server) do not get changed. I'm
not sure that's what you're looking for, but it might be. Don't get me
wrong: I love pinning. It's really useful. I'm just not sure it's the
tool for the job you've got.

It sounds like you want to guarantee two things: (1) DEV should get
updates before TEST, and TEST before PROD. (2) When I update package
foobar from version 1.2 to 1.2.1, I want to make sure TEST gets 1.2.1,
not (for example) 1.2.2 if the package got updated again after
application to DEV but before application to TEST. Does that cover it,
or is there more to it?

> I know that this could involve leveraging our own repository, however I am not excited by the prospect of being responsible for staging all OS patches into a local repo.
> Then again, I know little about managing repositories.

If you don't want to go down the road of having a local repo fully
managed by you (with attendant package signing keys and all the rest),
I'd start with just a local cache of repositories managed by others:

https://help.ubuntu.com/community/AptProxy

You could then sync on a regular cycle under your control, eg. only
after you've pushed updates to PROD.

> Essentially, I am just looking for a nudge in the right direction, so that I don't find out down the road that I  went the wrong way and wasted a bunch of time.
> Do I have to run a local repo to freeze/apply OS patches? Is there a way to achieve this same effect using the public repos and some cleverness?

If you are trying to accomplish the two things I said above, then
public repos and cleverness can get you there. What exactly that
cleverness is will depend on your needs, but might be as simple as
this (from the apt-get(8) manpage):

-----8< snip 8<-----
       install
           [...]
           A specific version of a package can be selected for
installation by following the package name with an equals and the
version of the package to select. This will cause that version to be
located and selected for install. Alternatively a specific
distribution can be selected by following the package name with a
slash and the version of the distribution or the Archive name (stable,
testing, unstable).

           Both of the version selection mechanisms can downgrade
packages and must be used with care.
-----8< snip 8<-----

> What do you guys do?

A mix! It depends what you're trying to accomplish, how many machines
are involved, whether you have all Ubuntu of one LTS or you have a mix
of Ubuntu releases, RHEL releases, CentOS, Solaris, AIX.....

If I were you I'd just start with a human/policy solution, eg. "Only
[list of people] apply updates to [list of boxes], and updates must be
applied to [subset of boxes, eg. dev] before [subset of boxes, eg.
test] with at least two full business days intervening unless there is
management approval and a change notice." And then you and the rest of
[list of people] set about reading the manpages for apt, apt-proxy,
apt-cache, yum, yum-updatesd, etc. etc. so that you don't mistakenly
apply updates you didn't mean to apply.

If you need some kind of software enforcement of your policy, whether
through apt-pinning, custom repositories, puppet, or something else,
is going to depend on the people, the machines, the packages, and the
problem you're trying to solve.

Cheers,
-- 
Cristóbal Palmer
cmpalmer.org



More information about the TriLUG mailing list