Hans Manz schrieb: > Hello! Hi, > You replied to me only, I assume by accident. Therefore I quote your > mail to the list. This is ok, hopefully. Oops, that wasn't my intention. Thanks.
> 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. Please. > 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 think we shouldn't do something just because others do it. It might be not the right choice. Yes, I've seen GOsa :) IMHO is the configuration not as much distributed as LDAP was designed for/to pull real benefit from it. The most important configuration is the one from bacula-dir and there is usually only one instance of it running on the network. Another moreless single thing is the sd config. The console and fd isn't that complex and most of my fd instances are running just with a single copy of the same file. > 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. Not too complex, but let's talk about that later. > 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, ... :-) That sounds like quite good idea to me. I'd prefer SQL backend, especially small to medium sized installs could benefit from it (and I maintain a lot of them ;) Another advantage is, the admin doesn't need to maintain another service like LDAP just for the backup system. Further, bacula already keeps a part of the config in SQL database (if you edit dir conf, you might need to update some ressources from bconsole, to reflect changes, some other times have to issue reload). > 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. :-) Yeah :D [...] > I vote for LDAP. :) For the environments I am concerned of is SQL probably the better choice. OTOH LDAP could also be nice. It could be deployed easily when the environment is new (fresh new install etc in a smaller network), but in larger environments it's quite complicated if not impossible to integrate (not only technically, but also concerning the policy of customer, for example). Regards, Dimitri Puzin aka Tristan-777
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- 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
