Purpose of the kerberos.ldif file
Paul B. Henson
henson at acm.org
Sat Jul 18 23:01:45 EDT 2015
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 ;).
More information about the Kerberos
mailing list