The ability to do manual disaster-recovery/emergency config changes is crucial. But you also have to understand that going this route is for *emergencies* - it is not the way to go for routine administrative tasks.

One item I've always wondered about the RTC design -- with all the other details being tracked, where's the checksum of the entry?

And recognizing that emergencies *do* happen, and having a Plan of Action is key to responding to emergencies correctly, what *is* the proper way to manually edit cn=config?  Particularly in a replicated RTC setup?  
I figure it's something like

- shut off slapd
- edit the ldif. 
   - remove | edit one or more of the operational attributes
 - turn on slapd

One
rough edge not so obviously logged is the server (as of 2.4.25) needs a
restart after adding an (hdb) database object/branch.

That is certainly not true, as test050 does this and much more.

Oddly, I followed the test050 procedure in creating my bootstraps
and based from that did expect it to work.
 
More accurately, under my particular build of 2.4.25 (based off the RH rpm spec file from 2.x)
under Centos5.6 using the -r chroot environment, with db-5.1.19. I found it necessary to restart
slapd in order for the database to be properly opened and available for
ldapadds.

--Chan

 

Replication has its own
pointy edges as well along with TLS; I've spent hours chasing obscure TLS
issues due to O/S dependent behaviors.

Regarding schemas -- it's a straightforward perl 1-liner to translate from
.schema to .ldif format.  Then import and edit via ldapmodify as needed.

Hope this helps,

--Chan


   I've seen the guides similar to this one here:
   http://blogger.ziesemer.com/__2011/01/ldap-authentication-__for-samba.html
   <http://blogger.ziesemer.com/2011/01/ldap-authentication-for-samba.html>
   which suggest hacking together a temporary slapd.conf file containing just
   the include directives, run slaptest, and then hack the output so that it
   can be loaded into cn=config using ldapadd.

   Given that this is a quite a common task, is there no way of generating
   the LDIF directly to be loaded into the directory, e.g.

   slaptest -s /etc/ldap/schema/myschema.__schema [ -n <schemanum> ] -l
   myschema.ldif

   Or then again, is this functionality already there but I just haven't
   managed to find it yet? I'd be grateful if someone could point me in the
   right direction and/or give me some hints as to the best way to manage
   schemas in the new regime.


   Many thanks,

   Mark.

   --
   Mark Cave-Ayland - Senior Technical Architect
   PostgreSQL - PostGIS
   Sirius Corporation plc - control through freedom
   http://www.siriusit.co.uk
   t: +44 870 608 0063 <tel:%2B44%20870%20608%200063>


   Sirius Labs: http://www.siriusit.co.uk/labs




--
 -- Howard Chu
 CTO, Symas Corp.           http://www.symas.com
 Director, Highland Sun     http://highlandsun.com/hyc/
 Chief Architect, OpenLDAP  http://www.openldap.org/project/