Hi Jonathon,

On 24 Sep 2010, at 08:38, Jonathan CLARKE wrote:

Hi,

Le 24/09/2010 07:31, Alister Forbes a écrit :

...

Hi Jonathon,

On 23 Sep 2010, at 15:24, Jonathan CLARKE wrote:

...

Hello Alister,

Le 23/09/2010 12:04, Alister Forbes a écrit :

...

All,

I have two identical servers (RHEL based VMs, server1 and server3) running 2.4.23 openldap.

built with these options:

--with-tls --prefix=/etc/operator/openldap --enable-syncprov --enable-syslog --enable-crypt -

I have the strangest problem, and am desperate for any insight you might provide

If I make a change on server3, then everything is fine, and the change is replicated to server1 If I make a change on server1 then server1 changes, but no changes are seen on server 3.

looking at the logs, on server1, Using tcpdump to sniff the connection, when a change is made on server1, it doesn't even attempt to contact server3.

As far as I can tell the configs are identical, and I have no clue whats causing this. Any hint at all would be gratefully accepted. Configs from both machines attached. server1 and server3(output of ldapsearch on cn=config) Also attached, logs (olcLogLevel is Sync) of the results when I change a value (olcLogLevel) on the two servers (change-on-server1 and change-on-server3)

I note several things:

The retry value of your syncrepl statements is set so that only a limited number of retries will occur. It is possible that (during some downtime) slapd has used up all these retries, and given up on a particular syncrepl consumer. A restart of slapd should solve this.

Looking at the logs, it seems that server3 at least is confused as to who is who, since it is sending out the change to both server1 and itself (and then dismissing it with "CSN too old, ignoring").

However, since one of your changes is to change the log level to "stats", therefore excluding "sync", it's unclear how trustworthy these logs are...

I suggest starting over: restart both instances of slapd with -c rid=001 -c rid=003, to reset the replication status, and take it from there.

Hope this helps, Jonathan --

Thanks very much for this, I should have been clearer in my original mail. Although I did make changes to the olcLogLevel in the ldapmodify commands, at the beginning of each command olcLogLevel was always set to Sync.

I did restart, with the -c options, but I'm still seeing exactly the same behaviour

Looking at my configs again, I still see only one ContextCSN on server3, and two on server1.

Any suggestions?

In this case, I suspect something is wrong with your DNS/IP setup. slapd identifies itself against the values in olcServerID by checking the host's FQDN (see the output of hostname --fqdn) and the hostnames in the -h option passed on startup.

Make sure your /etc/hosts contains sensible values for all names and IPs involved, and that you're running both slapds with something like -h ldap://serverN.example.com/.

If this still fails, maybe post a log excerpt from slapd startup with log levels config and sync?

Jonathan

I think you may be on to something here.. if I launch server3 with slapd -h ldap://server3.example.com then I can't connect to it with ldapsearch any more.. but server1 does Sync with it.

Now I just have to work out the magic incantation that lets both myself, and another master talk to an ldap server at the same time.

from server1:

netstat -an | grep 389 tcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:389 127.0.0.1:62264 ESTABLISHED tcp 0 0 127.0.0.1:62264 127.0.0.1:389 ESTABLISHED tcp 0 0 <SNIP>.181.39:389 <SNIP>.181.2:33860 ESTABLISHED tcp 0 0 :::389 :::* LISTEN

from server3: # netstat -an | grep 389 tcp 0 0 127.0.0.1:389 0.0.0.0:* LISTEN tcp 0 0 <SNIP>.181.2:33860 <SNIP>.181.39:389 ESTABLISHED tcp 0 0 ::1:389 :::* LISTEN

This looks like it's not listening for any new connections once the connection to server1 is set up. Does that sound right?

Alister

--

Jonathan CLARKE

Normation 44 rue Cauchy, 94110 Arcueil, France

---

Telephone: +33 (0)1 83 62 26 96

Web: http://www.normation.com/

-- Alister Forbes Work: +32 2 704 5762 Internal: 322 5762 a@cisco.com TACSUNS _.|._.|._ Cisco Systems

Please avoid sending me Word or PowerPoint attachments. See - http://www.gnu.org/philosophy/no-word-attachments.html