On Mon, Jul 13, 2015 at 01:21:00PM -0400, Greg Hudson wrote: > but our historical practice has been to extend the schema with new > optional attributes. I'm not sure what the upgrade story would be like > if we created a new schema each time we needed to add a new attribute.
As a user of kerberos with the ldap backend, please don't do that :). You can modify the schema in-place when using the cn=config backend, here's an old thread about it: http://www.openldap.org/lists/openldap-technical/201408/msg00036.html I guess if you wanted to make life easier for cn=config users you could ship a complete ldif schema with everything and then a differential ldif schema updating from the last full release to the current, each release including the new and any past differentials. Then they'd have to verify what they loaded last and then use the right update ldif. Despite the almost religious fervor about cn=config on the openldap mailing list, I can't stand it. I maintain our ldap config in revision control and it's automatically deployed to the running servers as changes are made and pushed through dev/test to prod. cn=config just doesn't support that workflow, and the response to any criticism is usually something along the lines of "you don't manage your servers right, here's how you can bend over backwards and touch your ankle with your elbow to sort of force our paradigm to do what you want" <sigh>. Fortunately the plaintext config, which was originally intended to go away with the release of 2.5, evidentally now isn't. So I can keep on using it :). So as long as you release the classic schema files I'll be happy ;). ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos