On Mon, Mar 27, 2000, Doug Barton wrote:
> One solution that was experimented with a while back, and referenced
> again in PR 17595 was to put a checkpoint variable in
> /etc/defaults/rc.conf which would prevent it from being recursively
> sourced. There are two problems with this strategy. The first is that
> users who define both an /etc/rc.conf and an /etc/rc.conf.local will not
> have the second file sourced on rc's first run through the rc.conf's.
> More serious is the fact that there are other scripts in /etc/rc* (like
> rc.firewall, rc.network, etc.) that source the rc.conf's themselves.
> Using this checkpoint variable method those scripts first source
> /etc/defaults/rc.conf, then don't go on to source the files in /etc.
> This prevents them from reading in user defined overrides to the
> defaults. This is disastrous in cases like rc.firewall, where for
> example the firewall type would never get defined as "open", so the
> machine is cut off from the network on reboot if ipfw is compiled into
> the kernel.
Ok, I tried something a little different.
I wrote a script called 'getconfig', whose sole existence is
to read /etc/defaults/rc.conf, /etc/rc.conf, and then any other
scripts that are in rc_conf_files (well, it didn't have to
read /etc/rc.conf, but I forced it anyway ..)
Then each startup script which loaded /etc/defaults/rc.conf and
tried to load /etc/rc.conf was modified to load /etc/getconfig
instead.
Since no code exists in the conf files, if the user copies them
around willy nilly, they don't cause a loop. It also means
that you could possibly put sanity checking code in getconfig
to make sure the user hasn't done anything blatantly stupid
(I can't think of anything, but then, I don't cp /etc/defaults/rc.conf
/etc/rc.conf that frequently either .. )
So, the question is: What have I missed this time ?
Adrian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
