spam at micropp.se
Mon May 3 18:38:40 EEST 2004
Dave Cridland [Home] wrote:
> On Mon May 3 10:40:52 2004, Lars Hallberg wrote:
>> 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.
Possably, Hovever, if the API is well designed this will all be
implementation details. We do not need to agree on this to agree on an
API, and the low level backends can be the same, ether they ar used
directly as datastore or to synk the config files with a central datastore.
> 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.
Don't think this need be *to* complikated. some central logic (can be in
a config demon, can be in a lib) maps path to backend and load the
needed backend on demand (when that namespace is querried), then talks
to that backend thru the same API, regardless what backend it is.
Some logic probably have to go in the backend - like figuring out hove
to merge user and system setings from different files/sorces. That
merging is defiend by the existing apps, and the config must use the
same roules - it can't define it's own! A good rekomendation for new
apps will make things easier - but everything will not instantly change
In the nastest case, the system and user setings is stored in diferent
file format (silly app that). But that backend can implement both
fileformats, or load a backend from the backend. Teoreticly the later
might open up for nasty loops, but in practis this is a prety hierarcial
Possably it is a good idé to have one bakend for the apps logic, that
loads a different low level backend for the actual file, ldap, ACAP or
whatever store. All the conections going thru the same API.
This might lead to an actual call will go thru a silly lots of layers of
the same API. But I think we need that kind of flexibilty to merge a lot
of config format and a lot of different applikatrion logic in one
> 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.
Over the top or not, the API should alowe this to be an implementation
>>> 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.
Yes, and the same low level backend should do the job in ether case!
> 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
> 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 :-)
>> 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.
Yes, the exersize was more for apps using the API to using it's own
configuration. Hopfully, most config tools will go thru som central
logic, in one way or another.
> 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.
Well, that the stuff is saved in the same file don't stop the backend
(or more probably some central logic in the config deamon) from handing
out more finegraind access controll to the users!
> 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.
> 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.
Some flush/rescan function should probably be in the API, so You can
tell Your config system to make sure the /etc/ file is up to date befor
You su and trhow Your favoprite texteditor at the config file. That
might be needed when You use the CVS version of Apache and midways in a
reconfiguration realize that som new featurs You need is not yet
avalible thru the nice GUI (of corce some simpel key-value pair regestry
like GUI might do the job to - provided an up to date cheme exist for
the new featurs).
More information about the xdg