Dimitri Puzin schrieb: >> 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.
If you don't mind I would postpone this. *ehem* :-) Basically it boils down to simplicity and performance for specific purposes (configuration management perfectly fits here). >> 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 :) I am pretty sure it would be the right choice. :) GOsa and other are interesting only because there are so many applications that implement an LDAP interface. So this is a network effect that becomes better when many people implement it. After all, that others do it actually is a good reason. At least it were not a false choice to do so. > 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. OK, bacula is a distributed app, but already concentrates its config in dir's config file. But there is still the inferface argument (for both LDAP/SQL): if there is a standardized(LDAP) networked(SQL/LDAP) interface, it is easily possible to create fancy admin tools (bat & co. could also benefit) or to integrate into general purpose admin tools like GOsa and others. For the distribution argument: If you are a user of GOsa or Univention Corporate Server (or others) you might have more than one physical location and thus more than one bacula installation. Here the hierachical structur and distributability of LDAP is very useful. Have a look for "departments" in GOsa. >> 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. LDAP for just one app is overkill. But admins in big sites who use LDAP consolidate many apps in this one backend and they would argument the other way around. What I've learned from experience is that RDBMS is for huge amounts of variable data and payload data (persitence of business objects[tm]) and that LDAP is for static infrastructure / environment data. To implement SPI providers is very easy, given that the infrastructure (API, SPI and the handling between both) is available. You could even easily abuse DNS for providing config information (I do not recommend). (*) I have no idea of how hard it would be to APIfy bacula's configuration management. BTW: didn't some Novell developers appear in this list who wanted to APIfy bacula? >> 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). Larger environments I know of either have LDAP or wish they had. But obviously it's a matter of details, evolution, taste, know how and others. After all this thread is a strong vote for APIs in general. Bacula's docs state that it were easy to configure. This is true compared to other open source network backup systems. But absolutely spoken it is far not easy, at least not for beginners, i.e. the learn curve is suboptimal. There is not much to do about it directly due to the complex nature of network backup. What I'd like to do is to implement or to see implemented a good, simple and more or less automated configuration and management application. IMHO the existent apps lack many features and maturity and these deficiencies correlate to the lack of APIs and to SQL beeing the only elegant way to visualize and manipulate bacula's operation. As stated some posts ago I am not a C hacker. My world is (java based) enterprise application stuff. If a customer asked me if I'd like to integrate bacula into a tomcat / geronimo / java system application server / ibm websphere as / php / something based management app I would say "no" until there are complete LDAP and SQL interfaces to all functions or at least SPI. By the way, bacula is a really neat piece of software -- despite of not yet beeing complete -- and I've had been glad if bacula at this stage existed seven years ago. Greetings, /HM (*) while writing that sentence I had to think of DNS srv records... ------------------------------------------------------------------------- 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
