[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: managing OpenLDAP / back-config



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.

Agreed.


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.




-- Kind Regards,

Gavin Henry.
Managing Director.

T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghenry@suretecsystems.com

Open Source. Open Solutions(tm).

http://www.suretecsystems.com/