Date: Sat, 13 Dec 1997 19:25:20 +1030 From: Mike Smith <mike@smith.net.au> To: Terry Lambert <tlambert@primenet.com> Cc: damian@cablenet.net, jb@freebsd1.cimlogic.com.au, hackers@freebsd.org Subject: Distributed configuration management (was Re: Kernel Config datafile... ) Message-ID: <199712130855.TAA01918@word.smith.net.au> In-Reply-To: Your message of "Sat, 13 Dec 1997 08:47:23 -0000." <199712130847.BAA26476@usr08.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Damian, if you are not subscribed to -hackers, please forgive me for pulling you into this. Jordan forwarded your libdefaults/libconfig proposal and I have been thinking long and hard about the matter (it being one of considerable interest to me). I'd really like to hear your thoughts about taking your model one level further and using a distributed database (eg. LDAP or perhaps NDS if Novell are still being "free" with it) for the backend parameter store... > > > Really, LDAP is not mature enough at this point, except for embedded > > > systems where you can guarantee the behaviour of the back end, and > > > the back end is either not write-cached, or understands the > > > significance of container objects implicit by hierarchy. > > > > What you appear to be saying is that you cannot perform complex atomic > > transactions, nor are transactions guaranteed to be serialised. > > > > There, I did it in two lines. 8) > > You miss the subtleties, though. > > You *can* do it, you just can't do it with all backend's for LDAP, > nor can you do it without imposing overhead on the applications. If it can't be done universally, or isn't part of the protocol, I'd buy "it can't be done" as a fair generalisation. > You also left out that probably LDAP should have transactioning, > but that even without it it, it's a good mechanism for name value > pairs, better than FreeBSD flat file databases. Sure. At the moment we have no serialisation nor complex atomic transactions. > And FreeBSD should probably go to LDAP for all native databases after > taking the indicated precautions with the back end. If I read you correctly, this could be buried in a library of LDAP-using configuration functions. The other issue at that point becomes maintaining the "legacy" configuration files in order to avoid violation of POLA. mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712130855.TAA01918>