[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
cn=config
- To: Quanah Gibson-Mount <quanah@stanford.edu>
- Subject: cn=config
- From: Jon Roberts <jon@jonanddeb.net>
- Date: Mon, 20 Feb 2006 15:03:56 -0700
- Cc: openldap-devel@OpenLDAP.org
- In-reply-to: <6EE519676CBA777D20020125@cadabra-sw.stanford.edu>
- References: <20060217114605.I70830@mippet.ci.com.au> <9B9B63B0A26DEF3A8EBA72EB@cadabra-sw.stanford.edu> <43F560BE.9090506@symas.com> <6A02B3B7B2CC6C15EA2B098D@cadabra-sw.stanford.edu> <b0459d5c0602191851n74b31fe1x12c74e30a6c4c2e7@mail.gmail.com> <6EE519676CBA777D20020125@cadabra-sw.stanford.edu>
- User-agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720)
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.
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
That could be at least monthly, right?
(b) Deleting schema elements
That would likely be never, I'd think.
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 :)
Jon Roberts
www.mentata.com