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/
