On 4/15/11 5:03 PM, Howard Chu wrote:
Christopher Strider Cook wrote:
On 4/15/11 11:46 AM, Howard Chu wrote:
Quanah Gibson-Mount wrote:
--On Thursday, April 14, 2011 5:28 PM -0700 Christopher Strider Cook ccook@pandora.com wrote:
Alternately, I tried to setup a separate database cn=config_slave and have that snycrepl to the slave into cn=config... but that creates a naming missmatch.
Is there an approved practice to achieve this, or some other pointers on avenues to explore?
Use slapo-rwm to rewrite the cn=config_slave database to be cn=config on the replicas.
No, that never worked well. Use suffixmassage in the syncrepl config statement. (Added in 2.4.24)
Yes that looks like the right path.. I've just recompiled to gain this superpower... But:
So I've got a 'stub' cn=config setup with enough (I think) to get it booted and connecting to the master to syncrepl over the rest of the config. olcDatabase={0}config.ldif has I think a proper syncrepl line: olcSyncrepl: {0}rid=001 provider=ldaps://hostxxx.com bindmethod=simp le binddn="cn=admin,cn=config_slave" credentials=pass searchbase=" cn=config_slave" suffixmassage="cn=config" schemachecking=on type=refreshAndPersist retry="60 +"
Please read the test059 script in the test suite, it already does all the necessary steps in the correct order.
So, the pointer to test059 was exactly what this issue needed and following it has lead me to an very good working setup with one puzzling final step.
Following the steps laid out in test059 a consumer server gets setup with an initial cn=config using the following script: <code> #!/bin/bash slapadd -F /etc/ldap/slapd.d -n 0 <<EOF dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcPidFile: /var/run/slapd/slapd.pid olcTLSCACertificateFile: /etc/ssl/certs/Equifax_Secure_CA.pem olcTLSCertificateFile: /etc/ldap/ssl/server.pem olcTLSCertificateKeyFile: /etc/ldap/ssl/server.pem olcTLSVerifyClient: never
dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootPW: {SSHA}xxx
EOF
chown -R openldap:openldap /etc/ldap/slapd.d/ /etc/init.d/slapd start #/usr/sbin/slapd -h ldap:/// -g openldap -u openldap -F /etc/ldap/slapd.d
ldapadd -x -H ldap://`hostname -s`.savagebeast.com -D cn=config -w xxx <<EOF dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=ldaps://ldap.savagebeast.com binddn="cn=admin,cn=config" bindmethod=simple credentials=xxx searchbase="cn=config,cn=slave" type=refreshAndPersist retry="3 5 300 5" timeout=3 suffixmassage="cn=config" - add: olcUpdateRef olcUpdateRef: ldaps://ldap.savagebeast.com EOF </code>
This works fine and the remaining live config syncs over bringing the main database with it.
The problem I now face is that the initial cn=config entries used to do the first sync do not get overwritten by the data from the master. So the install password doesn't get replaced nor do the updated retry timeouts for olcSyncRepl, because, I'm assuming, the 'stub' entries have newer timestamps than those on the master.
How can this be overcome from the perspective of the slave server. Updating the entries on the master triggers the update as you would expect. Is there a way to put the stub entries onto the slave with a timestamp in the past so that they get overwritten during the first sync? Or is there another way to trigger them to be updated?
Thanks for your assistance, Chris