> 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> >> <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/<http://www.openldap.org/project/> >
