[Date Prev][Date Next]
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.