[lug] Redhat doesn't support users that compile their own kernels.

[D. Stimits]

"Michael J. Hammel" wrote:
> 
> Thus spoke D. Stimits
> > They seem to be refusing to consider this unless I run a RH kernel,
> > which I cannot do since I have XFS. However, other people have also
> 
> So you're using your own kernel on a unsupported filesystem?  I gotta go
> with Red Hat on this one too.

It is a mistake to think the kernel is involved. There is a badly
misunderstood point here: *ALL* kernels, when they have iptables module
loaded, will NOT load ipchains. They are mutually exclusive. The bash
scripts seem to fail to check return values. If ipchains module is
properly loaded, a failure will show up from the init scripts. If
iptables is instead loaded, and ipchains does not start up due to the
mutual exclusion of both modules being loaded at once, the bootup init
messages will not show this failure. It has nothing to do with it being
a redhat kernel or anyone else's kernel. The filesystem is absolutely
unrelated. This is part of the point redhat is missing...it does not
matter that I don't have a redhat stock kernel, loading iptables will
deny loading ipchains, and the init script will not show up with a
failure message during bootup. They saw I have a non-redhat kernel and
stopped reading after that. My filesystem and kernel has nothing to do
with mutual exclusion between iptables and ipchains modules.

> 
> While you have found an issue that should be addressed, you have to view
> from their point of view of resources:
> 
> 1. It's not a show stopper - work can continue.  Result:  no developer will
>    get assigned to it immediately.

It means that all machines that are expected to be protected by ipchains
rules, if they accidentally load iptables module, will be rooted.

> 
> 2. It's minor and no fix is provided by you:  Requires someone assigning it
>    to a developer to track it down and fix.  Result:  it gets stuck at the
>    bottom of a growing queue and will never be looked at.  Cleaning out
>    that queue is the job of a project manager - who is graded by how fast that
>    queue shrinks - and removing minor bugs that can be offloaded as "not our
>    problem" is the fastest way to do that.

Yes, I reported it like 2 months ago. I don't have a fix because I'm not
a bash programmer.

I get ticked off when a totally unrelated non-redhat kernel is used as a
reason to not even look at it. It isn't irrelevant because it means you
can be rooted within a day of thinking you were protected.

D. Stimits, stimits at idcomm.com


> 
> 3. A tester can apply a user supplied patch on his own and try the result.
>    If it works, he can hand it directly to a developer for checkin (after a
>    quick check to make sure it doesn't break any security, which a minor fix
>         like this won't).  Result: the problem is addressed without going
>    through scheduling.
> 
> So supply the fix you deem appropriate in a new bug report.  It has a much
> better chance of being included because it won't require scheduling a
> developer to track it down.
> 
> Note that it's irrelevent if the bug is easy to find.  In fact, the easier
> it is to find the less likely anyone will be assigned to look for it.
> Developers are paid big bucks to fix big problems.  Little problems get
> fixed as time permits.  At least that's how it's always worked in all the
> software shops I've worked in (and that's quite a few, actually - and
> looking for yet another *sigh*).
> --
> Michael J. Hammel           |
> The Graphics Muse           |   Democracy is a beautiful thing, except for that
> mjhammel at graphics-muse.org  |     part about letting just any old yokel vote.
> http://www.graphics-muse.com
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug