Date: Wed, 22 Apr 1998 01:31:00 -0600 (MDT) From: allen campbell <allenc@verinet.com> To: config@FreeBSD.ORG Subject: Re: Config Databases Message-ID: <199804220731.BAA13255@const.> In-Reply-To: <353B9520.CEDABF26@tdx.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
[ The order of the quoted paragraphs has been reversed ]
> I'm still not too sure I like the idea of 'binary' databases... One of the
> reasons I love unix at the moment is you can mostly pull it to bits with vi
> - I guess so long as we don't loose site of that (i.e. with good export /
> import stuff etc.) it should be OK...
I would like to share my thoughts on 'good export / import' here.
The possibility of a portal file system which would export the
various domains of the database as /etc/* files was mentioned.
Several people, including myself, thought this was an excellent
idea. At the same time, the ability to write to these pseudo-files
and cause database updates occur was also offered. I have since
formulated a few thoughts on this.
The most obvious advantage of using the portal file system to export
configuration data from the actual database is the transparency to
existing software. Few modifications to existing, configuration
dependent programs would be required to implement this. Another
not-so-obvious advantage is concurrency; when some piece of global
information changes, it should be reflected in all of the exported
files automatically. Here we gain much of the benefit of a central
configuration system with no modification to system software
(although clearly not as good as if all dependent programs could
automatically respond to dynamic changes.) So far, all of the
above is accomplished with a _Read-Only_ portal file system
('configfs' henceforth :) .)
Making this mechanism write-able is where things get complicated.
My own experience in applications development tells me that it is
far simpler to author a reporting application than a data entry
application. I think that difference is well demonstrated by the
difficulty posed in creating the parsers and data validation software
necessary to support every conceivable format found lurking in /etc
and then merging all of this into configfs, whereas only reading
the database to emulate the original file should be relatively
trivial.
There is another possibility which should be considered. The
current password database system could be generalized to support
nearly any configuration file. Currently we have several front-ends
to the password database which handle account administration very
smoothly. Chpass(1), passwd(1) and vipw(1) all allow you to
manipulate the password database indirectly, and then update 'binary'
databases via pwd_mkdb. For some time after I began using FreeBSD,
I was completely unaware this was taking place. I didn't find out
until I noticed that an entry made directly into /etc/passwd with
vi had no effect.
If this model (I'll call it the translation model) were generalized,
I see where we gain in four ways. First, configfs remains read-only.
This provides for the possibility that it may exist within our
lifetimes. :) Second, the data reflected by configfs could be
easily backed up (right out of /etc), with nothing more powerful
than a shell script, in 'non-binary' form to satisfy the ambient
level of paranoia. Third, assuming the translation software is
well implemented, it should be possible to merge in data sets which
are in canonical /etc form into the database. This provides for
easy initial conversion, mass updates and even recovery should the
worst happen to the binary database. Last, I haven't heard many
complaints about vipw as an administration tool; perhaps the same
acceptance would be gained with, say, vihosts or vigroup.
Granted, the total sum of work necessary to do this is arguably no
less than a writable configfs. The difference is that each
configuration file which requires this facility is implemented
discretely, and only if really necessary. With a write-able
configfs, it is pretty much all or nothing. I don't think many
would really miss the privilege of hand editing resolve.conf, shells
or host.conf, so why expect that the proverbial 'someone' should
have to implement these in a write-able configfs?
> So whatever we end up with has to be runnable in a
> pretty 'minimal' environment... ;-) - i.e. the back end of a 1.44Mb fixit
> disk... <g>
This is a tough requirement. The need to support extremely minimal
environments is significant, if for no other reason than that it
demonstrates a certain elegance to get a kernel with TCP/IP, PPP,
FTP and sysinstall onto a diskette. The discussion has orbited
around some sort of transaction engine (LDAP perhaps) and a session
manager to control the database. General purpose transaction
engines are prohibitively large.
My assumption has been that the expectation is to have clients of
system configuration data migrate to querying the database for
needed information. This assumes the database is up. Supporting
this on a 1.44Mb diskette sounds tough.
The easy way out is to identify the programs which are necessary
in a minimal environment and support continued /etc/* dependency
for this subset. In this case /etc would be real (as opposed to
configfs) on the floppy (or ram, or boot-rom, or...) and the system
would bootstrap and run without the database. The question is,
which stay in /etc and which evolve?
Another way would be to roll our own (read-only?) database library,
which, being implemented with smallness foremost in the mind of a
very talented developer, would be acceptable in a minimal environment.
The compromise is that it would have none of the expected benefits
of the real thing. As I think about it, this may be workable; as
long as the minimal subset of programs continues think its dealing
with the full-blown database and the data is static. The actual
data could be stored in a hand edit-able format for modification
too. Hmm.
Allen 'please forgive me' Campbell
allenc@verinet.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?199804220731.BAA13255>