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.htmlhttp://blogger.ziesemer.com/__2011/01/ldap-authentication-__for-samba.html <http://blogger.ziesemer.com/**2011/01/ldap-authentication-** for-samba.htmlhttp://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/http://www.openldap.org/project/