Quanah Gibson-Mount wrote:
a) You could set up an accesslog database that stores the changes made to cn=config over time. If you had to have it in git, it shouldn't be particularly difficult to write a tool to parse those changes out into some format you desire
This has two caveats:1. Your change is logged *after* applying it. But think of staging where you want to tag tested changes to proceed to the next stage. Sure there will be a even more complex method by stacking more components on top. But it's not a solution to make things more complex.
2. This adds another hen-and-egg problem. Since there already are serious operational hen-and-egg problems with cn=config this rather contributes to operational issues instead of solving them.
b) Since cn=config is simply a tree, you could have your cn=config in git, commit your changes there, and use a tool like ldapdiff to create changesets to apply programatically.
So instead of writing a single file (in one FS transaction) after letting slaptest check it I have to write several files (multiple FS operations), diff that and then apply multiple LDAP operations.
Yeah, sounds really great regarding error handling.This pretty much shows the lack of understanding for what people bring up here. There might have been things gone wrong and slapd etc. does not work anymore. But instead of calling the people morons not capable of dealing with LDAP there should be a simple fix for reaching out of the dead end. Correcting a broken slapd.conf is a simple way out.
Ciao, Michael.P.S.: The day slapd.conf option is dropped from slapd I should start writing my own LDAP server. ;-)
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature