12:26 a.m.
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. 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.
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.
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.
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.
On the command line, the only thing I ever wish for is a more compact input
format than LDIF.
That's just my personal reaction, based on my experiences with numerous
deployments; other folks' experience will probably differ.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/