On Dienstag, 15. Januar 2008, Hallvard B Furuseth wrote: > Howard Chu writes: > > 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. > > (...) > > 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. > > Indeed. For most of my tasks, my editor is the best API I've got. > Or it would be if the task allowed it. Yes. But on the other hand you are a very experienced OpenLDAP user :)
> One main difference is tasks I don't know very well, when a specialized > API can know it better than I do. Assuming it's correct, of course:-) > Similarly, a good config API would be useful when one first sets up > OpenLDAP. > > > (...) On the command line, the only thing I ever wish for is a more > > compact input format than LDIF. > > ITS#5312 - ldapmodify defaults:-) > > Seriously, some suggestions to simplify that: > > We can include a program which dumps out a subset of cn=config, lets you > edit it, generates a diff from the original, shows the changes, and > applies it. That at least gets rid the add:/delete:/replace: LDIF > verbosity. Hm, have you heard of ldapvi? I think that does exactly what you are describing above: http://www.lichteblau.com/ldapvi/ > It'd be nice if if it prettified the ldif a bit first, e.g. chose good > places for line breaks in access statements. But I guess that needs a > way for the server to tell the client how to format attributes, so it's > a lot more work. > > (I'd like even more if something could generate slapd.conf-format and > convert back to ldif, but that would have to be a slap tool or some > magic LDAP request which gets a lot of help from slapd. I can't think > of a reasonably simple way to do the latter.) > > As I think I've mentioned before, it'd help make things less verbose if > back-config did not create attributes with defaulted values, or marked > such defaults with an attribute option. > > Assertion controls in the generated LDIF, to check that the config entry > being updated indeed matches the entry we read from cn=config and > edited. > > This requires support for assertion controls in back-ldif/back-config, > and some attribute for the assertion to test. Maybe an automatically > maintained md5sum(contents of entry) attribute. From an implicitly > included overlay, I guess. (Lacking that, it could at least check > modifyTimeStamp.) > > > For similar reasons it'd help to have EQUALITY matching rules on all > cn=config attributes. When we write by hand an LDIF to feed ldapmodify, > we can then write delete: <old value> / add: <new value>. That adds a > extra check for what we are changing. > > I suggested once to give config entries more informative names than > things like olcDatabase={0}<backend> too, more like > oldDatabaseName=(something derived from suffix, if possible). That'd > also make it easier to see what one is doing, and ensure it is done to > the right entry. assert(olcSuffix=...) helps when editing the database > entry, but can't be used on its subordinates. -- Ralf
