Hi!
I have a glued DIT on a syncProvider:
-----snip from slapd.conf------ database meta subordinate suffix proxy,ou=foo
database bdb subordinate suffix humans,ou=foo
database bdb subordinate suffix system,ou=foo
database bdb suffix ou=foo
overlay glue overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 -----snap from slapd.conf------
This should be replicated to a consumer:
syncrepl rid=401 provider=ldap://provider type=refreshAndPersist retry="60 10 300 10 3600 10" searchbase="ou=humans,ou=foo" bindmethod=simple binddn="cn=human,ou=mgr,ou=foo" credentials=nothing updateref ldap://provider
This does not work. Nothing is replicated.
When I slapcat everthing, define one, global database und slapadd all in - so I don't have a glued DIT at the provider anymore, it works.
Is the above configuration not working or did I a configuration error?
Hans
On Tuesday, 19 June 2007, Hans Moser wrote:
Hi!
I have a glued DIT on a syncProvider:
-----snip from slapd.conf------ database meta subordinate suffix proxy,ou=foo
database bdb subordinate suffix humans,ou=foo
overlay syncprov
database bdb subordinate suffix system,ou=foo
database bdb suffix ou=foo
overlay glue overlay syncprov
You probably want to remove the syncprov overlay here.
syncprov-checkpoint 100 10 syncprov-sessionlog 100 -----snap from slapd.conf------
This should be replicated to a consumer:
syncrepl rid=401 provider=ldap://provider type=refreshAndPersist retry="60 10 300 10 3600 10" searchbase="ou=humans,ou=foo" bindmethod=simple binddn="cn=human,ou=mgr,ou=foo" credentials=nothing updateref ldap://provider
This does not work. Nothing is replicated.
When I slapcat everthing, define one, global database und slapadd all in
- so I don't have a glued DIT at the provider anymore, it works.
Is the above configuration not working or did I a configuration error?
In 2.3, you can only syncrepl at the searchbase that contains a database with a syncprov overlay.
Also, you should not sync-repl a glued database, rather sync-repl the subordinates individually, and glue them back together on the consumer.
Regards, Buchan
Buchan Milne schrieb:
I have a glued DIT on a syncProvider: database bdb subordinate suffix humans,ou=foo
overlay syncprov
To put the overlay into the database context does not make any difference.
database bdb subordinate suffix system,ou=foo
In step 2 this database should be replicated to other servers. So if the overlay has to be defined in database context, there must be one here also.
You probably want to remove the syncprov overlay here.
Done that, see above. Does not work.
Also, you should not sync-repl a glued database, rather sync-repl the subordinates individually, and glue them back together on the consumer.
That's what I did. At consumer side I don't have any problem with glued databases, only at the provider. The syncrepl defintion (consumer) is at database ou=humans,ou=foo, which is subordinated unter database ou=foo.
This is all what happens at the consumer:
wait4msg ld 21a1d668 msgid -1 (timeout 0 usec) wait4msg continue ld 21a1d668 msgid -1 all 0 ** ld 21a1d668 Connections: * host: rzhs720.xxx.de port: 389 (default) refcnt: 2 status: Connected last used: Wed Jun 20 10:50:22 2007
** ld 21a1d668 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ** ld 21a1d668 Response Queue: Empty ldap_chkResponseList ld 21a1d668 msgid -1 all 0 ldap_chkResponseList returns ld 21a1d668 NULL ldap_int_select connection_get(17): got connid=0 daemon: added 17r listener=0 daemon: activity on 1 descriptor daemon: waked daemon: select: listen=6 active_threads=0 tvp=zero
At provider side I see the following for new entries:
=> acl_mask: access to entry "employeeNumber=id_rzl-0020.schulung,ou=humans,ou=foo", attr "entryCSN" requested => acl_mask: to value by "cn=human,ou=mgr,ou=foo", (=0) <= check a_dn_pat: anonymous <= check a_dn_pat: cn=human,ou=mgr,ou=foo <= acl_mask: [2] applying write(=wrscxd) (stop) <= acl_mask: [2] mask: write(=wrscxd) => access_allowed: search access granted by write(=wrscxd) <= test_filter 5 <= test_filter_and 5 <= test_filter 5 bdb_search: 163 does not match filter => test_filter AND => test_filter_and => test_filter GE
Hans
Buchan Milne schrieb:
To put the overlay into the database context does not make any difference.
It seems, I was wrong. Sorry. After I made a new change to one entry on the master and waited a bit longer, the changes were replicated to the consumer.
Hans
On Wed, Jun 20, 2007 at 11:16:47AM +0200, Hans Moser wrote:
Buchan Milne schrieb:
To put the overlay into the database context does not make any difference.
It seems, I was wrong. Sorry. After I made a new change to one entry on the master and waited a bit longer, the changes were replicated to the consumer.
In the long run this replication won't work with openldap 2.3.x. See ITS#4626. You need to use one replication for each database, ignoring the glue at the provider.
Andreas Hasenack schrieb:
To put the overlay into the database context does not make any difference.
It seems, I was wrong. Sorry. After I made a new change to one entry on the master and waited a bit longer, the changes were replicated to the consumer.
In the long run this replication won't work with openldap 2.3.x. See ITS#4626. You need to use one replication for each database, ignoring the glue at the provider.
I think, that's what I'm doing now.
provider: ----------- database bdb suffix ou=humans,ou=foo subordinate overlay syncprov
database bdb suffix ou=sys,ou=foo subordinate overlay syncprov
database bdb suffix ou=foo
overlay glue
consumer 1: ----------- database bdb suffix ou=humans,ou=foo subordinate
syncrepl rid=401 provider=ldap://provider type=refreshAndPersist retry="60 10 300 10 3600 10" searchbase="ou=humans,ou=foo" bindmethod=simple binddn="cn=human,ou=mgr,ou=foo" credentials=nothing updateref ldap://provider
database bdb suffix ou=foo
overlay glue
consumer 2: ----------- database bdb suffix ou=sys,ou=foo subordinate
syncrepl rid=401 provider=ldap://provider type=refreshAndPersist retry="60 10 300 10 3600 10" searchbase="ou=sys,ou=foo" bindmethod=simple binddn="cn=sys,ou=mgr,ou=foo" credentials=nothing updateref ldap://provider
database bdb suffix ou=foo
overlay glue
Is this fine (for now and 2.4)?
Hans
openldap-software@openldap.org
-
Andreas Hasenack -
Buchan Milne -
Hans Moser