[wplug] I'm a Linux whimp (need kernel help)

[Chester R. Hosey]

On Mon, 2005-08-15 at 13:50 -0400, Vanco, Don wrote: 
> >-----Original Message-----
> >From: wplug-bounces+don.vanco=agilysys.com at wplug.org 
> >[mailto:wplug-bounces+don.vanco=agilysys.com at wplug.org] On 
> >Behalf Of Chester R. Hosey
> >Sent: Monday, August 15, 2005 11:26 AM
> >To: General user list
> >Subject: RE: [wplug] I'm a Linux whimp (need kernel help)
> >
> >
> >On Mon, 2005-08-15 at 11:02 -0400, Vanco, Don wrote:
> >> >-----Original Message-----
> >> >From: wplug-bounces+don.vanco=agilysys.com at wplug.org 
> >> >[mailto:wplug-bounces+don.vanco=agilysys.com at wplug.org] On 
> >> >Behalf Of Chester R. Hosey
> >> >I get the impression that Red Hat's position is that you 
> >shouldn't be
> >> >using a kernel other than theirs anyways. You should install their
> >> >package and be happy about it.
> >> 	Not as much Red Hat as the ISVs (although arguably no one tests
> >> an Enterprise-designed kernel like RH).  Case in point, Oracle checks
> >> for kernel checksum when requesting support in some cases.  
> >> 	If you can't grasp the logic behind this type of mandated
> >> package use there's likely little point in you running RHEL.
> >
> >Whoa, there. I didn't say that I don't understand the preference for a
> >stable, known base upon which ISVs could base their tests -- I did say
> >(or at least I tried to imply) that it seems that Red Hat doesn't seem
> >to make it a priority to make kernel customization easier on users.
> >
> "You" as in "You, the general user".  No personal point meant here.

That was quite not quite clear to me.

> As far as Red Hat & making kernel customization easier, the entire point
> of their relatively universal kernel was to (at least in part) reduce
> help desk calls by providing a somewhat universally functional kernel.
> Over 50% of calls they got (at one point circa RH9) was stupid user
> error in building a custom kernel.

Aye. I'm not surprised.

> Further - why does recompiling a kernel need to be user friendly?  It's
> a complex system whose components potentially have a high degree of
> interdependence, and frankly if you've little idea what you're doing
> you're better off with "one size fits all".  (again, the "you"s here are
> intended as universal)

There are certain choices which can be made that don't strongly affect
the resulting product but which can make it easier for those who are so
inclined to make local modifications.

For instance, under Debian I can very easily build packages as a non-
root user and without special permissions to any particular directory.
Under Red Hat, I'd imagine that the same is possible, but it's certainly
not default behavior.

This means that if you're using a fast machine to build RPMs for use on
a slower one, you'll find it easier with root access on the build
machine, including running the actual compilation as root, despite the
fact that nothing involved should require superuser privileges. This
doesn't make it impossible to do what I want, but it makes it a little
less friendly.

Even unpacking a SRPM is a pain -- rpm2cpio? What for? Why isn't RPM
based on standard format in the first place?

> >Upon further review, it does look like the resident size is 
> >under a meg.
> >That I misinterpreted, and I will rescind my statement. However, where
> >did I say that I can't understand or appreciate the purpose of rhnsd?
> 1) in the fact that you state that as far as you can tell all it does is
> periodically run rhn_check.  It's a daemon - it listens, it waits for
> connection, it enables lots via RHN

According to netstat -ntlp, it isn't listening or waiting for
connections. I did run gdb and attach to the process -- it seems to be
calling select() periodically, but that's hardly a large task. I would
be surprised if rhnsd itself were very complex -- start, connect to RHN,
run external commands as needed, wait a bit, repeat until killed.
Enabling via RHN consists of calling external commands.

...

In fact, I just looked at the source, and it does exactly as I
originally claimed -- it simply passes everything on to rhn_check. The
daemon itself does very little. I don't even see any networking code.
Its use of select() is to process any output from rhn_check, and as a
timing mechanism.

> 2) in your statement that it doesn't offer any kind of useful logging on
> failure.  Try configuring a machine incorrectly and running up2date,
> then look at the contents of /var/log/up2date  
> Here's a quick example:
> 
>  up2date Error communicating with server. The message was:
> 
> Error Message:
>     Your account does not have access to any channels matching
> (release='4', arch='i686-redhat-linux')
> If you have a registration number, please register with it first at
> http://www.redhat.com/apps/activate/ and then try again.
> Error Class Code: 19
> Error Class Info: Architecture and OS version combination is not
> supported.
> Explanation:
>      An error has occurred while processing your request. If this
> problem
>      persists please enter a bug report at bugzilla.redhat.com.
>      If you choose to submit the bug report, please be sure to include
>      details of what you were trying to do when this error occurred and
>      details on how to reproduce this problem.
> 
> 
> ....dunno how much else they could include before it becomes "useful
> information"......

It could be "useful information" if it logged failures to connect to RHN
for reasons other than configuration.

For instance, I had several systems stop checking in during some RHN
downtime recently. Nothing was produced in the logs -- manually running
rhn_check would succeed, but rhnsd was making no attempts to start
rhn_check.

Restarting rhnsd caused check-ins to resume, but did nothing to try to
isolate the original problem. I shouldn't have to restart rhnsd due to a
temporary RHN problem, but that's what happened. I understand that
verbose logging isn't always desired, but how about trapping USR1 for
in-flight enabling of verbose logging without restarting the process?

Besides, rhnsd does very little logging itself. Check out the source --
there's very little done by it.

> >And if I "don't need to be running RHEL" if I "can't understand /
> >appreciate what the RHN daemon is all aboot", then why would I 
> >bother to "just pull it" but continue using RHEL?
> 	OK - since when is rhnsd a requirement of running RHEL? (HINT:
> it's not)  There are many ways to update from and/or utilize RHN that
> don't require the daemon.

Since when did I say that rhnsd is a requirement of running RHEL? (HINT:
I didn't). I simply repeated your statements -- you said "if you can't
understand / appreciate what the RHN daemon is all aboot you likely
don't need to be running RHEL". Those are your own words.

What I said was that if, as you say, someone who doesn't appreciate
rhnsd shouldn't be running RHEL, then why would someone who doesn't
appreciate rhnsd continue running RHEL?

> >I'll admit when I'm wrong. It happens often enough that I don't
> >understand your desire to make claims about my understanding 
> >or position that simply aren't true.
> 	Again, no direct implications meant.  At least part of this
> (kernel config & bloat) is based in philosophy anyway, so there's really
> no right or wrong....

Again, that was unclear.

> 	And if you care to look at my posts strictly on this forum, the
> only time I come out of the woodwork is when folks start to misquote
> about RH or we hit the 80th OT message on "Pittsburgh DSL".  
> 	Why does everyone take my emails as hostile?  It's no wonder I
> never post here anymore......

I made statements of the form "I feel as though ...". Your "If you can't
understand... then there's little point..." sounds like a direct response
to my statements. If you want to be taken as "not hostile", perhaps you
could take caution to make it clear whether you are addressing a specific
person ("you") or a general group ("people", "users", etc.).

Besides, it certainly sounds like you're sensitive to what you perceive
as Red Hat-bashing, whether or not it is actual bashing. If you think
that people have misconceptions, your productive options are to keep silent
or to try to help people locate the sources of misunderstanding.

Ranting about how people who don't sufficiently appreciate rhnsd
shouldn't be using RHEL is rather presumptuous, and doesn't provide
anyone with a better understanding of the software which you defend.

Chet