Hi
current version of openldap 2.4.23-7.2 I have however built and used 2.4.31 with the same results.
I have a single provider that has multiple domians
ie dc=company dc=subdivision1,dc=company dc=subdivision2,dc=company
on some of the consumers, I have a single syncrepl config with the base, so these servers have all the users and replication tends to work fine.
olcSyncrepl: {0} rid=00x provider=ldaps://x.x.x.x bindmethod=simple binddn="cn=replica,dc=repl_config,dc=company" credentials="xxxxx" filter="(objectclass=*)" searchbase="dc=company" scope=sub attrs="*,+" schemachecking=off type=refreshAndPersist retry="5 5 300 +" starttls=yes tls_reqcert=never tls_cert=/etc/ldap/ssl/ca-cert.pem tls_key=/etc/ldap/ssl/keys/ca-key.pem
on some of the consumers, I have multiple syncrepl configs so that I replicate specific subdivision data to those servers.
olcSyncrepl: {0} rid=001 provider=ldaps://x.x.x.x bindmethod=simple binddn="cn=replica,dc=repl_config,dc=company" credentials="xxxxx" filter="(objectclass=*)" searchbase="dc=company" scope=base attrs="*,+" schemachecking=off type=refreshAndPersist retry="5 5 300 +" starttls=yes tls_reqcert=never tls_cert=/etc/ldap/ssl/ca-cert.pem tls_key=/etc/ldap/ssl/keys/ca-key.pem
olcSyncrepl: {1} rid=002 provider=ldaps://x.x.x.x bindmethod=simple binddn="cn=replica,dc=repl_config,dc=company" credentials="xxxxx" filter="(objectclass=*)" searchbase="dc=repl_config,dc=company" scope=base attrs="*,+" schemachecking=off type=refreshAndPersist retry="5 5 300 +" starttls=yes tls_reqcert=never tls_cert=/etc/ldap/ssl/ca-cert.pem tls_key=/etc/ldap/ssl/keys/ca-key.pem
olcSyncrepl: {2} rid=002 provider=ldaps://x.x.x.x bindmethod=simple binddn="cn=replica,dc=repl_config,dc=company" credentials="xxxxx" filter="(objectclass=*)" searchbase="dc=subdivision,dc=company" scope=base attrs="*,+" schemachecking=off type=refreshAndPersist retry="5 5 300 +" starttls=yes tls_reqcert=never tls_cert=/etc/ldap/ssl/ca-cert.pem tls_key=/etc/ldap/ssl/keys/ca-key.pem
whats happening with these consumers is that the initial sync seems to work and some changes to the provider do make it down to the consumer but lately most changes are NOT making it down to the consumer, when I log sync then I am seeing that the csn is committed for the change for the first rid but then for the next rid it logs that the csn is too old?
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=080 LDAP_RES_INTERMEDIATE - NEW_COOKIE Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=080 NEW_COOKIE: rid=080,csn=20120822075659.107448Z#000000#000#000000 Aug 22 09:56:59 fw1 slapd[30938]: slap_queue_csn: queing 0xb4230120 20120822075659.107448Z#000000#000#000000 Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=082 LDAP_RES_INTERMEDIATE - NEW_COOKIE Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=082 NEW_COOKIE: rid=082,csn=20120822075659.107448Z#000000#000#000000 Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=081 LDAP_RES_INTERMEDIATE - NEW_COOKIE Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=081 NEW_COOKIE: rid=081,csn=20120822075659.107448Z#000000#000#000000 Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=083 cookie=rid=083,csn=20120822075659.107448Z#000000#000#000000 Aug 22 09:56:59 fw1 slapd[30938]: slap_graduate_commit_csn: removing 0xb422e830 20120822075659.107448Z#000000#000#000000 Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=082 LDAP_RES_INTERMEDIATE - NEW_COOKIE Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=083 CSN too old, ignoring 20120822075659.107448Z#000000#000#000000 Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=082 NEW_COOKIE: rid=082,csn=20120822075659.112753Z#000000#000#000000 Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=081 LDAP_RES_INTERMEDIATE - NEW_COOKIE Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=081 NEW_COOKIE: rid=081,csn=20120822075659.112753Z#000000#000#000000 Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=080 LDAP_RES_INTERMEDIATE - NEW_COOKIE Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=080 NEW_COOKIE: rid=080,csn=20120822075659.112753Z#000000#000#000000 Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=083 cookie=rid=083,csn=20120822075659.112753Z#000000#000#000000 Aug 22 09:56:59 fw1 slapd[30938]: slap_queue_csn: queing 0xb4f11d20 20120822075659.112753Z#000000#000#000000 Aug 22 09:56:59 fw1 slapd[30938]: slap_graduate_commit_csn: removing 0xb4f18508 20120822075659.112753Z#000000#000#000000 Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=083 CSN too old, ignoring 20120822075659.112753Z#000000#000#000000
Mark Coetser wrote:
Hi
current version of openldap 2.4.23-7.2 I have however built and used 2.4.31 with the same results.
I have a single provider that has multiple domians
ie dc=company dc=subdivision1,dc=company dc=subdivision2,dc=company
on some of the consumers, I have a single syncrepl config with the base, so these servers have all the users and replication tends to work fine.
olcSyncrepl: {0} rid=00x provider=ldaps://x.x.x.x bindmethod=simple binddn="cn=replica,dc=repl_config,dc=company" credentials="xxxxx" filter="(objectclass=*)" searchbase="dc=company" scope=sub attrs="*,+" schemachecking=off type=refreshAndPersist retry="5 5 300 +" starttls=yes tls_reqcert=never tls_cert=/etc/ldap/ssl/ca-cert.pem tls_key=/etc/ldap/ssl/keys/ca-key.pem
on some of the consumers, I have multiple syncrepl configs so that I replicate specific subdivision data to those servers.
That is not supported. You can only use multiple consumers in the same database if they are all pointing at different providers (and each of those providers uses a unique serverID).
whats happening with these consumers is that the initial sync seems to work and some changes to the provider do make it down to the consumer but lately most changes are NOT making it down to the consumer, when I log sync then I am seeing that the csn is committed for the change for the first rid but then for the next rid it logs that the csn is too old?
On 22/08/2012 10:39, Howard Chu wrote:
Mark Coetser wrote:
on some of the consumers, I have multiple syncrepl configs so that I replicate specific subdivision data to those servers.
That is not supported. You can only use multiple consumers in the same database if they are all pointing at different providers (and each of those providers uses a unique serverID).
Can I split them into separate databases on the consumer? Or whats the correct way of doing what I am trying to achieve?
On Wed, 22 Aug 2012, Mark Coetser wrote:
On 22/08/2012 10:39, Howard Chu wrote:
Mark Coetser wrote:
on some of the consumers, I have multiple syncrepl configs so that I replicate specific subdivision data to those servers.
That is not supported. You can only use multiple consumers in the same database if they are all pointing at different providers (and each of those providers uses a unique serverID).
Can I split them into separate databases on the consumer? Or whats the correct way of doing what I am trying to achieve?
I believe you could do this with a single syncrepl consumer with a searchfilter that tests against entryDN. (|(entryDN:dnSubtreeMatch:=dc=repl_config,dc=company) (entryDN:dnSubtreeMatch:=dc=subdivision,dc=company))
...though if it's at all a possibility of happening at your site, I would specifically test the results of moving an entry into or out of a matched subtree.
Philip Guenther
On 22/08/2012 18:34, Philip Guenther wrote:
On Wed, 22 Aug 2012, Mark Coetser wrote:
On 22/08/2012 10:39, Howard Chu wrote:
Mark Coetser wrote:
on some of the consumers, I have multiple syncrepl configs so that I replicate specific subdivision data to those servers.
That is not supported. You can only use multiple consumers in the same database if they are all pointing at different providers (and each of those providers uses a unique serverID).
Can I split them into separate databases on the consumer? Or whats the correct way of doing what I am trying to achieve?
I believe you could do this with a single syncrepl consumer with a searchfilter that tests against entryDN. (|(entryDN:dnSubtreeMatch:=dc=repl_config,dc=company) (entryDN:dnSubtreeMatch:=dc=subdivision,dc=company))
...though if it's at all a possibility of happening at your site, I would specifically test the results of moving an entry into or out of a matched subtree.
Philip Guenther
Thanks for the help, I do prefer the acl solution on the server though that way I have more control from central place as to what is delivered to the consumer. I am however having trouble wrapping my head around the acls
openldap-technical@openldap.org
-
Howard Chu -
Mark Coetser -
Philip Guenther