Dave Cridland [Home]
dave at cridland.net
Mon May 3 16:12:42 EEST 2004
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
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'
>> Potentially, yes. Or they may tacitly or overtly support other projects
>> providing these, or they may tacitly or overtly support a shepherd process
> 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.
More information about the xdg