Hans Manz schrieb: > 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). I've discussed that point here with my colleagues and customers. See below.
>>> 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, What do you mean by standardized? > 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. Today I've briefly communicated with my colleagues and some customers about your idea (adding ldap backend support for configuration). However at least we here agree that LDAP wasn't meant to be used as a configuration storage. LDAP primary aims at storage of more or less heavily distributed data, organized into hierarchical tree structure. While it is possible to put almost anything into LDAP storage, many apps won't benefit. We couldn't make a point where a tree/hierarchy/distribution across systems would fit into current configuration layout. We concluded that SQL backend would be more useful for bacula than LDAP. From developers point of view this will also keep dependencies on other libs small. > > 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. Yes that's true. However, see the arguments above. It just fits there where it is for GOsa. I dislike however the heavily customized schema of GOsa and other similar products. Here, we prefer to go as close and as generic as possible with the current RFCs. >>> 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). (*) The implementation of DNS SRV RRs aims at automatic discovery of services in a network domain. Here it fits well. Probably not for distribution of configuration for services. > 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. Yes. Naturally they would store user/group and account information there (probably other things as well). It makes sense. > 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. You are right about the API thing. However I can't see how an API would help to improve the learning/experience with configuration/usage of bacula for end users/admins. The API would clearly make things easier for developers, not for users. [...] > 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. Yeah, long time ago I've switched from commercial products to bacula and many of my customers are pretty satisified with it now. There is still space for improvements however :) Here, a big thanks to Kern and all other developers of bacula. Regards, Dimtiri Puzin aka Tristan-777 > (*) while writing that sentence I had to think of DNS srv records... >
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
