[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: EXIM, LDAP and some pop3 stuff?



On Sun, 13 Jan 2002, Donovan Baarda wrote:

[SNIP]
> Note that backwards compatability with existing config files has lead to the
> /etc directory changing roles. Once upon a time this dir contained files
> that admins edited directly. Increasingly, editing these files directly is
> becoming "not the right way to do it", with tools like adduser and
> update-<somethingoranother>, becoming the new admin interface. I don't know
> if these are helping much becase these tools themselves are not that
> consistant. The /etc directory is becoming like an add-hock config database
> with a mish-mash of storage formats and multiple inconsistant access API's.

True. The problem with a lot of unix configuration files is that they
were intended to only be *read* by the programs that use them, not
*written*. And that still shows in their format, which is generally much
easier to read than to update in an automated fashion.

Also, a difficulty with line-oriented ASCII files is that their records
have variable length, and updating such records is relatively hard. This
of course stems from the fact that Unix only offers files as streams,
not records - which is generally a good thing, IMHO, but it makes things
a bit cumbersome in this case.

The next problem is the general problem of different programs
communicating together. If the program or package to which a
configuration file belongs does not implement write support, and
changing a configuration is done by a different program, then the
configuration effectively file becomes a protocol. Sadly, most formats
were not exactly designed with the robustness of a real protocol in
mind.

Defining a standard presentation for configuration data, so that
readers and writers at least agree on syntax, is not a bad idea, I think.
Of course, as with a real protocol, it should be relatively easy to
write implementations. To *require* a particular library or API because
implementation is complex will cause it to become an evolutionary dead
end at some point.

I definitely don't think we should have a fragile, binary heap of
pointers - a filesystem-on-a-filesystem like the windows registry does
*not* seem to be a good idea. Lots of small real files are not the
fastest thing in the world on most Unix filesystems though, so it seems
we need some compromise until everybody starts using ReiserFS or
something like that. 

But again, I'd definitely object to having the whole configuration tree
in a single file. That would be wasting a perfectly good hierarchical DB
already offered by Unix - the filesystem. The modern cron.d / modutils /
ip-up.d etc. approach over single files shows how much write support can
already be made much easier by taking advantage of it.

Perhaps DBM or something similar, like djb's cdb format could be an
option. Using a separate file per 'table' lowers the risk of binary
files a bit, and the filesystem could be used to store these tables in a
nice hierarchical fashion. It's not that ideal perhaps, but IMHO better
than a windows registry, XML or even LDAP. The latter is a nice idea,
but I really think the configuration hierarchy should be reflected in
the unix filesystem, not hidden inside a database. I'd like to manage
data by simply copying it around, using tar, rsync, etc.

In any case, I really think that this problem should be approached as
designing a protocol: put the smarts in the data, not the code; make
it robust and extensible, and easy to implement support for - from
scratch if needed.

Cheers,


Emile.

--
E-Advies / Emile van Bergen   |   e-advies@evbergen.xs4all.nl
tel. +31 (0)70 3906153        |   http://www.xs4all.nl/~evbergen/



Reply to: