Dimitri Puzin schrieb: >>> 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?
Here I mean a bunch of RFCs that are implemented by schemes that tells you how you could organise some infrastructural information in ldap -- like posix user data, mail addresses and others. It's up to you to use these schemes or you can leave them or you can extend them. However there are many applications and services that you can attach to ldap and they can use information from ldap more or less instantly. A better / weaker word may be conventions? >> 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. It depends... write an email alias to a user account. One may call this an addressbook. But you can easily configure MTAs out of the box to lookup this address during an SMTP session and to rewrite it to a local mailbox address. Depends on the exact meaning of "configuration storage", but I would call it like that. > LDAP primary aims at storage of more or less > heavily distributed data, organized into hierarchical tree structure. Think of heavily distributed, hierachical organisations. :-) > 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. YMMV; if you already have many apps that use SQL for configuration there is not point in using yet another database type like LDAP. > We concluded that SQL backend would be more useful > for bacula than LDAP. I think your and my focusses are different. I think of larger companies who want administration interfaces that integrate not just bacula, but also everything they have to administrate like users, proxies, printers, telephony, file servers, firewalls, routers, end user applications, whatever. All systems I know of that attempt to integrate as much as possible aspects into one place use LDAP. IMHO it is de facto industry standard in this matter. When I try to remind of what applications use SQL as configuration medium I do not find any app that is in fact integrated anywhere except of isle-solution (german expression?). (This is not a strong evidence, though.) > From developers point of view this will also keep > dependencies on other libs small. That's a point. Compile time options are our friends. >> 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 just tried to grab some examples. There are many. BTW also Microsoft uses LDAP in its proprietary reincarnation called Actice Directory. *ehem* ok, for most readers who read this list, this is an anti argument. But in this case I think they chose right... (well, this mircrosoft-argument has some usual restrictions...) > 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. ACK, this is a point against GOsa (et. al.?). But bear in mind that they implement a lot of functions that are not covered by any RFCs. What RFCs are there you could rely on when you implement SQL configuration storage for bacula? BTW it could be an idea to publish LDAP schemes for bacula as an RFC (maybe no). To do this with SQL schemes would sound strange to me ... > 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. It was just a silly example for an SPI provider. Might not be useful. :-) >> 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. But not limited to this, as you can see in the wild. >> 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. It's easier for developers to implement applications / plugins that integrate well into bigger scale administration frameworks which in turn is a good thing[tm] for end users. There is a big target group who need this sort of tools in order to use things like bacula. Also, developing just one all-in-one tool for every bacula purpose is not enough. There are many frameworks made by Red Had, SuSE, Collax, Univention, Gonicus insert-other-names-here that are key points for accessing new users who alltogether not at all want to edit one single config file. Integration is my key point here. > 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. My support. :-) /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
