Configuration API

[Dave Cridland [Home]]

On Mon May  3 10:40:52 2004, Lars Hallberg wrote:
> Dave Cridland [Home] wrote:
>> The alternative, as I've mentioned before, is to manage these systems 
>> externally, by having a shepherd process that handles the data and 
notifications from the common backend by rewriting configuration files and 
making those changes happen (by the almost-ubiquitous HUP, or restarting 
processes, as appropriate.).
> 
> Yes, that more of an implementation detail (large ditail I admit). Such 
> shepherd process can use the same API and backend plugins to scan and 
generate the diferent config files!
> 

It certainly makes sense to use Config4GNU to do that job, yes. Ideally, 
Config4GNU could be wrapped into the same API, yes, but it needn't be.

> 
> Other implementation can use the different backends direktly to keep the 
> 'old style' textfiles 100% actoriative all time!
> 
> Think the API must be avere of the need of activation on (the config tool 
> users) demand for apps not avare of notifikation.
> 

Again, this is dwelling on the concept that there are multiple backends, 
which operate a fixed portion of the namespace. I think that might get very 
complex, very fast.

The nastiest possibility is that a backend must be authoritative for two 
non-contiguous portions of the namespace, in which case things would be very 
complex.

I'd prefer to see all configuration managed by a single backend. Apart from 
anything else, forcing all Apache configuration to be managed by a Config4GNU 
style chunk of namespace precludes the possibility of using a network-based 
central management tool, largely, unless we create a protocol on top of the 
API to handle this - which, in my opinion, is getting well over the top, 
since people wishing to do this will be using a network protocol already to 
manage the config.

Bear in mind also that network-aware configuration management tools may well 
be operating directly on the network backend itself, by, for instance, 
directly operating on ACAP or LDAP servers.

> 
>>> If this API get som use, say Gnome and KDE, app authors might start 
>>> providing and updating ther backends, regarless if they use the backends 
themself for reading ther config - just to integrate nicly with the 'standar' 
config tools!
>> 
>> Potentially, yes. Or they may tacitly or overtly support other projects 
>> providing these, or they may tacitly or overtly support a shepherd process 
project.
> 
> Idealy, that would be the same thing!
> 

It should end up being the same result, yes.

Either way, I think we can safely suggest that any configuration management 
system with a consistent data model and API would allow for a holistic 
approach to configuration management.

> 
>>> The benefit from using the API in the app is that it becoms easy to 
>>> replase the config format or switch between lokal file store and network 
config deamons. When a set of solid implementations exists, it will probably 
be natural chose for *new* apps. But only apps needing som extra features 
like notification is likly to *change* to use the API. Stuff lika postfix, 
bind and apache is not likly to be first in line to cross over :-)
>> 
>> Or, indeed, ever convert at all. Bear in mind that it's pretty trivial to 
>> stuff all the data for postfix's maps into a configuration store, but 
equally, when I looked seriously at doing that, I realised it was easier and 
better to simply use existing hash files and rewrite them on notifications.
> 
> The nice thing is that they can integrate nicly without ever converting. As 
> You point out. Ther are strong reasons for some apps to rely on only on 
files in /etc/. But we still want those apps to be configurable thru our nice 
new GUI :-)
> 

Yes, absolutely. The point I'm trying to make is that Apache, for instance, 
need never know that its configuration is managed by a relatively complex 
configuration system which is unavailable before the network, or /usr, or 
whatever, is unavailable. Regardless of how the configuration is 
authoritatively stored, we can ensure that there are methods available for 
ensuring the /etc files are maintained with best-effort data at all times.

There are, of course, edge cases, such as when a machine's boot-time 
configuration is changed when that machine is offline - or simply off - but 
there will always be those. I can't see even the efforts of LR managing to 
reconfigure LILO without some form of shepherd process.

Oh, and I'd like to point out that 'shepherd process' is a very bad name, but 
the best I could come up with.

> A smale point here - if You chose to use the plugin for Apache config file 
> format directly, You will only gett access to Apache namespace, but thats 
good enuf for Apache :-)
> 
> I can see som use for a small lib that can load a few backends and present 
> them thru one instance of the API. That way a app neding to read (and 
possably alter) a few config files in different format can do that thru the 
API without the need to rely on any config deamon.

Hmmm. Yes, I see where you're coming from.

However, I'd suggest that that leads to applications which ignore the policy 
set by the site administrator.

There's plenty of good reasons to store configuration externally from these 
files anyway - for instance, it could allow people to reconfigure their own 
Apache virtual server *without* being able to reconfigure the whole of 
Apache, for instance, by use of ACLs.

There is one key time when an application needs to access two backends at the 
same time, of course - when the administrator requests a change in the 
primary backend used.

> 
> In the case of altering, it might lead to allot of stress for a shepherd 
> process. Some filelevel locking cheem might be needed :-/
> 

Yes, sort of.

It's pretty easy to ensure that only one such process is operating, in 
practise, even without having any locking, as such, at all - O_EXCL is pretty 
much all you need.

Obviously if people edit the files directly while they're being managed in 
this way, then all hell breaks loose, but the root user has such wonderful 
scope for letting all hell break loose anyway, it's not a big deal. Indeed, 
thanks to Config4GNU, you could even register that the modification time has 
changed, and re-read the configuration anyway, potentially, although that 
might lead to a race.

Dave.