RH tools and conf changes (was: Re: Vi backspace key problem)

["Chester R. Hosey" <Chester Hosey gianteagle com>]

On Thu, 2005-07-21 at 09:05 +0800, John Summerfied wrote:

> [Points about Debian restarting services on upgrade snipped]

You've made some good points. This wasn't a Debian-rules-Red Hat-sucks
comment, but "dpkg implements this feature, perhaps Red Hat could find a
way to work something similar into their chain of tools".

Specifically with respect to restarting services, I agree that
restarting by default isn't always desirable. However, it does make
sense in the case that you have a lab set up for initial testing before
rolling updates out to production machines. A few years ago I was bitten
lightly when I ran "make world" on a FreeBSD machine in England and
didn't catch a change in the configuration defaults which kept sshd from
starting. A few weeks later the machine was restarted; it took me a
while to track down and resolve the problem.

That's a case in which an automatic service restart would have brought
the matter to my attention immediately after upgrading the system (and
thus helped to isolate the problem). It's also a case in which an
explanatory email would have been appreciated!

I was new to FreeBSD at the time, and yes there's a file somewhere that
tells you what you should be aware of when upgrading the system, but
email is a great way to notify admins of pertinent issues. Of course
this taught me to always restart services myself, always check log
files, always preverify configuration if possible (apachectl configtest
and such).

I didn't say "Debian does everything better" or "FreeBSD is naughty".
However, notification of issues which can be easily identified by the
package management software and flagged for administrative review is a
Good Thing.

Another good thing would be for RHN to allow admins to restart a single
service from the administrative interface. Hell, if Red Hat wanted to do
it RIGHT they'd even integrate basic service confirmation into RHN. Let
RHN monitor services which have been restarted per request, and for
machines which aren't routable and can't be accessed via satellite
servers at least let up2date include logic to make sure that a service
which has been restarted per request comes back up.

If they wanted to _really_ impress me (which should obviously be
everyone's primary goal in life, right?) they'd go so far as to
integrate actual monitoring into RHN. Give RHN more value, give the
satellite servers more value, give the customers more value, reuse
existing interfaces for additional functionality, yadda yadda yadda.
It's a win-win situation. There are certainly technical objections, but
it would be a great thing for Red Hat to be able to offer monitoring
"for free" to RHN customers.

> [Debian-installer-has-issues snipped]

I agree. Debian targets many architectures, and insists that things such
as the installer work across all of them. I definitely recognize
Debian's shortcomings; however, this doesn't remove the fact that one
particular tool offered by Debian performs a useful function which would
be nice under Red Hat as well.

I've also kept Debian machines running for years without a
reinstallation. There's a machine which I installed in 1999 and is still
running on its original installation, but has been upgraded to current
without issues. Red Hat recommends not upgrading a single machine more
than once; a RHEL 3 machine can go to RHEL 4, but they recommend
reinstalling when RHEL 5 goes live. This means that a machine cannot
keep current with RHEL for more than three years (on an 18-month release
cycle).

Yes, I realize that RHEL is supported for N years (where N>3, I believe
it's around 7 actually). However, there's a difference between a
"supported" distribution and a "current" one.

The point? I honestly believe that one reason why the Debian installer
sees so little attention is because Debian installations tend to have
long lives. If you do the math, Red Hat recommends that a single RHEL
installation not last for more than three years if your goal is to stay
current. More usage == more attention.

None of this has anything to do with the fact that it would be a nice
feature for Red Hat's tools to flag potential configuration issues.

Chet