Re: managing OpenLDAP / back-config

On Dienstag, 15. Januar 2008, Howard Chu wrote: > Ralf Haferkamp wrote: >> With the great features that back-config provides to configure OpenLDAP >> servers at runtime it seems logical to start thinking about providing >> tools that could help to leverage those features. >> >> Currently to manage an OpenLDAP server through back-config you have the >> option to use either a generic LDAP Browser (JXplorer, Apache LDAP >> Studio, web2ldap), the OpenLDAP command line tools (ldapsearch, >> ldapmodify, ...) or homegrown software using one of the available LDAP >> APIs. I think it would be helpful to have some more sophisticated >> management tools (Commandline and/or GUI). >> >> In order to get there I think it could be helpful to create an API >> dedicated to provide an easy way to access the OpenLDAP configuration >> (databases, overlays, schema, access control, ...). This API could then >> be used to create different flavors of management tools. >> >> I have not yet spend too much time thinking about the design of such an >> API. Neither about the programming language that I'd use to implement >> something like this (Python, C, C++, ?). I first like to get a feeling >> how others think about this and if anybody is interested in collaborating >> on such an API. So please feel free to reply with your comments and >> suggestions :) > One thing I find to be extremely awkward about other directory server > products is the fact that they corral you into using their custom tools to > do administration. If they even have a generic admin interface it's poorly > documented and hidden in a corner somewhere. > > My point in implementing back-config is not only that it allows dynamic > changes, but that it can be operated using standard LDAP requests, > manipulated using generic tools, and requires no auxiliary programs to > support it. Yes, and I like it that way and I think any management tool should be completely optional and not changes this essential feature of back-config.

> As such, I don't see much benefit in designing custom APIs for > configuration. Specialized, task-oriented UIs sometimes make sense, but I > think if they use specialized APIs then something is wrong with the design. A utility library that has some knowledge about back-config could make the creation of such UIs probably bit easier. That would be my whole point for such a library.

> Tools that make certain commonplace tasks easier are certainly a good > thing. But when the tools get in the way, (e.g., FedoraDS where there are > even more bug reports about getting their admin server running than for > their actual directory server), the whole effort is just pointless. Heh, and that's of course not where I want to go. On the other hand we have quite some customers demanding for tools to manage OpenLDAP, that's why I came here to find ways to improve that situation in a way that others could benefit from it as well.

> In a lot of ways I think homegrown solutions are the only way to go. People > seem to believe that there are a ton of common operations that every site > needs to do, but in reality, every site has different deployment styles and > policies. They look the same from 10,000 feet, but at the detail level > they're nothing alike. > > That means you wind up needing a tool that is extensively configurable, to > present just the set of menus or tasks that you want to deploy. If this > tool is general-purpose enough, and can be customized enough to be focused > on the tasks of interest, it will inevitably be even more complicated to > configure than slapd itself. Yes, that's a good point. And something that we should of course avoid. > For the moment I think it would make most sense to take something like > Apache Directory Studio, which already has comprehensive capabilities and > configurability, and just provide some sample modules for it. Yes, that would probably worth a look as well. Though I have my issues with the huge framework in the back of Apache Directory Studio :). I probably have to come over that ;) > On the command line, the only thing I ever wish for is a more compact input > format than LDIF. Ok, that would throw XML out of the discussion :-). But seriously, do you think of something specialized on back-config? Or a generic approach that can replace LDIF? > That's just my personal reaction, based on my experiences with numerous > deployments; other folks' experience will probably differ.