Re: slurpd replicatoin problems

["John Hogenmiller" <john@pennswoods.net>]

Negative.  There is one backend per server.  I have done several tests to
ensure that I am not pointing slurpd to the same server twice, either
directly or indirectly (ie, pointing two stunnels to the same server).

> 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