Re: cn=config replication to consumer / slave servers

[Christopher Strider Cook <ccook@pandora.com>]

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