Re: use of current on production systems

On Fri, 2002-10-04 at 19:53, Mike McCallister wrote:

> that and just implement a solid server for up2date.  However, I am still 
> REAL nervous about letting some automated processes get updates from a 
> server and then manually update/install them.  The system I have in 
> place now (a few shell scripts and wget) basically allows me to update 
> stuff but I still do the final install by hand.  I realize up2date has 
> gone through several versions, but I am still skeptical.  If these 
> systems go down, it is my @#% in a vice in a major way - it will be 
> painful.  The problem is that the sys admin stuff is distracting me from 

There's no getting around the fact that at this level of automation,
we've reduced the effort needed to totally destroy entire networks down
to a single cronjob, assuming somethings really really broken.

Having said that, I or john should have been the people to see total
system devastation by now, and we havne't. 

We get python tracebacks (python equivalent of a core dump) fairly
regularly, but not total system devastation.

However, if you're not comfortable with an automated approach, you're
not comfortable with an automated approach. Arguing about it is like
arguing with a person choice of favorite color.

> software development so I want to automate it a little more.  How many 
> people on this list have a high level of confidence in both the security 
> and reliability of the current/up2date combination?  Also, can kernel 
> updates be cancelled?  I checked the up2date man page but there was no 

Look at your /etc/sysconfig/rhn/up2date file.

fileSkipList skips any package that would touch file /some/path/here

noBootLoader keeps up2date from touching your boot loader config

pkgSkipList skips any package listed - and by default, the kernel is
listed

noReplaceConfig skips any package that would change your systems
configuration (config files are marked specially in the rpms themselves)

removeSkipList list of packages that up2date will never remove,
regardless of what its told.

and finally, retrieveOnly, which would allow you to configure up2date to
only download all the packages (and dependancies) it needs, and NOT
install them. you could then manually install whatever. Kind of like an
rpm -F with full dependancy resolution and network access.

These are all features of up2date by the way - current interacts with
none of them. So obviously the RHN team had other cautious admins in
mind when they wrote up2date.


> mention of it here.  Obviously, I could just not make those RPMs 
> available for that given channel, but I would like to just mirror 
> updates from Red Hat - which will download them.  Suppose I could just 
> filter those out - anyone else know how kernel updates are handled?

My recommendation? 
Based on user comments here over the last year or so, it either works
for people or it doesn't. I have no hate mail from anyone saying "you
broke my box". I have plenty of email saying "It tracebacks, you
Q!$%%$^&".

So, IN MY OPINION, current/up2date is unlikely to totally mangle your
world. (Other than particular updates managling your world, like the
very recent problems with the glibc update for mysql users - I can't fix
that).

So, what to do?
Pick a victim machine or three, install the server and client, and see
what happens for a while. Test it. Feed it packages from outer slobovia.
Or most any random selection from redhat contrib. Or, shudder, even
rpmfind.net. Use all the command line options on up2date with a tree
full of kernel packages from your 3 year old son. Find a  secretary, and
tell him/her to run up2date every morning on those test boxes.

Beat it up. Take it behind the woodshed every day for a week. If it
breaks, OBVIOUSLY don't turn it on on your other systems. And if it
broke because I'm a !$%^&^, send me email with what happened.

-- 
Hunter Matthews                          Unix / Network Administrator
Office: BioScience 145/244               Duke Univ. Biology Department
Key: F0F88438 / FFB5 34C0 B350 99A4 BB02  9779 A5DB 8B09 F0F8 8438
Never take candy from strangers. Especially on the internet.