<Note: the opinions expressed do not necessarily reflect the opinions
of RHEL product management, etc....>
Ed Brown ([EMAIL PROTECTED]) said:
>> The reason things like that are installed in the default minimal
>> install is that there's not a good mechanism to automatically grab
>> hardware-specific packages specific to your machine. If something
>> like that comes around, that can change.
>
> It really seems like you're NOT listening to what has been said over and
> over on this list, not just in this thread. Many of your customers would
> like you NOT to look out for us so thoughtfully, ultimately requiring us
> to work harder to undo your thoughtfulness.
I hear you, but...
> I know that's not everyone, or perhaps even most people.
... this is the key point. It's a tradeoff, optimizing for the most common
case that (for better or worse) causes the least *total* confusion among
customers, users, and admins.
Considering the case of hardware-enabling packages, the current
situation:
1) those that need it have it by default
2) those that don't need it:
a) will have a package that isn't doing anything by default
b) can uncheck the group/package
c) can use kickstart
d) can remove it later
A proposal that deselects <this group of packages>
3) those that need it will have to manually select the
group/or package. If they don't know that they now need
to do this, or they don't know what the specific package
name they need is, they're in trouble.
4) those that don't need it won't have it
The case here that's most likely to generate load on support/documentation/
engineering is 3. 1, 2a, and 4 generate no to very little load on
support/development/documentation. 2b/c/d causes annoyance (as you
state), but for better or worse, people in your situation are those
that are most able to handle the customization/changes themselves.
(isdn is a bad example, FWIW - I shouldn't have chosen it. It's not
even *in* the base or core groups. Disabling dialup by default might
be reasonable in RHEL 6.)
As long as it's shipped in a one-size-fits-all manner like it
currently is, that's the choice to make. That may be the underlying
issue - a better way to expose these things, or a different product with
a different default configuration.
> I, and likely everyone else on this thread, absolutely are using
> kickstart. But to be honest, I haven't actually taken a serious look at
> --nobase. I will. And sectool is a step in the right direction, though
> it sure doesn't look like it will be ready for RHEL6 either.
It's in Fedora now. How much of it will be done by RHEL 6 is
up in the air, of course, and we want to be running it regularly
on Fedora to make sure that:
- it's not complaining about anything it shouldn't
- we can fix things that it does complain about
>> Well, I'm not sure scouring the net for guides to disagree with is
>> practical, but critiquing some of the common ones could be useful.
>
> You know, there's a flipness or arrogance in your comments on this issue
> that is really disturbing. (The crack/snake oil thing was a beaut.)
Well, experience with Bastille has hardened me.
> Anyone who studies or takes system administration seriously (again,
> probably not your average customer) is familiar with secure
> configuration guidelines from CIS, NIST, SANS, NSA or possibly others.
> The NSA's, specifically for RHEL5, is 170 pages (and supposedly was
> developed with input from RedHat, though it still has some bad and/or
> arbitrary advice, in my view).
You mentioned the guidelines, I read them over. When an initial
scan reveals 'advice' such as:
- disabling pam_console handling of DRI devices, which has the effect
of either:
- making the devices 0666
- crippling the X server
- removing module files shipped with the kernel to disable features,
which is an impressively hacky and bad way to do it (Maintaining lists
of modules to remove sounds like so much fun.)
- decries IPv6 as being new and untested, when it predates the existence
of RHEL by 5+ years (and is actually pushed to be default in
RHEL by... government standard. ;) )
- has contradictory guidelines on the same page about yum
- describes kudzu as allowing hardware configuration by unpriveleged users
...
None of these things fall under 'sensible', and it makes me rather
skeptical as to the guidelines' overall quality when I read this. It may
not have been obvious, but this is the first time I've seen them. If I
had seen them earlier, I would have loved to have gotten them fixed.
(They certainly weren't passed around for general review.)
The biggest issue is that for any package, there is one set of bits, that
ranges from corporate desktop to SMB server to compute cluster node to edge
print server to shell server to development workstation. This greatly affects
what you can do.
The options that are there right now are:
- turn off dialup by default
Probably reasonable, although those on ISDN may differ.
- Expose the distinction between Base & Core in the UI,
and flip what's default in kickstart
Considering Core includes neither yum nor rpm, this needs
work - some things would need moved from Base to Core.
I suppose that could irritate those people that want a really
tiny core group, but I'm willing to irritate them - if you
don't even want a package manager, you're way outside the normal
install case.
This doesn't help the issue of defaults for particular services or
packages, but that can't be done without changing the packages themselves
right now. [1]
Bill
[1] There's support for system-wide overrides for chkconfig in rawhide, but
we don't use it for anything right now
_______________________________________________
rhelv5-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/rhelv5-list
