Re: new sysinstall

[Richard Coleman <richardcoleman@xxxxxxxxxxxxxx>]

G065363@xxxxxxxxxxxxxxxxxxxx> <20030901144956.GA8023@xxxxxxxxxxxxxxxxx> <200309011613.h81GDt0C099442@xxxxxxxxxxxxxxxxxxxx> <3f53d0f9$0$267$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <200309020145.h821jIjk003543@xxxxxxxxxxxxxxxxxxxx>
In-Reply-To: <200309020145.h821jIjk003543@xxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 58
Message-ID: <3f5400d5$0$268$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
NNTP-Posting-Host: 24.98.233.138
X-Trace: 1062469846 crater_reader.dragonflybsd.org 268 24.98.233.138
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:844

Matthew Dillon wrote:

> What I would like to do is temporarily move people away from the
> language discussion and get people to start talking about how to
> integrate an installer / configurator with RCNG and how to record and
> manage non-RCNG related files.
> 
> There are some fairly obvious ways we can integrate with RCNG, e.g.
> simply by maintaining our own /etc/config/rc.conf file and perhaps
> adding some # md5's in comments to detect manual changes (I hate it
> when as a sysop I make a change to a file then run a configurator
> which rips out and reverts my changes, don't you?).
> 
> But what about things like /etc/resolv.conf?  /etc/group, 
> /etc/master.passwd, etc?  I can kinda see emplacing #md5 checksums in
>  comments for the sections modified by the configurator to detect 
> manual changes, but the real question is how the configurator should 
> track the myrid pieces of information installed in these files by 
> disparate applications.
> 
> The goal should be to be able to go into the configurator and add a 
> package, have it modify all the files as necessary, and to then be
> able to go into the configurator, remove that package, and have it
> properly undo all the changes (as long as it determines the changes
> weren't manually modified by a third party outside the configurator).

The only thing I can think of is to keep a file containing a list of md5 
hashes associated with each "data element" that the configurator can 
change.  Each line of this file would represent a single element by a 
"token" which represents the file in which it is contained, along with 
the particular element.  For instance

rc.conf-gateway		md5value
rc.conf-hostname	md5value
rc.conf-firewall_enable	md5value
resolv.conf-nameserver	md5value
resolv.conf-domain	md5value
group-wheel		md5value
group-user		md5value
passwd-root		md5value
passwd-nobody		md5value

This could be kept in a db database if necessary.  A couple small C 
programs could be written to add/delete entries.  Then the RCNG scripts 
could use these small programs to install/delete/etc.

I'm not sure how to handle data elements that may exist multiple times 
(nameserver entry in resolv.conf).  A brute force solution is for the 
md5sum to always represent the hash of the concatenation of all the data 
values associated with a single key value.

Unfortunately, this doesn't handle the situation where I've "manually" 
set an element to a value which just happens to be the same as the default.

Richard Coleman
richardcoleman@xxxxxxxxxxxxxx