Re: Making powerd=YES default

[Steven Bellovin <smb%cs.columbia.edu@localhost>]

On Aug 3, 2011, at 10:55 33PM, jean-Yves Migeon wrote:

> On Wed, 3 Aug 2011 22:26:31 -0400, Steven Bellovin wrote:
>>>> How about this: read defaults/rc.conf *after* reading rc.conf, but use
>>> 
>>>>    : ${varname:=defaultvalue}
>>> 
>>>> to set it.
>>> 
>>> Nice idea, but how do you deal with all the existing rc.confs which
>>> have the ". /etc/defaults/rc.conf" _first_, rather than _last_?
> 
> IMHO that should have been done that way first. But read on.
> 
>>> You could make /etc/defaults.rc.conf empty and put the defaults in
>>> another file, but then how do you get that file included in the legacy
>>> rc.confs?
>> 
>> postinstall?  etcupdate?  Let's first figure out where we want to go,
>> and then figure out how to get there.
> 
> Indeed; unfortunately it's problematic to have something working acceptably 
> in postinstall/etcupdate that won't bork up the end-user's /etc/rc.conf. As 
> explained in rc.conf(5), end-user may put whatever he wants inside, and this 
> can lead to complicated parsing/editing.
> 
> IMHO postinstall/etcupdate shouldn't push big changes in /etc/rc.conf: risk 
> being either an incorrect /etc/rc.conf which can cripple a boot entirely. Or 
> have something that requires user's intervention to fix and is not as simple 
> as "don't use foo because its obsolete. use bar-YES instead".
> 
> With all the potential side affects hiding behind, I am not prepared to make 
> such a paradigmal shift (e.g. moving from defaults overriden by end-user to 
> end-user overriden by defaults in case it's not set).
> 
I suspect that my idea will give the same result for any rc.conf that
doesn't check for already-set -- and I don't see why any should make
such a check.

Here are my proposed semantics for the upgrade code.

First -- these three lines are the first non-null, non-comment lines
in rc.conf:

        if [ -r /etc/defaults/rc.conf ]; then
                . /etc/defaults/rc.conf
        fi

If that isn't true, print a message and don't autoupgrade.

Second -- look for "exit" in rc.conf.  Its presence denotes
user complexity; scream for help.

Third -- look for "if" (except as above), "for", "while", "case",
"test", or "[" as commands; again, they represent a complex case, 
so scream for help.

Fourth -- delete the standard code from the beginning (along with
its comments) and add them to the end.

I note that etcupdate today is fully interactive and postinstall
already doesn't handle certain fairly mundane tasks (like adding
new system users to /etc/master.passwd.  I don't think this situation
is particularly different.


                --Steve Bellovin, https://www.cs.columbia.edu/~smb