automatic nightly updates

[Joe Harrington]

> I have yet to see a scenario where
> automatic updates direct from the upstream vendor is a Good Idea on
> production systems.

Ok, here's one.  My building has about 300 employees and one system
manager.  We're a university; that's what we can afford.  Further,
he's not an RHCE or an MSCE or anything else; he's a musician and this
is his day job.  We can't afford anyone with real credentials; they'd
have to be paid more than the department chairman.  Each person here
has one or more computers.  The mix is very heterogeneous, about
evenly divided between Linux, Sun, Mac, and PC.  The hardware is
whatever was hot when the person bought the computer.  There are no
"recommended configurations" or anything like that; you get what you
can get a good deal on and that fits your needs.  Each senior person
controls his own budget.  Very few are people who would know what to
do with a root password.

The main tasks our system manager worries about are making new user
accounts on the department's shared machines, installing and
configuring new machines as people buy them, installing and
configuring the third-party software they need, fixing hardware
that breaks, and maintaining our servers.

Needless to say, manually updating the 600 or so computers here is
*low* on the system manager's list, but it's of course crucial that it
happens, as are all the other things.  So, automatic updates are the
way we go.  If an update were to break something (hasn't happened
yet), people would squeal, he'd figure out what happened, and if there
weren't another update forthcoming that fixed it, he'd write some
scripts to back out the problem update and tell people to run them.

Yup, folks, we're a zoo.  And, the situation is the same in nearly
every university department in the country, save for the mix of
machines.  Add onto our millions of machines those of private
individuals, and you get a sizeable audience of people for whom auto
update, no matter what the OS, is the best thing since the invention
of ketchup.

There are many situations where you wouldn't want auto update, some of
which have been outlined here by people whose responsibilities cover
them.  In many of those situations, RH itself would tell the customer
it should never be running Fedora, it should be running RHEL.
Fedora's low cost and its declared experimental nature predisposes it
to be run in situations like ours.

If you don't believe that many people auto-update, do some statistics
on your web servers for FC1.  Calculate the *local* time of each
request for the repo data (i.e., the first yum request).  You'll have
to do a lookup on the IP address and figure out what time zone they're
in to do that.  Then plot a histogram vs. local time.  I'll bet money
that you get more hits in the 4:00am - 6:00am range than during any
other time.  Cron.daily fires at 4:02 am and FC's scripts throw in a
random delay of up to 2 hours.

My point is simple: since auto update is very common and a good idea
for many people, FLP should document the practice and gear its
services to it.  It means a little more care in putting the updates
together, but not much, and certainly not more care than you are
already taking.  Gearing toward auto updates will not hurt manual
updaters at all.

Don't worry about making "formal recommendations" on whether to
auto-update.  Clearly, it's a good choice for some, a poor choice for
others.  Rather, write clear descriptions of the pros and cons.
Anyone running Fedora is self-supported and had better be able to read
the pros and cons and decide what best fits their particular situation
best.

--jh--