On Jan 1, 11:37am, Greg A. Woods wrote:
} Subject: Re: /etc/default ickiness...
} [ On Friday, September 15, 2000 at 16:36:52 (-0700), John Nemeth wrote: ]
} >
} >      Your solution really doesn't help me much (I have many machines
} > spread all over the city to maintain).  You make more work for me,
} > since I have to look in one file and then make changes in another
} > file.  At upgrade time, I need to compare the old and new /etc/default
} > files to see what has changed in order to make any necessary changes to
} > the /etc files, which is an additional step that wasn't there bofore.
} > Or, I could just start my /etc files from scratch.
} 
} That's because, as you admit below, you're making your own life harder
} on yourself!  :-)

     I don't believe I am doing that.  You keep trying to convince me
to use your methods.  I've used all sorts of methods and I know what
works for me and what makes life harder for me.  We'll probaby never
agree on methods, so why don't we just agree to disagree and you can
stop trying to convince me to use your methods, which is an exercise in
futility?

} If you simply put only the locally changed variables in /etc/rc.conf and
} leave the rest alone (i.e. in /etc/default/rc.conf) then you might not
} have to do *anything* on an upgrade but reboot into multi-user mode!

     Yeah right!  When new options are being added, old options being
changed or deleted, and defaults changed, then I must at least examine
the /etc/default files.

} (It really does work in practice for patch releases, though often with

     With patch releases, if I do them at all, I usually don't bother
with the /etc set; since patch releases aren't supposed to change
functionality there is usually nothing of interest changed in the /etc
set.

} point releases there are likely to be so many new things that you'll at
} least want to check the new defaults and no doubt some variable names
} may even have been deprecated too, etc.)

     Correct.  So much for not having to do anything...

} > } Except that if you don't like what we have now, you can do this:
} > } 	cp /etc/default/rc.conf /etc/rc.conf
} > } and you're back to where we used to be, sans the rc.local.conf stuff
} > 
} >      I just may do that.
} 
} Don't do that!  It really is much much easier in the long run to only
} put changed values in /etc/rc.conf and leave *everything* else out.  Any
} modern full-screen text editor will easily allow you to simultaneously
} view two files and to copy selected bits of one file to the other.  Even
} without such modern conveniences the additional effort of first
} appending the entire default file to the primary one and then deleting
} all un-changed entries afterwards is really quite trivial.  I.e. do do
} this instead:
} 
} 	cat /etc/default/rc.conf >> /etc/rc.conf
} 	vi /etc/rc.conf
} 
} If you then insert a marker comment on all the lines you change it'll be
} really easy to delete all the lines you didn't change and you'll be left
} with the same result you'd get if you had only added the changed entries
} to the file in the first place.

     This sounds like a lot of work for no particular reason.  Given
that I will always need to at least examine the /etc/default files, I
may as well have all the info in a convenient place (i.e. in the /etc
files).  That way, it will be fairly easy to develop a tool to do a
three way merge between the old /etc/orig file, the new /etc/orig file,
and my changed /etc files.  After the automated merge is done, I will
simply have to quickly check the resulting new /etc files for any new
variables that I may want to changed.  This could also be helped by
flagging the new variables (the three way merge tool would preprocess
the /etc files to remove the NEW flag before using it).

} >  However, I recall a discussion about
} > rc_configured that indicated that it might not be that simple.  I'll
} > have to look into it.
} 
} You'll be obliterating the critical part of the default /etc/rc.conf if
} you clobber it with /etc/default/rc.conf -- append the latter instead.

      I did say that I would have to look at in detail...

} >      I think the suggestion I made of leaving the /etc files alone and
} > stashing a copy in /etc/orig would make adminstration easier and would
} > make the development of a merging tool easier.  Your current
} > /etc/default scheme would probably make the development of a merging
} > tool easier, but it does so at the cost of making administration
} > harder.  This is the wrong way to do things.
} 
} There's literally no real difference between your /etc/orig and the
} existing /etc/default (except that one could in theory make changes to

     Actually, there is a real difference.  I don't need to go through
extra unnecessary steps to see the stuff that I want to change, or to
find out the value of a variable at a later time (with /etc/default, I
would first have to look in the /etc file to see if I gave it a
non-default value, and if not, then look in the /etc/default file).
One thing that people being taught about databases are taught early on,
is that having the same information in multiple places without an
automated replication scheme is a recipe for disaster.  rc.conf could
conceptually be thought of as database that describes system startup.
You now have to look in two places to figure out how the system startup
is configured, instead of just one.  This is a very bad thing.

} /etc/default files and potentially cause the behaviour of the system to

     One could do this, but it would probably lead to major headaches.

} change -- I suppose sysinst could "chflags schg /etc/default/*" to
} prevent that from happening easily though).

     Where there's a will, there's a way...

} The /etc/default scheme does not make creation of a merge tool any
} easier at all in fact.  What it does is to make upgrades much easier
} *without* a merge tool.

     Not really, because I would still have to do a detailed comparison
between the old /etc/default files and the new /etc/default files, then
possibly make changes to the /etc files.  When doing that, it makes no
difference where the information is, except that if you increase the
number of files that I must process then I'm going to be very annoyed
(this is one of the things I really hate about SysV based systems).

} A merge tool is trivial to devise if it can assume that an original copy
} of the file has been squirrelled away for its future use at sysinst time
} (perhaps on a non-default branch in an RCS file) and thus allowing it to
} perform a standard 3-way merge (with diff3) when given a new copy and
} the localised copy.

     This is basically a rewording of what I've been saying all along.

} I.e. the /etc/default scheme is never the wrong way (and since it
} logically identical to the /etc/orig scheme you would prefer even you
} cannot make a logical argument against it), but it is not necessarily

     I can and I have.  What you may think of my argument is really not
my concern.

} In the specific case of a localised /etc/rc.conf that only modifies the
} values inherited from a master /etc/default/rc.conf there is perhaps
} some need for a tool that can verify that an upgrade does not change a
} configuration.  Such a tool is almost too trivial to write though since
} any experienced person should be able to invent it on the spot, but
} since it needs a few temporary files it might best be turned into a
} script:
} 
} 	: ${TMPDIR:=/var/tmp}
} 	( set > $TMPDIR/$$.base )
} 	( . /etc/rc.conf ; set | cat - $TMPDIR/$$.base | sort | uniq -u > $TMPDIR/$$.oldconf )
} 	mv /etc/default/rc.conf /etc/default/rc.conf-OLD
} 	mv /etc/default/rc.conf-NEW /etc/default/rc.conf
} 	( . /etc/rc.conf ; set | cat - $TMPDIR/$$.base | sort | uniq -u > $TMPDIR/$$.newconf )
} 	( . /etc/default/rc.conf-OLD ; set | cat - $TMPDIR/$$.base | sort | uniq -u > $TMPDIR/$$.olddef )
} 	( . /etc/default/rc.conf ; set | cat - $TMPDIR/$$.base | sort |	uniq -u  > $TMPDIR/$$.newdef )
} 	comm -13 $TMPDIR/$$.oldconf $TMPDIR/$$.newconf > $TMPDIR/$$.chgvar
} 	comm -13 $TMPDIR/$$.olddef $TMPDIR/$$.newdef > $TMPDIR/$$.newvar
} 	comm -23 $TMPDIR/$$.chgvar $TMPDIR/$$.newvar

     $$.oldconf and $$.newconf are exactly the same, so the first comm
is meaningless.  Although, I do see the gist of what you are trying to
accomplish.

} If I'm not mistaken (the above is not tested in any way and my set
} theory is a bit rusty it seems), the output should be just the default

     sh script programming has never been one of my strong points.  All
the common scripting languages are horribly convoluted (especially
PERL).  Anybody interested in standardising on REXX, or at least making
it a common scripting language (how can you tell that I worked on IBM
mainframes before doing UNIX)?

} configuration items changed by the upgrade and not already overridden by
} local settings, excluding any new items that would not have been
} mentioned in the old files.  In an upgrade the output should probably be
} empty in fact.  If you want to change the defaults in any of the new

     You may think that; however, default variables are changed between
point releases for various reasons (i.e. tightening up security,
enabling things that were previously experimental, etc.).

} configuration items then $TMPDIR/$$.newvar should be where you look for
} the list of such items.
} 
}-- End of excerpt from Greg A. Woods