4:12 p.m.
Hi there again,
I'm running OpenLDAP 2.4.11.
I followed the 18.3.3. N-Way Multi-Master on the
http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master
documentation.
I setup only two servers. When I run the new configuration on the
first change in one server is replicated to the other server. After
that all changes that I made are not replicated. What can be causing
this problem?
Here is the configuration that I used for cn=config:
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov
dn: cn=config
changetype: modify
replace: olcServerID
olcServerID: 1 ldap://192.168.139.10
olcServerID: 2 ldap://192.168.139.11
dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcSyncRepl
olcSyncRepl: rid=001 provider=ldap://192.168.139.10
binddn="cn=admin,cn=config" bindmethod=simple credentials="ii"
searchbase="cn=config" type=refreshAndPersist retry="5 10 10 +"
timeout=1
olcSyncRepl: rid=002 provider=ldap://192.168.139.11
binddn="cn=admin,cn=config" bindmethod=simple credentials="ii"
searchbase="cn=config" type=refreshAndPersist retry="5 10 10 +"
timeout=1
-
add: olcMirrorMode
olcMirrorMode: TRUE
And the configuration for bdb database
dn: olcDatabase={1}bdb,cn=config
changetype: modify
add: olcRootDN
olcRootDN: cn=admin,dc=arquis,dc=local
-
add: olcSyncRepl
olcSyncRepl: rid=003 provider=ldap://192.168.139.10
binddn="cn=admin,dc=arquis,dc=local" bindmethod=simple
credentials="ii" searchbase="dc=arquis,dc=local" type=refreshOnly
interval=00:00:00:10 retry="5 10 10 +" timeout=1
olcSyncRepl: rid=004 provider=ldap://192.168.139.11
binddn="cn=admin,dc=arquis,dc=local" bindmethod=simple
credentials="ii" searchbase="dc=arquis,dc=local" type=refreshOnly
interval=00:00:00:10 retry="5 10 10 +" timeout=1
-
add: olcMirrorMode
olcMirrorMode: TRUE
dn: olcOverlay=syncprov,olcDatabase={1}bdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
Here is some output debug:
root@ubuntu:~# /usr/sbin/slapd -d 16384
@(#) $OpenLDAP: slapd 2.4.11 (Nov 8 2008 09:42:18) $
buildd@palmer:/build/buildd/openldap-2.4.11/debian/build/servers/slapd
slapd starting
do_syncrep2: rid=004 LDAP_RES_SEARCH_RESULT
do_syncrep2: rid=002 LDAP_RES_INTERMEDIATE - REFRESH_DELETE
do_syncrep2: rid=003 LDAP_RES_SEARCH_RESULT
do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - REFRESH_DELETE
That's equal to the output of the 2nd server:
root@ubuntu:~# /usr/sbin/slapd -d 16384
@(#) $OpenLDAP: slapd 2.4.11 (Nov 8 2008 09:42:18) $
buildd@palmer:/build/buildd/openldap-2.4.11/debian/build/servers/slapd
slapd starting
do_syncrep2: rid=003 LDAP_RES_SEARCH_RESULT
do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - REFRESH_DELETE
do_syncrep2: rid=004 LDAP_RES_SEARCH_RESULT
do_syncrep2: rid=002 LDAP_RES_INTERMEDIATE - REFRESH_DELETE
do_syncrep2: rid=004 LDAP_RES_SEARCH_RESULT
do_syncrep2: rid=003 LDAP_RES_SEARCH_RESULT
Thanks in advances
3:39 a.m.
Calos Lopez wrote:
I'm running OpenLDAP 2.4.11.
I followed the 18.3.3. N-Way Multi-Master on the
http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master
documentation.
I setup only two servers. When I run the new configuration on the
first change in one server is replicated to the other server. After
that all changes that I made are not replicated. What can be causing
this problem?
Especially for such a configuration you should run a recent release of
OpenLDAP (2.4.16 at the moment). There have been numerous fixes to
syncrepl since 2.4.11.
Ciao, Michael.
2:28 p.m.
Just upgraded to version 2.4.15 and the issue is exactly the same: only the
first change is replicated to the other server. I don't think upgrading to
version 2.4.16 will resolve this. Any clues? Just one more thing in the
tutorial is said the the the setup of syncrepl is only necessary for the
first server because all the config that will be replicated "*(...)We still
have to replicate the actual data, not just the config, so add to the master
(all active and configured consumers/masters will pull down this config, as
they are all syncing)(..)*". Actually that didn't happen, I had to replicate
to all servers the backend database syncrpl configuration. May this is a
clue....
Thanks
2009/6/22 Michael Ströder <michael(a)stroeder.com>
Calos Lopez wrote:
>
> I'm running OpenLDAP 2.4.11.
> I followed the 18.3.3. N-Way Multi-Master on the
>
http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master
> documentation.
> I setup only two servers. When I run the new configuration on the
> first change in one server is replicated to the other server. After
> that all changes that I made are not replicated. What can be causing
> this problem?
Especially for such a configuration you should run a recent release of
OpenLDAP (2.4.16 at the moment). There have been numerous fixes to
syncrepl since 2.4.11.
Ciao, Michael.
1:43 a.m.
Calos Lopez wrote:
2009/6/22 Michael Ströder <michael(a)stroeder.com
<mailto:michael@stroeder.com>>
Calos Lopez wrote:
>
> I'm running OpenLDAP 2.4.11.
> I followed the 18.3.3. N-Way Multi-Master on the
>
http://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master
> documentation.
> I setup only two servers. When I run the new configuration on the
> first change in one server is replicated to the other server. After
> that all changes that I made are not replicated. What can be causing
> this problem?
Especially for such a configuration you should run a recent release of
OpenLDAP (2.4.16 at the moment). There have been numerous fixes to
syncrepl since 2.4.11.
Just upgraded to version 2.4.15 and the issue is exactly the same: only
the first change is replicated to the other server. I don't think
upgrading to version 2.4.16 will resolve this.
Why don't you take my advice serious? If you continue to ignore specific
hints nobody will bother to answer your questions in the future.
It's my strong belief that when using Open Source software one should
take care of economical aspects of the developer's and other volunteers'
spare time. So in general it's bad practice to report bugs of older
release again when these might have already been fixed in a newer
release. It's the user's obligation to prove that a bug still persists
in a recent release (or even preferrably in a recent CVS checkout).
Before making any assumptions one should look into file CHANGES of a
recent source release. For your particular issue have a look at these lines:
OpenLDAP 2.4.16 Release (2009/04/05)
[..]
Fixed slapd syncrepl newCookie sync messages (ITS#5972)
Fixed slapd syncrepl hang during shutdown (ITS#6011)
Fixed slapd syncrepl too many MMR messages (ITS#6020)
Fixed slapd syncrepl skipped entries with MMR (ITS#5988)
Ciao, Michael.
3:49 a.m.
On 22/06/2009 23:28, Calos Lopez wrote:
Just upgraded to version 2.4.15 and the issue is exactly the same:
only the first change is replicated to the other server. I don't
think upgrading to version 2.4.16 will resolve this.
It may not resolve this issue, but since several replication related
fixes were introduced, you'd probably be better off using it anyway, to
avoid future issues, once you get your config working.
Any clues? Just one more thing in the tutorial is said the the the
setup of syncrepl is only necessary for the first server because all
the config that will be replicated "/(...)We still have to replicate
the actual data, not just the config, so add to the master (all
active and configured consumers/masters will pull down this config,
as they are all syncing)(..)/". Actually that didn't happen, I had to
replicate to all servers the backend database syncrpl configuration.
May this is a clue....
You may be running into the issue described in a note just below that quote:
Note: As stated in slapd-config(5), URLs specified in olcSyncRepl
directives are the URLs of the servers from which to replicate. These
must exactly match the URLs slapd listens on (-h in Command-Line
Options). Otherwise slapd may attempt to replicate from itself,
causing a loop.
In your original message, you state that you launch slapd using:
root@ubuntu:~# /usr/sbin/slapd -d 16384
I suggest adding "-h ldap://192.168.139.10" (and .11 respectively) to
that. This way, slapd can know which server is 'self', and which are others.
Jonathan
--
--------------------------------------------------------------
Jonathan Clarke - jonathan(a)phillipoux.net
--------------------------------------------------------------
Ldap Synchronization Connector (LSC) - http://lsc-project.org
--------------------------------------------------------------
5026
days inactive
5028
days old
openldap-software@openldap.org
4 comments
3 participants
participants (3)
-
Calos Lopez -
Jonathan Clarke -
Michael Ströder