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

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

On Thu, 2005-07-21 at 10:27 -0500, Ed Wilts wrote:
> On Thu, Jul 21, 2005 at 09:04:53AM -0400, Chester R. Hosey wrote:
> > It's also a case in which an
> > explanatory email would have been appreciated!
> 
> I haven't got time to comment on the entire thread right now (and there
> are a lot of good points being made already), but I think something like
> the following might help:
> 
> Gather the release notes for a package before downloading
> # up2date foo --release-notes
> 
> Read the release notes for an existing package:
> # rpm -qip --release-notes foo.rpm
> 
> It should be *mandatory* for all rpms to have a release-notes section.
> This is different from the changelog which is frequently too brief to
> even be useful.  I'm talking nice detailed release notes like I've been
> getting with my VMS updates for the last 20 years.
>
> [snip]
>
> Those of us used to Enterprise environments where things are documented
> extremely well and upgrades "just work", working in the Linux
> environment sometimes is frustrating.  For example, I haven't done a
> fresh install on my VMScluster since I inherited my cluster over 7 years
> ago - I've done at least 4 major upgrades since then and am currently #2
> on the uptimes site (http://uptimes.hostingwired.com/stats.php?op=active)
> 
> > 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. 
> 
> Nope - email is *not* the way since it's already too late.  If things
> change, that should be in the release notes which you're paid to read
> first.  There should be absolutely NO surprises during an upgrade.

You have a point there. The nice thing about FreeBSD is that they do try
to maintain comprehensive release notes. My background hadn't introduced
me to something that wasn't a haphazard collection of random packages. I
learned to appreciate the release notes, and the value of testing in
advance to make sure changes _should_ work, and testing immediately
after to make sure that changes _did_ work. My biggest pet peeve is when
someone will change a configuration file and restart a service without
verifying the change before moving on.

> > 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. 
> 
> Red Hat had the Red Hat Network Monitoring Module.  I can't find any
> mention of it on their US web site now but Google found it in India:
> http://www.in.redhat.com/software/rhn/monitoring/

Nagios is good. I'm honestly just having trouble understanding Red Hat's
value proposition.

It's interesting to me that every time I think a feature would be nice,
it's met with either a reason why it would be harder to engineer a
solution than to do nothing, or a reason why it's a bad idea. Either I
haven't a clue what would be nice, or I just don't understand Red Hat's
attitude towards their customers.

Here's a slightly appropriate example: Red Hat's ld said to me the other
day:

/usr/bin/ld: BFD 2.15.92.0.2 20040927 internal error, aborting
at ../../bfd/cache.c line 495 in bfd_cache_lookup_worker

/usr/bin/ld: Please report this bug.

So, being a good little follower of instructions, I report the bug and
am told told "This can happen if some other process removes or truncates
one or more of the input files (.o objects resp. .a libraries) given to
the linker on the command line between the initial linking phase and the
end of the link. As such, it would be a dependency bug in the makefiles
of the project you are compiling."

On one hand, I've got "internal error, report this bug". On the other
hand, I get "this isn't an ld bug, but a problem with your makefiles."

Huh? Is it an internal error or isn't it? Should I have reported the
bug? Why report the bug if Red Hat doesn't care?

Evolution crashed recently and told me I shouldn't be running such an
old version of GNOME. Excuse me for running RHEL4 -- is it an example of
the product gently suggesting another vendor?

There's no consistency between any of it, and Red Hat's customer
attitude seems to be that you can figure it out or script around it.
Great. And I'm a paying customer! How about acknowledging that a bad
error message is a problem instead of telling me to fix my makefile?

Does Red Hat not care AT ALL about problems that cause people to not
like their software?

> > 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.
> 
> I've done the math.  The typical lifecycle of the hardware is around 3-4
> years.  I just upgraded a server from RHL 6.2 to RHEL 3 by doing a fresh
> install on new hardware and copying the data over.  I expect to do the same 
> thing in about 3 or 4 years (it was actually about 5 before).  This
> wasn't a small server either - over 1,500 active accounts, both internal
> and external, with lots of cronjobs.  The impact to the users was
> minimal - about 2 hours of downtime (the longest downtime since the
> system was installed) and very little fallout.  There were a lot of
> major architectural changes behind the scenes too.
> 
> The bottom line is that people will simply install to new hardware.
> That's wrong, I know, compared to other architectures (like VMS) where
> new installs are not required even if you do a wholesale swap of the
> hardware.

I suppose I have higher expectations regarding server lifetime that
might be appropriate given the tools I'm using. It seems to me that an
"enterprise" operating system should support long-lived installations,
upgrades between versions, easy configuration, notifications if
something happens which might break the system.

If I'm building from scratch, I can see Dag's point about checking the
upstream feeds to make sure surprises aren't likely. I believe the best
option even for something that satisfies the wish list I've written
above would be to test, test, test, then roll out incrementally.

If I'm not building from scratch, I'd at least like to know which of the
expectations on my list aren't goals shared by the vendors. Given the
generally bad reputation that cross-version upgrades have around these
parts, I do understand that my initial request doesn't make as much
sense in this environment.

However, I don't see the downside of being notified when a configuration
file is overwritten in a potentially troublesome way. Even notify me
that it was overwritten, and let me define "troublesome". More
information is better than less.

As always Ed, I appreciate your response.

Chet