On Wednesday, January 30, 2002, at 11:40 PM, Mark Woodson wrote:
> I don't feel that the current system needs changing. It's my thought
> that if you go to the extra trouble of compiling ipfw or ipf into the
> kernel, then you want it and you get it. No matter what you've set in rc.
> conf.
I see nothing wrong with creating/using a more generic kernel and system
configuration. I have several identical computer systems and I have a set
of
services that those systems are to provide. I'll be installing/configuring
each system so that any system can provide any/every service. The only
difference is that for each service "foo", only one system will have
foo_enable="YES"
in its /etc/rc.conf. Ideally, I can move, failover, or load-balance a
service,
I need only modify the rc.conf file (and probably modifying the DNS).
I see simplicity and correctness that I can prepare my systems to be ready
to serve, but with the protection when I explicitly say "NO", the system
understands that I mean "NO".
> Perhaps the docs should be modified to make that behavior more clear, but
> if you have a machine set up as a firewall having it's functionality as a
> firewall eliminated by setting enable="NO" is unacceptable from a
> security standpoint.
And therein lies the real problem. The current configuration is misleading
and--to many of us--undesirable, even wrong. But security concerns make it
hard
to correct. It's wrong, to me (and I don't think I'm alone in this),
because I believe that clarity in rc.conf is more than a desire, it's an
objective. When the rc.conf file
includes
foo_enable="NO"
it's right to expect that the system will operate like a system that does
not
have foo installed.
Paul Fardy
--
Systems Administrator
Computing and Communications
Memorial University of Newfoundland
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
