[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: slurpd replicatoin problems



Hi,

I'm currently dealing with a similar problem, due to several "replica"
statements concerning a single slave. This could occur only if you have
several back-ends (several suffixes) on the master server and wants to
replicate more than one to a single slave server.
If this is your case, you may have a look at ITS#2137 (
http://www.OpenLDAP.org/its/index.cgi?findid=2137) to see if it can match
with your problem.

Cheers,

Bruno

----- Original Message -----
From: "John Hogenmiller" <john@pennswoods.net>
To: <openldap-software@OpenLDAP.org>
Sent: Friday, October 11, 2002 6:01 PM
Subject: slurpd replicatoin problems


> Hello,
>
> I am in the process of upgrading our ldap servers to openldap 2.1.5.
>
> Our setup:
>
> 1 master ldap server behind a firewall.
> 4 slave ldap servers in remote locations
>
> stunnel is setup to securely transmit ldap changes from the master ldap
> server to the remote ldap servers.  We have maintained this setup
> peacefully for two years (the only change being moving from ugly ssh
> tunnels to the cleaner stunnel).
>
> Recently, I have begun upgrading these boxes from 2.0.xx versions to 2.1.5
> I upgraded one box to the new version, and it immediately stopped taking
> new updates from our master ldap server.  It would accept type:
> modification, but not type: add.  Each addition would be rejected with the
> message "type or value already exists".  An ldapsearch showed the object
> didn't exist, and using ldapadd would successfully insert the rejected
> entry.  At this time, we were running openldap 1.1.13-eng on the master
> ldap server and I suspected the version discrprency as the culprit.
>
> Because we were planning on upgrading everything, I setup openldap 2.1.5
> on the master ldap server and worked with it till I had it replicating to
> both 2.0.xx (18-21) servers, and the 2.1.5 server.  Once I had everything
> setup, I switched everything over to using the 2.1.5 server. (On a fresh
> install of redhat 7.3, db-4.1.24).
>
> The remote ldap server (slave0) with openldap 2.1.5 also has a fresh
> install of redhat 7.3, db-4.1.24.  I created an additional slave (slave1)
> with the exact same configuration and put it in place.
>
> Now, when slurpd on master does a replication, it succeeds in replicating
> to slave0, slave2, and slave3 (slave2 and slave3 are older versions of
> ldap and linux).  When it goes to make an addition to slave1, I get the
> following error in openldap-slurpd/replica/localhost:4005.ref:
>
> ERROR: Type or value exists
> replica: localhost:4005
> time: 1034142867.0
> dn: uid=testjp7,ou=people,dc=pennswoods,dc=net
> changetype: add
> gecos: test test
> .. <remaining ldap entry>
>
> This is the same exact problem I had when the master running 1.1.13eng was
> attempting to replicate to slave0 running 2.1.5.
>
> This is not an issue where I am sending the same add twice to the same
> server.  I checked this out thoroughly.  The stunnel's are pointing at the
> right server, no two are going to the same server, and they are listening
> on the right port, as defined in slapd.conf.  And no, the dn does not
> exist on the remote server, never did, and doesn't until I run slapadd
> directly (either contacting the remote server directly, or over the
> stunnel).
>
> I've been searching the mailling list for anyone with similiar problems
> and haven't seen anything more recent than 2 years ago, and the
> problem/solution did not match my scenario.
>
> At this point, I have exhausted my knowledge of where to look.  I can
> provid e configuration files, debug logs, etc.  If this is a problem with
> the underlying database (db-4.1.24), let me know.  I feel this is a
> problem with slurpd, as ldapadd works perfectly fine processing these .rej
> files (after eliminating a few extraneous lines that slurpd uses).
>
> Thanks in advance for any help you can provide.
>
> Cheers,
> John
>
>
> --
> John Hogenmiller, kb3dfz
> Network Engineer
> Pennswoods.net
> 877.716.2002 x 529
>