On Donnerstag, 17. Januar 2008, Pierangelo Masarati wrote:
Ralf Haferkamp wrote:
Yes, I guess that this works pretty well when you deploy OpenLDAP (or basically any other software) at a single customer. It gets harder when you ship OpenLDAP as a part of a product,
I already imagined what your aim is. ;-)
Of course my aim is somewhat focused on what I am getting paid for, whose isn't? :)
we routinely feel similar needs.
But additionally to that I was trying to find out if there is a general interest among the OpenLDAP Developers to have some kind of management tools/api. If there were, we could have started something that would serve both interests. I am trying to avoid a solution just specific to our products.
My main concern is that from an api to a management tool there is a big difference. It might be difficult to draw the line, if any line can be drawn at all. In terms of usefulness and demand, I'd concur with you. In terms of viable solution, perhaps you (we) should be more specific, try to propose something that looks like a plan, and see how everyone's needs fit in it.
The API that I had in mind would have some knowledge how back-config is structured and have functions to read specific parts of the configuration (e.g. a single database or overlay) into datastructures. Additionally it would provide functions to access those structures. A simple example: In order to create a new index on a database you'd call something like this:
db = olcConfig.getDatabase("<suffix>"); db.addIndex("<attribute>", SLAP_INDEX_EQ); db.commit();
Providing this kind of detailed API for every possible slapd parameter would probably be an overkill and too much to implement, even if one would chose as similar table based approach as inside slapd. It should probably only done for the most important settings (which are of course hard to define). The rest of the attributes should probably be handled by more generic getter/setter-functions.
As for usecases, that Michael asked for in his last mail, I have the e.g. following in mind:
- add a simple database - manage ACLs and indexes on that database - configure some overlays on that database (e.g. ppolicy, refint, memberof) - setup replication - manage the schema (not a complete schema editor to define new objectclasses and attribute types, but the possibility to add existing definitions to the server) - or as something completely different, but also requested some times: setup a caching proxy server.