Date: Mon, 27 Mar 2000 02:24:24 -0800 From: Doug Barton <Doug@gorean.org> To: Adrian Chadd <adrian@creative.net.au> Cc: FreeBSD-current@freebsd.org Subject: Re: conf/17595: Preventing cp /etc/defaults/rc.conf /etc/rc.conf from looping Message-ID: <38DF36D8.EE1E8706@gorean.org> References: <20000325103755.10128.qmail@ewok.creative.net.au> <38DCA346.58CFC148@gorean.org> <20000327083736.A4402@ewok.creative.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
I took another look at this problem, and before I go forward with more
testing I wanted to solicit some comments. The problem is that users who
don't read blindly copy /etc/defaults/rc.conf into /etc. Because of the
recursive call at the end of /etc/defaults/rc.conf when you copy the
file into /etc it gets sourced once by /etc/defaults/rc.conf, then keeps
sourcing itself in /etc/rc.conf forever (actually, till the system runs
out of fd's).
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.
The method I've finally arrived at is to replace the simple recursive
source at the end of /etc/defaults/rc.conf with a combination of the
checkpoint variable and the definition of a function which handles the
recursive sort. This function uses a local variable to keep track of
which files it has sourced already. This eliminates the possibility of
infinite recursive source's, while also allowing other files to source
the rc.conf's both within rc, and independently. The only thing that has
to change is that the files which need to source the rc.conf's will need
to add a call to this new function. Here is the function:
if [ -z "${sourcercs_defined}" ]; then
sourcercs_defined=yes
sourcercs ( ) {
local sourced_files
for i in ${rc_conf_files}; do
case "${sourced_files}" in
*:$i:*)
;;
*)
sourced_files="${sourced_files}:$i:"
if [ -f $i ]; then
. $i
fi
;;
esac
done
}
fi
In (for example) rc, this:
if [ -r /etc/defaults/rc.conf ]; then
. /etc/defaults/rc.conf
elif [ -r /etc/rc.conf ]; then
. /etc/rc.conf
fi
would change to this:
if [ -r /etc/defaults/rc.conf ]; then
. /etc/defaults/rc.conf
sourcercs
elif [ -r /etc/rc.conf ]; then
. /etc/rc.conf
fi
I realize that this solution may seem overly complex, but it allows the
greatest amount of flexibility while at the same time unloading a gun
that lots of users have shot themselves in the foot with. It works with
the little test suite of conf files and scripts that I created to
simulate the rc* files. I plan to do more thorough testing tomorrow with
actually patching my rc* files and rebooting.
Comments welcome,
Doug
--
"So, the cows were part of a dream that dreamed itself into
existence? Is that possible?" asked the student incredulously.
The master simply replied, "Mu."
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?38DF36D8.EE1E8706>