[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: cn=config replication to consumer / slave servers

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:
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


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
add: olcUpdateRef
olcUpdateRef: ldaps://ldap.savagebeast.com

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,