MIT krb5 has an LDAP back end for its KDC, which uses its own schema. Currently, we distribute just a .schema file for OpenLDAP, which isn't very friendly to a DS using back-config and slapd.d. I have some questions about how we might do better.

1. For initial installs, I take it we should distribute a .ldif file which can be loaded with ldapadd. If we continue to use our .schema file as the master source file for the time being, then I assume we'll want to convert that to the .ldif file using slaptest. If we do that, should we remove the {n} prefix from the cn of the converted output, along with the metadata entries at the end, to match the style of the .ldif files in servers/slapd/schema?

2. If someone is upgrading to a version of krb5 which has new stuff added to the schema, how should we facilitate that upgrade? I don't think the .ldif file mentioned above would be of much use, since ldapadd will refuse to change an existing entry and ldapmodify wants to see change records.

One option is to distribute an LDIF file with a bunch of idempotent modify operations to upgrade the schema. Looking at RFC 2849, I'm not sure you can idempotently create an LDAP entry with LDIF (so this input file couldn't be used for initial installs), but perhaps it's a viable option to bring the olc* attributes on an existing schema entry up to date. Has anyone done something like this before, and is there a good way to generate such an ldapmodify input file from either a .schema file or its attrval-record .ldif equivalent?

Another option is to distribute delta LDIF files for each specific upgrade. That seems less friendly to OS packagers, who would then have to identify which upgrades to apply, but perhaps it's a better approach for reasons I don't know yet. If it is the best option, again, is there a good way to generate such delta LDIF files automatically?

Thanks for any advice, and apologies if I missed anything in the documentation or mailing list archives.