Date: Mon, 18 May 1998 09:22:16 -0700 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Dan Janowski <danj@3skel.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: system config database... Message-ID: <27848.895508536@time.cdrom.com> In-Reply-To: Your message of "Mon, 18 May 1998 00:42:42 EDT." <Pine.BSF.3.96.980518002504.5978B-100000@fnur.3skel.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> I've been putting brain power into
> the issue of a configuration system for /etc.
> I have done something along this path with
> M4 for a similar purpose.
>
> Is M4 too weird to use for something of this
> scope?
No, I don't think so, though it's also pretty damn cryptic and I'd
hope that any future standard for /etc would emphasise both
flexibility AND ease of use since the average skill level of the Unix
population is only steadily declining. M4 is powerful, few would
deny that, but it's also cryptic as hell.
If I had my druthers, there would be a single text file in /etc which
stored all the configuration data for system startup. People wouldn't
(generally) be expected to edit it directly but rather use one or more
browsing tools for displaying and editing each "startup object" in a
friendlier form, that perhaps looking something like this:
name: amd
desc: The Auto Mount Daemon for NFS filesystems.
enabled: no
class: net
order: 9
requires: is_enabled nfs_client && is_enabled network
v_exec: amd
v_flags: -a /net -c 1800 -k i386 -d ${domain} -l syslog /host /etc/amd.map
command: ${v_exec} ${v_flags}
The attribute names are somewhat contrived, but basically you want
each startup entity to be something which describes itself (thus
eliminating the grotty in-line comments in /etc/rc.conf) and gives you
sufficient hints about when to invoke it in the startup sequence (the
class and order attrs). Everything which is ``enabled'' and matches
its requirements check, something which could just be a line of sh(1)
using a bunch of handy provided shell functions like ``is_enabled'' to
prevent its becoming rapidly unreadable, gets its "command" executed.
Attributes like v_foo would be just temporary variables used to make
changing things easier and could be skipped in the interests of more
concise entries.
Somewhere, of course, you'd have a global object which defined
attributes of its own for controlling the overall ordering of classes,
e.g. "fs swap serial net cleanup quotas user", and so on. Browsers
could inspect this object for hints on how and where to display the
rest of the objects and also perhaps store their metadata here.
Needless to say, I also see such a system _replacing_ the current one
and available as an option, just as upgrading one's /etc mechanisms
has essentially always been. I've seen 2.1 systems using their old
/etc dirs after being upgraded to 3.0 no problems - as long as it's
still self-consistent and nobody tried to upgrade just half of it or
something, it works. That means that the purists can choose whichever
suits them and I suppose that we could even make the choice an
installation option.
Unless you want to play some very clever and bizarre tricks with an
"etcfs" using portals or some such, going for full backwards
compatability is going to be nothing more than an impediment to doing
this. It's technically possible, sure, but also annoying enough that
it's more likely that you'd simply punt the project before making it
do all the good things that a new startup configuration mechanism
should do and be also fully backwards compatible with all the old
files.
- Jordan
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?27848.895508536>