Ralf Haferkamp wrote:
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.
Ralf, at first one would have to define what "manage OpenLDAP" really
means, by defining the use-cases needed. I'd distinguish the use-cases
1. Configuration (network config, backends, indexing, ACLs, etc.)
2. Directory user and group management related to access control
3. Maintaining the content retrieved by client applications.
For 1. I usually ask my customers how they are going to implement the
change management. After some discussion we usually end up with
text-based config managed with version control. Something simple and
Configuration changes in production are most times not that dynamic.
Rather they are subject of a long-lasting change process. Tweaking text
files is not the issue during this process.
Dynamic reconfiguration if really needed for certain deployment
situations (e.g. change of master/slave role) are implemented by
home-grown scripts which must be thoroughly tested.
Use cases in category 2. are much simpler than 1. If the number of
changes is low and the change process itself is rather simple the
existing tools cover this situation quite well. If specific workflows
have to be followed there is not a single tool which covers all the
variants you can find even within one company. ;-)
Again a home-grown tool has to be implemented for more complex cases.
3. is most times done by home-grown tools or by syncing mass data from
So like Howard I don't see much need for developing something like this.
I rather see the need to teach the customers. ;-) Also bear in mind that
an API might get very complex e.g. in case of tweaking things with
Regarding customization of configuration tools I can also confirm that
most people are asking for powerful customization features but then
nobody bothers to read the docs to really customize a admin UI.