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

Re: cn=config

Not sure why you answered to -devel instead of -software, but...


--On Monday, February 20, 2006 3:03 PM -0700 Jon Roberts <jon@jonanddeb.net> 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 myself am not worried about it that much at all. I simply put in a SASL regexp that maps a particular kerberos principal to the cn=config backend. Thus my config backend is as secure as anything else I run.

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


I update my schema a few times a year, this would be really helpful.

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

Maybe, maybe not. I have 10 production, 4 test, 4 dev, and soon I will have an additional 3 UAT boxes. Having to stop and reload the servers across all these environments is tedious.

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


Backends, I probably wouldn't do often. Overlays I can see. There are overlays I'd like to set up now to do particular things I just haven't found the time to do yet.

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


Replication is something different from a slaves configuration... I think Howard addressed this well enough.

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? 

Usually less for production here. ;)  And right now I restart daily.

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


My post about helping out was not specific to cn=config. It was specific to OpenLDAP in general.

--Quanah

--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html