Re: managing OpenLDAP / back-config

[Ralf Haferkamp <rhafer@suse.de>]

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.

-- 
Ralf