> <[EMAIL PROTECTED]> said: > > > [...] > >> > libconf doesn't store the config information elsewhere than where >> they are - in the config files. Libconf >> >> In the end, there must only be one copy of the configuration >> information (any other system with meta-configuration eventually has >> problems with diverging configurations). So, if you want the >> configuration stored in XML or LDAP, it means the application needs to >> be using that directly. > > sure, but libconf can be used to synchronise ldap and the config files.
IMHO this should be approached carefully, only config files that are known to be modified via LDAP should be done like this by default. Instead, those services which can be made to read from LDAP (bind has an ldap backend for example, which is not in the distro) where possible. > If everything were in ldap, libconf would be useless, and configuring a > linux system would be super easy :) > If you know LDAP ... and backend config formats is one thing libconf is supposed to make more transparent to the user. > actually we should code every new config tools in such way that it > read/write config infos from/to ldap, and libconf would synchronize > between ldap and the config files for the software that are not LDAP > aware (ie 80% of the softwares). > But then we would need a set of config tools for those using LDAP, and those not using LDAP (although it should really only be very small installations not using LDAP). If instead, libconf could handle LDAP also, a config tool would only need to support libconf, and would get LDAP (and XML etc etc) for free. For synchronisation, care should be taken where development on the original software is aiming at LDAP, to not have incompatible LDAP schemas .... >> >> For applications where configuration can be stored in LDAP (such as >> Postfix canonical maps etc), the backend should be capable of >> supporting this, but at present most systems capable of reading >> configuration from LDAP still require a config file to tell them where >> to find the LDAP server (among other things). This will change I >> think, as the use of DNS to locate services becomes more popular (ie >> Kerberos-style SRV records). > > if the backend is capable of that, no need to use libconf, because no > synchronization is needed. > So there are currently configuration frontends that are sufficient for all LDAP use? Instead, if libconf can write to LDAP also, >> >> > provides a mapping of these >> > information into a convenient perl structure. It is planed to have >> an xml output, and a ldap output. You would then be able to ask >> libconf to write an xml file from a standard config file. Or to feed >> a ldap base. >> >> I think the big thing is that the API for frontends needs to be >> defined, as perl structeres aren't that portable (for instance, >> consider a remote Windows front-end ...). > > sorry, I don't understand your point completely :/ At some stage, there may be applications that want to use libconf as a backend which are not written in perl ... I didn't see any documentation o this aspect ... Regars, Buchan
