Hello! You replied to me only, I assume by accident. Therefore I quote your mail to the list. This is ok, hopefully.
Dimitri Puzin schrieb: >> If not already requested anywhere, LDAP support would be a sexy feature >> (configuration, job definitions, etc.). > Hmm, to me, it would seem more meaningful to have the configuration of > bacula-dir purely in an SQL database, not relying on the definitions in > the config file. I've been already kind of thinking about that. If I > have enough free time i'd probably attempt to implement it... I am sure, > this would also ease the configuration of bacula with other frontends > currently under development. I don't see a clear advantage of using LDAP > for configuration of daemons over files/DB. IMHO the advantages are the following two: 1.) The L in LDAP stands for lighweight. Well, intentionally in contrast to DAP not SQL. But I think that compared to SQL it is lightweight enough so that you could restrict all configure options of all entities (fd, dir, sd, console, monitor, ...) to the credentials necessary to connect to the directory service and put everything else into the directory. Of course you could do all that with SQL, but LDAP is optimized for just this purpose. I could elaborate this point, if you wish. 2.) There are currently many attempts of distributors that aim to put as much as configuration data into LDAP and create management interfaces to LDAP. Collax and Univention heavily create and rely on on this infrastructure; but also RHEL and SLES partly do so and there are other solution providers like GONICUS' GOsa. I am also working on business solutions[tm] that use LDAP. My point is: LDAP is mainstream concerning distributed configuration. I am not a C hacker, I am more a java kiddie; I can't tell you how ldap libs for C look like. But I guess that fetching a hash table with all configuration data for the client can easily be written in two lines of code exluding exception handling given that you know your credentials that must reside in config file, of course. Naturally there might be environments where an SQL backend is more appropriate. What's about dividing the configuration retrieval to an API and an SPI? One SPI-provider for files, one for SQL, one for LDAP, ... :-) As stated above I am not a C hacker, but I have some knowlegde in LDAP and could provide LDAP schemes when needed. (Creating schemes for LDAP is the most nasty work on this, I think.) > Another thing I am currently thinking about is Kerberos/GSSAPI > authentication for daemons/users. That could possibly also solve the > problem with the current SSL implementation, which has been discussed > recently on bacula-devel. A world with all apps kerberized is one dream of admins, at least mine. :-) > Just my few ยข, as usual YMMV etc :) I vote for LDAP. :) > Regards, > Dimitri Puzin aka Tristan-777 /HM ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
