Blog Entry

cbetanco's picture
blog
Reads:

4860

Score:
2.5
2.5
2
 
Comments:

2

Patch Management best practice

Author Info

28 February 2010 - 5:28pm
Submitted by: cbetanco

Author Blog
Author Profile

Tags

Tags Map

(View Disclaimer)

I am researching how to setup an Enterprise Patch Management. We plan to design a set of standard patches for SLES 10 and OES2 in a centeralized repository. I read that a pair of tools are available for this purpose, SMT and NCC.

I believe that SMT is an add-on tool that registers each system and collects detail on installed modules that can be viewed in a centeralized report. NCC (Novell Customer Center) provides a list of systems but no detail on pending Patches.

What research I have thus far, favors using a Local Repository to collect updates from Yast Online Update, then select which updates to post.

I'd like hear other opinions and deployment strategies.

Charles.


Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).

It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.



Related Articles


User Comments

paulgear's picture

One of the related articles

Submitted by paulgear on 15 October 2010 - 5:16am.

One of the related articles ("What the world needs now is a better SMT" - http://www.novell.com/communities/node/9404/what-w...) is a blog entry i wrote a while back, and there were some good comments as well. Everything in it still holds true as far as i am concerned.

jalmda's picture

Software is the objective

Submitted by jalmda on 24 October 2010 - 11:35am.

Our point of view is that operating systems are something of a burden, and having to patch them makes them doubly so. Not to pick on Linux/SUSE, but Linux is not the objective -- delivering our own software is.

For several reasons, including regulatory policy, we have patch our systems and install up-to-date operating systems, for ourselves and customers. This is unavoidable despite numerous rational arguments to the contrary.

So we collect patches on a quarterly (roughly 3 to 5 months) interval, using SMT. These are then used to update our systems regularly, and provide a consistant environment for our delivered systems. (Some people call this configuration management, although this is the software engineering sense, not the more loosely defined sense used in the linux/system admin world).

But there are complexities: keeping our in-house systems up to date conflicts with supporting customers who have not yet received our updates (we don't let them update SLES or our software directly). So we have to provide two environments, or coordinate customer updates with our "factory" set, or both.

When we have to upgrade to SLES11 (currently we are at 10SP3) then new complexities arise -- the diversity of environments will be an issue as well as delivering software that is (more) compatible with SLES11 than SLES10 (our experience going from SLES9 to SLES10 guides us here).

All the above is not handled at all well by Novell SMT (nor Redhat for that matter). We have to add a lot of process documentation and disk space and training to do this right. OK, maybe it is just because of how we do things, but for an Enterprise system there should be some feature set that meets Enterprise expectations.

--John

© 2012 Novell