[TriLUG] Approaches to Linux Patch Management

[Igor Partola]

Running a local repo is not particularly difficult. I do this at work, and
we have a testing and stable repos. Packages first go into testing before
we upload them to stable. This means pretty much just using apt for all of
our deploys which sounds similar to your situation.

You might also look int apt's package pinning. Not sure which way will be
easier, but pinning would let you hold patches back for a while.

Igor
On Jun 12, 2012 1:55 AM, "John Wheeler" <jwheeler at etherealfringe.com> wrote:

> Hello all,
>
> I don't post to the list much, mostly just watch to glean bits here and
> there.
> Today though, I am trying to derive the "correct" approach to patching an
> enterprise linux platform and was hoping that you guys would have some
> suggestions.
>
> In this case we are running Ubuntu 10.04 Server in Amazon EC2.
> We have standard OS patches as well as 3rd party software patches to
> handle.
>
> The business has asked that we, as a new open source initiative, bring our
> patch cycles in line with their periodic  approach to patching M$ servers.
> The idea being that our test systems run the latest patches for a period
> of time before those patches are applied to production.
>
> 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.
>
> 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?
> What do you guys do?
>
> Any insight that you gentlemen have to offer is highly regarded and
> appreciated.
>
> Thanks,
>
>
> John Wheeler
> Web Applications Developer
> --
> This message was sent to: Igor Partola <igor at igorpartola.com>
> To unsubscribe, send a blank message to trilug-leave at trilug.org from that
> address.
> TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
> Unsubscribe or edit options on the web  :
> http://www.trilug.org/mailman/options/trilug/igor%40igorpartola.com
> TriLUG FAQ          :
> http://www.trilug.org/wiki/Frequently_Asked_Questions
>