Date: Sun, 19 Apr 1998 19:56:09 -0600 From: Wes Peters <softweyr@xmission.com> To: Karl Pielorz <kpielorz@tdx.co.uk> Cc: config@FreeBSD.ORG, terry@lambert.org Subject: Re: (was Discussion : Using DHCP) - Now 'Config Databases' Message-ID: <353AAB38.2C5021FF@xmission.com> References: <199804192202.PAA15594@usr08.primenet.com> <353A87D5.6F4A8737@tdx.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Karl Pielorz wrote:
>
> Terry Lambert wrote:
>
> > This was supposed to only go to config, like was suggested in the
> > message I replied to.
>
> True, I guess we get to see how many people are actually reading -config
> now... ;-)
There are still a few of us. ;^)
> > If you use an API with get/set semantics, and it does the set as a
> > transaction, then you are not liable to corruption unless your
> > physical media goes bad.
>
> Ok - granted - Maybe we should be more concerned with 'applications'
> corrupting the database - and if so have a nicer way to correct it (Ok, read
> - 'anyway' to correct it) unlike Windows '95 / NT - in which the registry is
> largely seen as an unindexed black whole...
>
> > If the physical media goes, it doesn't matter how it's implemented.
>
> True... Having revised my answer though - I'd still like to see a nice way
> of importing / exporting the data, and editing it (to patch it up when
> things go wrong with applications etc.)
>
> The last thing we want is the 'perpetually' growing mess that my NT machine
> has on it, called a 'registry' (The install is about 2 months old, and
> already the registry is up to just under 5mb - It usually 'lasts' about 6 -
> 8 months before all the 'weird' things start happening (CD players opening
> in too a small window etc.)
One thing that Mike Smith and I discussed last year was the idea of
being able to key modifications to the system configuration to packages.
This way, if you added a package and *it* changed the system configuration,
it could back out the changes on de-install, or back them out and reapply
new ones on upgrade.
While this is an admirable goal, when you think about it in detail it
becomes obvious that this is a very difficult job to do well. How to
handle changes that were made after your changes is a prime example of
problems that haven't been addressed that well. The simplest way to
address this, I feel, is to stick with text configuration files and
use RCS to control the revisions. You can do some mighty clever things
with tags, or with checkin comments, and RCS can do some mighty clever
tricks with versions of files. What RCS cannot do natively, a little
clever programming can work around, like a program that can take one
revision out of the middle of a line by backing up to the previous
revision and patching forward all the revisions *except* the one you're
trying to get rid of.
RCS also allows you to specify *why* you made a particular change, and
the package and port installation tools could be upgraded to consitently
comment on their actions in changing the configuration as well.
> > Clearly, you would need to take the same care in backing up a binary
> > file as you do in backing up a text file in case of physical failure.
>
> Granted - I just can't figure out why I always feel more 'secure' with text
> files (and a lot of other people appear to feel the same)...
Because the backups are so persistent, and so easy to implement. A text
configuration allows an old e-mail message with the contents, or even
a printout stuffed in your bottom desk drawer, to be a reliable backup
in case of catastrophic failure. This is rarely, if ever, true with a
binary file...
> I'm sure I'll get used to it - especially when it's done 'right'... <g>
...unless it's done right. Think of the 'vipw' model: your data is
stored in a binary file with whatever structure makes sense for the
data. *One* of the common access methods is to write a program that
can dump this structured binary data into a structured text file, and
read the information back from the structured text file. Then *one*
of your user interfaces can be as simple as implementing a script
program that locks the binary file, exports the data, runs the user's
preferred editor, and imports the data iff the user modified the file.
Sounds kinda familiar, doesn't it? ;^)
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
http://www.softweyr.com/~softweyr wes@softweyr.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-config" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?353AAB38.2C5021FF>