The ability to do manual disaster-recovery/emergency config changes
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
rough edge not so obviously logged is the server (as of 2.4.25) needs
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
> 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,
>> I've seen the guides
similar to this one here:
which suggest hacking together a temporary slapd.conf file containing
>> the include directives, run slaptest, and then hack the output so that
>> 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
>> 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
>> right direction and/or give me some hints as to the best way to manage
>> schemas in the new regime.
>> Many thanks,
>> Mark Cave-Ayland - Senior Technical Architect
>> PostgreSQL - PostGIS
>> Sirius Corporation plc - control through freedom
>> 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