Ralf Haferkamp wrote:
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.
Just some kind of wrapper lib. I guess it's up to whatever language you
use and write something for your own use. I thinking like the CPAN etc.
Depends what UI you want to write.
> 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.
This question always gets asked by customers ;-) The answer is they are
free to chose.
Whenever anything gets mentioned, like Howard says, each rolls their own...
> 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.
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
Open Source. Open Solutions(tm).