c.gatzemeier at tu-bs.de
Mon May 3 19:31:36 EEST 2004
Am Monday 03 May 2004 15:12 schrieb Dave Cridland [Home]:
> > 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,
Well there actally are many out there :) (SCNR)
> 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.
Ok, now I can see the case for the point you are making. Declaring one backend
as authoritative *globaly* in order to solve this comes with unfortunate
sideeffects though. What was thought about to solve this, and what might be
an alternative is to have meta-variables that are authororitative just within
the common config representation.
For example when apache, cups and samba all store some same setting lets say
"Servername" for a (bad) simplification here. For all apps their own value is
authoritative, but within a common representation their settings could be set
to a meta-variable, a common setting like "Servername" that is defined by
meta-configuration just as the others, but only used for cross reference
within the representation. The setting is stored in one (arbitrary) backend
and has only a authoritative meaning on and within the abstraction layer.
This makes it possible to change the "Servername" in the common API and
change different apps in one step if their meta-config is set so.
> 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
I wouldn't call it managed by I'd say it can be edited by it.
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.
If you like please try to rephrase this again, I am not really sure what you
where refering to here.
I have been thinking that Config4GNU was allways trying to make as less
assumptions or mandates as possible. There are those two alternatives though,
to install CFG on each host in a network (possibly accessible through a
network protocol frontend) or to let the backend interfaces access remote
databases/fetch files (ssh) with a network protocol itself.
> 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
Yes, apache or whatever shouldn't need to be aware of it. All "config file
managed by" approaches I know of couldn't hold true to allways guarantee that
though, and surely let to conflicts with other tools, that just claim the
same. Manual changes and fixes in configuration to solve a boot problem for
example get overwritten as soon as the "management" overtakes control of it
again. Administrator's carefully hand crafted scripts can't do its job
> 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 -
To handle those cases one would have to let the client pull its config (/etc
etc.) from a server.
[apps modifying other apps configs]
> 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.
Err, that is a different problem IMO not somthing that gets solved leaving
obstacles on purpose.
I agree that
> There's plenty of good reasons to store configuration externally from these
like backups config alternatives logs and diffs etc. but they should be
considered as authoritative. They can be made authoritative if saved,
possibly through the common api, at a place where the corresponding
application considers it to be authoratative. This can be a separate file or
a common backend if the app so desires in the future. If the user has those
rights of course.
> 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.
Ah, that might be a nice example, yes. I'd rather like to read this as -- only
when the administrator requests a change in the common (dynamic)
Just saying rather make the representatin dynamic than some backends.
More information about the xdg