Bill Nottingham wrote:
When the alternative is "wait, you can't talk to the network because
ISDN/bridge tools/etc. aren't installed", absolutely.
Nonsense. You're already on the network, installing the OS. You can
install what you need at that point.
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 know that's not everyone, or perhaps even most people.
In the meantime, "%packages --nobase" in kickstart should solve your
needs - if you're trying to install a large group of servers, you
absolutely should be using kickstart.
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.
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.) 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). It seems like your biases, or lack of
familiarity with the issues that your government customers, at least,
are facing or going to be facing, with respect to these secure
configuration guides, allows you to dismiss them too easily. As I
said initially, some of us don't have that option, we are having to
assert compliance with some such standard. Apparently because it is
widely understood, outside of Redhat anyway, that RedHat's default
'sensible security' isn't really so much about security as about
usability. I'm not saying usability's not important, I get that. But
it just seems like you're really not getting that security is a higher
priority for some of your customers.
-Ed
_______________________________________________
rhelv5-list mailing list
rhelv5-list@redhat.com
https://www.redhat.com/mailman/listinfo/rhelv5-list
