On Jan 6,  2:09am, Greg A. Woods wrote:
} [ On Wednesday, September 20, 2000 at 04:06:11 (-0700), John Nemeth wrote: ]
}
} >      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.
} 
} Don't bet on it....  Any given system might not depend on those changes
} at the time the upgrade is performed, but systems are dynamic living
} things and who's to say that a week later you might need exactly the fix
} that was in some /etc file from the upgrade?

     I read the changelog, which is generally pretty complete, so if
there was something that I needed, I would most likely catch it, and
could deal with it, assuming I hadn't already.

} > } 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...
} 
} It's one thing to read through the various critical files, diff them,
} etc., and quite another to have to re-configure everything from scratch!

     rc.conf isn't that big of a file, and given how often I do it, its
not a big deal.  However, I could just merge changes if needed.

} >      This sounds like a lot of work for no particular reason.
} 
} The effort is necessary in order to get to the first step in the process
} of making things easier down the road.  This little bit of effort up
} front is what saves enormous complications and contortions later on.  If
} you don't believe in preparing ahead of time to make your life easier
} down the road then obviously this won't make sense, but if I can forsee

     I do, but only if I believe I will benefit down the road,
especially since it can sometimes be difficult to find the time to do
the upfront work.

} >  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).
} 
} The trick is in reducing the amount of information that you have to
} manage from being *everything* to being just those items that make your
} system unique from the distribution.

     This isn't feasible.  I work with too many operating systems, not
to mention versions of operating systems.  I have to know exactly
what's going on on a given system, not just how it differs from a
default install.  NetBSD is far better then most systems for this, but
not quite perfect.

} Meanwhile the trick employed by NetBSD with rc.conf (or in the past by
} rc.conf.local) is immediately and instantly usable by any human to
} understand what's been done to configure a particular system.

     As a general rule, I'm more interested in how a given system is
currently configured then in how its configuration has changed.

} > } 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.
} 
} What I meant was that fundamentally the result is exactly the same.  Two
} systems configured with each method will behave identically.
} 
} The differences are not operational but rather in the techniques used to
} manage them.

     We're not talking about operational status, but rather how to
manage them, so this is a moot point.

} >  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.
} 
} Your /etc/orig scheme, or use of a version control tool (eg. RCS), is
} also replicating the same information.  The only difference is that such
} schemes don't make live use of the replicated information.  In fact the

     Yes, which means it doesn't matter what one does with the
replicated information, it won't cause operational problems.  However,
messing with it would cause problems come upgrade time, so it's best
just to leave it alone.  If fact, if an automated upgrade tool were
created, then you should be able to totally ignore it.

} In fact automating the replication is what makes it *safer*!  The use of
} RCS is by and far the best way to replicate this information of course
} since it makes it impossible to accidentally change the original version
} thus ensuring that the correct delta can always be calculated at any
} time in the future.

     Where there's a will, there's a way...  Although, you're right
that RCS would make it considerably more difficult.  However, I'm not
sure that RCS wouldn't be overkill for this application.

} The advantage of the /etc/default scheme is that you can swap original
} /etc/default files around underneath the delta file (under controlled
} upgrade procedures of course) and not necessarily have to do anything
} else to retain the uniqueness of the system instance.

     Yes, you would.  Not checking out the changes to the defaults
would be extremely sloppy.

} Certainly there are changes that can be introduced by the change of
} system defaults, but those changes won't always have a negative effect
} on the way a given instance of a system fulfills its requirements.  Say
} for example that SSH becomes a built-in tool and perhaps the system
} didn't have an add-on SSH on it already, so in that case the
} introduction of a new daemon is probably a very positive and beneficial
} change in the default behaviour of the system.

     On the other hand, if I had sshd started from rc.local and
suddenly rc.conf decided that it wanted to start sshd then there would
be a problem.  If rc.conf decided to do so with different keys or a
different configuration file, then there could be a big problem.

} In any case simple deductive logic proves my point.  Without an
} /etc/default style of system it's impossible to just upgrade and go
} because the upgraded /etc/rc.conf file must always be re-edited to
} re-introduce local configuration changes.  Therefor one must conclude

     There are a lot more files in /etc then just rc.conf.  I always do
a recursive diff of the entire /etc directory.  This means that adding
a few lines to rc.conf is in the noise of the overall process.

} that with at least the possibility of being able to upgrade and go
} without having to reconfigure anything must in fact make the

     I have never seen this case in practice.  One could also say that
I have a possibility of winning the lottery, assuming I was actually
silly enough to buy lottery tickets.

} None of this stuff matters a whole lot if you've got only one system to
} manage through a series of upgrades.  However if you've got dozens of
} such systems, each with unique configurations, this particular 

     Off the top of my head, I have 12 NetBSD systems to do, plus a
variety of other OSes just to make my life difficult.  I can see the
need to know just the changes from the defualt; however, in dealing
with them, I would also need to take into account, the changed
defaults.

} Yes, a merge tool is eventually necessary for all the other kinds of
} configuration files in /etc anyway, so we still need one in the long

     Exactly, see my point above about /etc having a lot more files
then just rc.conf.

} > } 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.
} 
} Ah, no, $$.oldconf and $$.newconf are not necessarily the same, and
} that's the key to understanding what's going on!  You say as much

     Okay, I see what's happening.  Although the lines for creating
$$.oldconf and $$.newconf are exactly the same, you're changing
/etc/default/rc.conf between them, and since that is sourced by
/etc/rc.conf it means that these lines will have different outputs.
This means that you're depending on a hidden side effect.  A very nasty
thing to do.  Obviously, a production version of this script would need
to be heavily commented.

} > } 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)?
} 
} Any language that can easily manipulate lists of things and do set
} operations on them would achieve the same result once given the lists of
} "variable=value" pairs.  I'd have written my example in lisp if I were
} just wanting to get the job done since that's the language I first
} learned to apply set theory with, but since there's perhaps some desire
} to do this with just the tools that would be available on a plain unix
} system, and given the audience in this forum, I chose to use them and
} they are more than adequate for the task.

     I'd take it in lisp, even though I haven't played with lisp in
quite some time.  Just if there were more hours in the day, so I had
more time to play with "esoteric" languages, such as lisp, forth,
postscript, etc.  Of course, there are so many things I want to do, the
day would pratically have to be infinite.

}-- End of excerpt from Greg A. Woods
ng about operational status, but rather how to
manage them, so this is a moot point.

} >  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.
} 
} Your /etc/orig scheme, or use of a version control tool (eg. RCS), is
} also replicating the same information.  The only difference is that such
} schemes don't make live use of the replicated information.  In fact the

     Yes, which means it doesn't matter what one does with the
replicated information, it won't cause operational problems.  However,
messing with it would cause problems come upgrade time, so it's best
just to leave it alone.  If fact, if an automated upgrade tool were
created, then you should be able to totally ignore it.

} In fact automating the replication is what makes it *safer*!  The use of
} RCS is by and far the best way to replicate this information of course
} since it makes it impossible to accidentally change the original version
} thus ensuring that the correct delta can always be calculated at any
} time in the future.

     Where there's a will, there's a way...  Although, you're right
that RCS would make it considerably more difficult.  However, I'm not
sure that RCS wouldn't be overkill for this application.

} The advantage of the /etc/default scheme is that you can swap original
} /etc/default files around underneath the delta file (under controlled
} upgrade procedures of course) and not necessarily have to do anything
} else to retain the uniqueness of the system instance.

     Yes, you would.  Not checking out the changes to the defaults
would be extremely sloppy.

} Certainly there are changes that can be introduced by the change of
} system defaults, but those changes won't always have a negative effect
} on the way a given instance of a system fulfills its requirements.  Say
} for example that SSH becomes a built-in tool and perhaps the system
} didn't have an add-on SSH on it already, so in that case the
} introduction of a new daemon is probably a very positive and beneficial
} change in the default behaviour of the system.

     On the other hand, if I had sshd started from rc.local and
suddenly rc.conf decided that it wanted to start sshd then there would
be a problem.  If rc.conf decided to do so with different keys or a
different configuration file, then there could be a big problem.

} In any case simple deductive logic proves my point.  Without an
} /etc/default style of system it's impossible to just upgrade and go
} because the upgraded /etc/rc.conf file must always be re-edited to
} re-introduce local configuration changes.  Therefor one must conclude

     There are a lot more files in /etc then just rc.conf.  I always do
a recursive diff of the entire /etc directory.  This means that adding
a few lines to rc.conf is in the noise of the overall process.

} that with at least the possibility of being able to upgrade and go
} without having to reconfigure anything must in fact make the

     I have never seen this case in practice.  One could also say that
I have a possibility of winning the lottery, assuming I was actually
silly enough to buy lottery tickets.

} None of this stuff matters a whole lot if you've got only one system to
} manage through a series of upgrades.  However if you've got dozens of
} such systems, each with unique configurations, this particular 

     Off the top of my head, I have 12 NetBSD systems to do, plus a
variety of other OSes just to make my life difficult.  I can see the
need to know just the changes from the defualt; however, in dealing
with them, I would also need to take into account, the changed
defaults.

} Yes, a merge tool is eventually necessary for all the other kinds of
} configuration files in /etc anyway, so we still need one in the long

     Exactly, see my point above about /etc having a lot more files
then just rc.conf.

} > } 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.
} 
} Ah, no, $$.oldconf and $$.newconf are not necessarily the same, and
} that's the key to understanding what's going on!  You say as much

     Okay, I see what's happening.  Although the lines for creating
$$.oldconf and $$.newconf are exactly the same, you're changing
/etc/default/rc.conf between them, and since that is sourced by
/etc/rc.conf it means that these lines will have different outputs.
This means that you're depending on a hidden side effect.  A very nasty
thing to do.  Obviously, a production version of this script would need
to be heavily commented.

} > } 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)?
} 
} Any language that can easily manipulate lists of things and do set
} operations on them would achieve the same result once given the lists of
} "variable=value" pairs.  I'd have written my example in lisp if I were
} just wanting to get the job done since that's the language I first
} learned to apply set theory with, but since there's perhaps some desire
} to do this with just the tools that would be available on a plain unix
} system, and given the audience in this forum, I chose to use them and
} they are more than adequate for the task.

     I'd take it in lisp, even though I haven't played with lisp in
quite some time.  Just if there were more hours in the day, so I had
more time to play with "esoteric" languages, such as lisp, forth,
postscript, etc.  Of course, there are so many things I want to do, the
day would pratically have to be infinite.

}-- End of excerpt from Greg A. Woods