I have a pair of mirror mode master servers that I would like to be able to provide cn=config replication to a series of slave servers, primarily, to keep ACLs in sync across servers.
I've tried syncrepl to the cn=config of the primary servers trying to exclude certain objects and attributes to prevent the slave from also taking the syncprov role. This did not seem to work well enough as I was unable to prevent some unwanted entry or another from making it's way through and overwriting the syncrepl line itself.
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?
Thanks, Chris
--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.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
On 4/15/11 9:59 AM, 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.
--Quanah
I was looking at that but it felt a little chicken and egg. I need a config in place that defines a rewrite rule that then provides the config? How would you lay this out?
Syncrepl the cn=config_slave database locally to a slave and then have a database relay setup to rwm-suffixmassage ontop of the cn=config namespace? Would that work?
Thanks, Chris
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc.
Zimbra :: the leader in open source messaging and collaboration
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)
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 +"
Something is still not quite right. In the logs I see a few troubling messages and the local cn=config doesn't update.
Apr 15 16:29:38 ramones slapd[1475]: conn=-1 op=0: config_add_internal: DN="cn=config" already exists and Apr 15 16:31:39 ramones slapd[1475]: send_ldap_result: err=67 matched="" text="Use modrdn to change the entry name"
is this because the cn entry for dn: cn=config_slave doesn't get rewritten from cn: config_slave to cn: config by the suffixmassage?
Thanks
Full logs from a replication attempt below.
Apr 15 16:29:38 ramones slapd[1475]: daemon: epoll: listen=8 active_threads=0 tvp=zero Apr 15 16:29:38 ramones slapd[1475]: daemon: epoll: listen=9 active_threads=0 tvp=zero Apr 15 16:29:38 ramones slapd[1475]: daemon: epoll: listen=10 active_threads=0 tvp=zero Apr 15 16:29:38 ramones slapd[1475]: =>do_syncrepl rid=001 Apr 15 16:29:38 ramones slapd[1475]: =>do_syncrep2 rid=001 Apr 15 16:29:38 ramones slapd[1475]: daemon: added 12r listener=(nil) Apr 15 16:29:38 ramones slapd[1475]: daemon: activity on 1 descriptor Apr 15 16:29:38 ramones slapd[1475]: daemon: activity on: Apr 15 16:29:38 ramones slapd[1475]: Apr 15 16:29:38 ramones slapd[1475]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Apr 15 16:29:38 ramones slapd[1475]: daemon: epoll: listen=9 active_threads=0 tvp=NULL Apr 15 16:29:38 ramones slapd[1475]: daemon: epoll: listen=10 active_threads=0 tvp=NULL Apr 15 16:29:38 ramones slapd[1475]: daemon: activity on 1 descriptor Apr 15 16:29:38 ramones slapd[1475]: daemon: activity on: Apr 15 16:29:38 ramones slapd[1475]: 12r Apr 15 16:29:38 ramones slapd[1475]: Apr 15 16:29:38 ramones slapd[1475]: daemon: read active on 12 Apr 15 16:29:38 ramones slapd[1475]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Apr 15 16:29:38 ramones slapd[1475]: daemon: epoll: listen=9 active_threads=0 tvp=NULL Apr 15 16:29:38 ramones slapd[1475]: daemon: epoll: listen=10 active_threads=0 tvp=NULL Apr 15 16:29:38 ramones slapd[1475]: connection_get(12) Apr 15 16:29:38 ramones slapd[1475]: connection_get(12): got connid=0 Apr 15 16:29:38 ramones slapd[1475]: =>do_syncrepl rid=001 Apr 15 16:29:38 ramones slapd[1475]: =>do_syncrep2 rid=001 Apr 15 16:29:38 ramones slapd[1475]: ==> rewrite_context_apply [depth=1] string='cn=config_slave' Apr 15 16:29:38 ramones slapd[1475]: ==> rewrite_rule_apply rule='(.*)cn=config_slave$' string='cn=config_slave' [1 pass(es)] Apr 15 16:29:38 ramones slapd[1475]: ==> rewrite_context_apply [depth=1] res={0,'cn=config'} Apr 15 16:29:38 ramones slapd[1475]: >>> dnPrettyNormal: <cn=config> Apr 15 16:29:38 ramones slapd[1475]: <<< dnPrettyNormal: <cn=config>, <cn=config> Apr 15 16:29:38 ramones slapd[1475]: ==> rewrite_context_apply [depth=1] string='cn=config_slave' Apr 15 16:29:38 ramones slapd[1475]: ==> rewrite_rule_apply rule='(.*)cn=config_slave$' string='cn=config_slave' [1 pass(es)] Apr 15 16:29:38 ramones slapd[1475]: ==> rewrite_context_apply [depth=1] res={0,'cn=config'} Apr 15 16:29:38 ramones slapd[1475]: ==> rewrite_context_apply [depth=1] string='cn=admin,cn=config' Apr 15 16:29:38 ramones slapd[1475]: ==> rewrite_rule_apply rule='(.*)cn=config_slave$' string='cn=admin,cn=config' [1 pass(es)] Apr 15 16:29:38 ramones slapd[1475]: ==> rewrite_context_apply [depth=1] res={0,'cn=admin,cn=config'} Apr 15 16:29:38 ramones slapd[1475]: ==> rewrite_context_apply [depth=1] string='cn=config_slave' Apr 15 16:29:38 ramones slapd[1475]: ==> rewrite_rule_apply rule='(.*)cn=config_slave$' string='cn=config_slave' [1 pass(es)] Apr 15 16:29:38 ramones slapd[1475]: ==> rewrite_context_apply [depth=1] res={0,'cn=config'} Apr 15 16:29:38 ramones slapd[1475]: ==> rewrite_context_apply [depth=1] string='cn=Subschema' Apr 15 16:29:38 ramones slapd[1475]: ==> rewrite_rule_apply rule='(.*)cn=config_slave$' string='cn=Subschema' [1 pass(es)] Apr 15 16:29:38 ramones slapd[1475]: ==> rewrite_context_apply [depth=1] res={0,'cn=Subschema'} Apr 15 16:29:38 ramones slapd[1475]: >>> dnPretty: <cn=config> Apr 15 16:29:38 ramones slapd[1475]: <<< dnPretty: <cn=config> Apr 15 16:29:38 ramones slapd[1475]: >>> dnNormalize: <cn=config> Apr 15 16:29:38 ramones slapd[1475]: <<< dnNormalize: <cn=config> Apr 15 16:29:38 ramones slapd[1475]: >>> dnPretty: <cn=admin,cn=config> Apr 15 16:29:38 ramones slapd[1475]: <<< dnPretty: <cn=admin,cn=config> Apr 15 16:29:38 ramones slapd[1475]: >>> dnNormalize: <cn=admin,cn=config> Apr 15 16:29:38 ramones slapd[1475]: <<< dnNormalize: <cn=admin,cn=config> Apr 15 16:29:38 ramones slapd[1475]: >>> dnPretty: <cn=config> Apr 15 16:29:38 ramones slapd[1475]: <<< dnPretty: <cn=config> Apr 15 16:29:38 ramones slapd[1475]: >>> dnNormalize: <cn=config> Apr 15 16:29:38 ramones slapd[1475]: <<< dnNormalize: <cn=config> Apr 15 16:29:38 ramones slapd[1475]: >>> dnPretty: <cn=Subschema> Apr 15 16:29:38 ramones slapd[1475]: <<< dnPretty: <cn=Subschema> Apr 15 16:29:38 ramones slapd[1475]: >>> dnNormalize: <cn=Subschema> Apr 15 16:29:38 ramones slapd[1475]: <<< dnNormalize: <cn=subschema> Apr 15 16:29:38 ramones slapd[1475]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Apr 15 16:29:38 ramones slapd[1475]: syncrepl_entry: rid=001 inserted UUID 9531bb2c-d970-102f-98bd-9352bfe36c1e Apr 15 16:29:38 ramones slapd[1475]: => access_allowed: search access to "cn=config" "entry" requested Apr 15 16:29:38 ramones slapd[1475]: <= root access granted Apr 15 16:29:38 ramones slapd[1475]: => access_allowed: search access granted by manage(=mwrscxd) Apr 15 16:29:38 ramones slapd[1475]: => test_filter Apr 15 16:29:38 ramones slapd[1475]: EQUALITY Apr 15 16:29:38 ramones slapd[1475]: => access_allowed: search access to "cn=config" "entryUUID" requested Apr 15 16:29:38 ramones slapd[1475]: <= root access granted Apr 15 16:29:38 ramones slapd[1475]: => access_allowed: search access granted by manage(=mwrscxd) Apr 15 16:29:38 ramones slapd[1475]: <= test_filter 5 Apr 15 16:29:38 ramones slapd[1475]: => test_filter Apr 15 16:29:38 ramones slapd[1475]: EQUALITY Apr 15 16:29:38 ramones slapd[1475]: => access_allowed: search access to "cn=module{0},cn=config" "entryUUID" requested Apr 15 16:29:38 ramones slapd[1475]: <= root access granted Apr 15 16:29:38 ramones slapd[1475]: => access_allowed: search access granted by manage(=mwrscxd) Apr 15 16:29:38 ramones slapd[1475]: <= test_filter 5 Apr 15 16:29:38 ramones slapd[1475]: => test_filter Apr 15 16:29:38 ramones slapd[1475]: EQUALITY Apr 15 16:29:38 ramones slapd[1475]: => access_allowed: search access to "cn=schema,cn=config" "entryUUID" requested Apr 15 16:29:38 ramones slapd[1475]: <= root access granted Apr 15 16:29:38 ramones slapd[1475]: => access_allowed: search access granted by manage(=mwrscxd) Apr 15 16:29:38 ramones slapd[1475]: <= test_filter 5 Apr 15 16:29:38 ramones slapd[1475]: => test_filter Apr 15 16:29:38 ramones slapd[1475]: EQUALITY Apr 15 16:29:38 ramones slapd[1475]: => access_allowed: search access to "olcBackend={0}hdb,cn=config" "entryUUID" requested Apr 15 16:29:38 ramones slapd[1475]: <= root access granted Apr 15 16:29:38 ramones slapd[1475]: => access_allowed: search access granted by manage(=mwrscxd) Apr 15 16:29:38 ramones slapd[1475]: <= test_filter 5 Apr 15 16:29:38 ramones slapd[1475]: => test_filter Apr 15 16:29:38 ramones slapd[1475]: EQUALITY Apr 15 16:29:38 ramones slapd[1475]: => access_allowed: search access to "olcDatabase={-1}frontend,cn=config" "entryUUID" requested Apr 15 16:29:38 ramones slapd[1475]: <= root access granted Apr 15 16:29:38 ramones slapd[1475]: => access_allowed: search access granted by manage(=mwrscxd) Apr 15 16:29:38 ramones slapd[1475]: <= test_filter 5 Apr 15 16:29:38 ramones slapd[1475]: => test_filter Apr 15 16:29:38 ramones slapd[1475]: EQUALITY Apr 15 16:29:38 ramones slapd[1475]: => access_allowed: search access to "olcDatabase={0}config,cn=config" "entryUUID" requested Apr 15 16:29:38 ramones slapd[1475]: <= root access granted Apr 15 16:29:38 ramones slapd[1475]: => access_allowed: search access granted by manage(=mwrscxd) Apr 15 16:29:38 ramones slapd[1475]: <= test_filter 5 Apr 15 16:29:38 ramones slapd[1475]: send_ldap_result: conn=-1 op=0 p=0 Apr 15 16:29:38 ramones slapd[1475]: send_ldap_result: err=0 matched="" text="" Apr 15 16:29:38 ramones slapd[1475]: syncrepl_entry: rid=001 be_search (0) Apr 15 16:29:38 ramones slapd[1475]: syncrepl_entry: rid=001 cn=config Apr 15 16:29:38 ramones slapd[1475]: => access_allowed: add access to "cn=config" "entry" requested Apr 15 16:29:38 ramones slapd[1475]: <= root access granted Apr 15 16:29:38 ramones slapd[1475]: => access_allowed: add access granted by manage(=mwrscxd) Apr 15 16:29:38 ramones slapd[1475]: <= acl_access_allowed: granted to database root Apr 15 16:29:38 ramones slapd[1475]: oc_check_required entry (cn=config), objectClass "olcGlobal" Apr 15 16:29:38 ramones slapd[1475]: oc_check_allowed type "objectClass" Apr 15 16:29:38 ramones slapd[1475]: oc_check_allowed type "cn" Apr 15 16:29:38 ramones slapd[1475]: oc_check_allowed type "olcArgsFile" Apr 15 16:29:38 ramones slapd[1475]: oc_check_allowed type "olcPidFile" Apr 15 16:29:38 ramones slapd[1475]: oc_check_allowed type "olcToolThreads" Apr 15 16:29:38 ramones slapd[1475]: oc_check_allowed type "olcTLSCACertificateFile" Apr 15 16:29:38 ramones slapd[1475]: oc_check_allowed type "olcTLSCertificateFile" Apr 15 16:29:38 ramones slapd[1475]: oc_check_allowed type "olcTLSCertificateKeyFile" Apr 15 16:29:38 ramones slapd[1475]: oc_check_allowed type "olcTLSVerifyClient" Apr 15 16:29:38 ramones slapd[1475]: oc_check_allowed type "structuralObjectClass" Apr 15 16:29:38 ramones slapd[1475]: oc_check_allowed type "entryUUID" Apr 15 16:29:38 ramones slapd[1475]: oc_check_allowed type "creatorsName" Apr 15 16:29:38 ramones slapd[1475]: oc_check_allowed type "createTimestamp" Apr 15 16:29:38 ramones slapd[1475]: oc_check_allowed type "olcLogLevel" Apr 15 16:29:38 ramones slapd[1475]: oc_check_allowed type "entryCSN" Apr 15 16:29:38 ramones slapd[1475]: oc_check_allowed type "modifiersName" Apr 15 16:29:38 ramones slapd[1475]: oc_check_allowed type "modifyTimestamp" Apr 15 16:29:38 ramones slapd[1475]: conn=-1 op=0: config_add_internal: DN="cn=config" already exists Apr 15 16:29:38 ramones slapd[1475]: send_ldap_result: conn=-1 op=0 p=0 Apr 15 16:29:38 ramones slapd[1475]: send_ldap_result: err=68 matched="" text="" Apr 15 16:29:38 ramones slapd[1475]: syncrepl_entry: rid=001 be_add cn=config (68) Apr 15 16:29:38 ramones slapd[1475]: => access_allowed: search access to "cn=config" "entry" requested Apr 15 16:29:38 ramones slapd[1475]: <= root access granted Apr 15 16:29:38 ramones slapd[1475]: => access_allowed: search access granted by manage(=mwrscxd) Apr 15 16:29:38 ramones slapd[1475]: => test_filter Apr 15 16:29:38 ramones slapd[1475]: PRESENT Apr 15 16:29:38 ramones slapd[1475]: => access_allowed: search access to "cn=config" "objectClass" requested Apr 15 16:29:38 ramones slapd[1475]: <= root access granted Apr 15 16:29:38 ramones slapd[1475]: => access_allowed: search access granted by manage(=mwrscxd) Apr 15 16:29:38 ramones slapd[1475]: <= test_filter 6 Apr 15 16:29:38 ramones slapd[1475]: send_ldap_result: conn=-1 op=0 p=0 Apr 15 16:29:38 ramones slapd[1475]: send_ldap_result: err=0 matched="" text="" Apr 15 16:29:38 ramones slapd[1475]: <= acl_access_allowed: granted to database root Apr 15 16:29:38 ramones slapd[1475]: send_ldap_result: conn=-1 op=0 p=0 Apr 15 16:29:38 ramones slapd[1475]: send_ldap_result: err=67 matched="" text="Use modrdn to change the entry name" Apr 15 16:29:38 ramones slapd[1475]: null_callback : error code 0x43 Apr 15 16:29:38 ramones slapd[1475]: syncrepl_entry: rid=001 be_modify cn=config (67) Apr 15 16:29:38 ramones slapd[1475]: syncrepl_entry: rid=001 be_modify failed (67) Apr 15 16:29:38 ramones slapd[1475]: connection_get(12) Apr 15 16:29:38 ramones slapd[1475]: connection_get(12): got connid=0 Apr 15 16:29:38 ramones slapd[1475]: daemon: removing 12 Apr 15 16:29:38 ramones slapd[1475]: do_syncrepl: rid=001 rc 67 retrying Apr 15 16:29:38 ramones slapd[1475]: daemon: activity on 1 descriptor Apr 15 16:29:38 ramones slapd[1475]: daemon: activity on: Apr 15 16:29:38 ramones slapd[1475]: Apr 15 16:29:38 ramones slapd[1475]: daemon: epoll: listen=8 active_threads=0 tvp=zero Apr 15 16:29:38 ramones slapd[1475]: daemon: epoll: listen=9 active_threads=0 tvp=zero Apr 15 16:29:38 ramones slapd[1475]: daemon: epoll: listen=10 active_threads=0 tvp=zero
--On Friday, April 15, 2011 4:53 PM -0700 Christopher Strider Cook ccook@pandora.com wrote:
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:
Have you looked at test059 which tests setting this up?
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
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.
Something is still not quite right. In the logs I see a few troubling messages and the local cn=config doesn't update.
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
Christopher Strider Cook wrote:
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.
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?
Use slapd -c. Read the slapd(8) manpage.
openldap-technical@openldap.org
-
Christopher Strider Cook -
Howard Chu -
Quanah Gibson-Mount