Re: slurpd replicatoin problems

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

I found the problem, although the error message is definitely not specific
to it.

On the one server, I had at some point added the directive:
updatedn  "cn=diradmin,dc=domain,dc=dom"

I had not added this to the other server.  Adding it in solved the problem.

However, the error message "ERROR: Type or value exists" is misleading.

Of course, so is the word replicatoin vs replication, which I just now
noticed. ;}

Cheers,
John


> 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


-- 
John Hogenmiller, kb3dfz
Network Engineer
Pennswoods.net
877.716.2002 x 529