[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: cn=config

Jon Roberts wrote:
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.

I agree, the potential as an attack vector is huge, which is another reason I've been reluctant to allow normal users to have access to it. Right now the fact that only the cn=config rootDN can touch it makes the risk exposure a lot easier to contain. I've gotten a couple requests to open things up and make it observe regular ACLs; I find the prospect of allowing arbitrary users access to the config tree quite unsettling. Any mistake there could be pretty devastating.

On the flip side, I think it's important to be able to refine ACLs on regular databases without interrupting service, which is why ACL editing is supported.


> (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 ;)

Over the run life of a server I'm sure it will be a tiny fraction. Adds are supported now because that should be the most common of these rare events (e.g., installing a new app that comes with its own schema).

(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.

If your cache settings are adequate, it shouldn't have any negative impact. Since we take care to only lock one entry at a time, the probability that the indexing task will make any other operation wait is pretty low.

(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.

It's debatable, yes. My personal experience is from needing to add connectors to hundreds or thousands of subordinate servers on the fly, but in that case we stored the connection information in a regular database. (Conceptually using a hybrid of back-hdb and back-ldap.) Adding new local databases is a pretty uncommon occurrence.

(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.

Yes, which is why Quanah refers to a secondary backend, to isolate the slave details from the master.
Of course, if you want all your servers to be identical, then a coarse-grained multimaster replication would suit the situation.

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

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.


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 :)

Most of the features Quanah listed are already working. It's just adding support for the remaining backends and overlays that is tripping him up, and that's really not an engineering exercise any more, just rote-level rewriting. Replication of slave configs still needs to be worked out. As Kurt mentioned in the past, replication may not be the best way of looking at that problem.

--
 -- 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/