Quanah Gibson-Mount wrote:Here are the reasons I would like to use cn=config:
(a) The ability to modify ACL's on the fly, without restarting the server
This is the same reason I'm not quite so enthusiastic about cn=config, ie. it could allow a non-root entity to remotely compromise my security, configuration, or data. I'm not saying a system couldn't be configured to safeguard against this, but there are no guarantees with most slapd defaults. At the very least, I hope cn=config continues to be optional. Ditto for acis.
> (b) The ability to modify (add or MOD, not delete) the schema on the > fly, without restarting the server
That would be fun, but maybe just for schema spinners like me ;)
(c) The ability to add new indices on the fly, which will automatically trigger either updating or adding the new index, without restarting the server
That may be useful, but sometimes a CPU killer. Downtime may not be too awful by comparison.
(d) The ability to add new backends and overlays on the fly
I admit straight up I have no idea how valuable this would be. I can't see myself wanting it ever.
(e) The ability to store my replicas configuration (which differs from the masters) on the master as a secondary backend, and have changes to it replicated to all the replicas via (delta-)syncrepl to my replicas, so that I can just modify one location to push updates out to my 9 replica servers.
If I used replication, I would like this assuming it handled the necessary differences in configuration between a master and slave.
Personally I'd prefer to just ldapadd new object files into an exe branch and tell the old server to exec the new one. I.e., a back-fs backend that maps LDAP objects to filesystem objects. From a manageability standpoint, I think this where we need to go for large scale enterprise deployments. Probably not so important for small deployments.Those are just what come off the top of my head. Essentially, with cn=config, the only time I envision having to restart my servers are:
(a) Version upgrades
I'm not saying cn=config is a bad idea, because keeping configuration in the DIT is a common strategy among LDAP implementations I've seen. But since I'm not a professional C programmer, I don't have a lot of money, and I see this problem as pretty nontrivial it's easy for me personally to pass on the offer to help a brother (top ten private university) out :)
-- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/