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

Re: trouble with replication



"Kurt D. Zeilenga" wrote:
> 
> At 03:09 PM 2/3/00 +0000, Olivier Aussage wrote:
> >Hello,
> >
> >
> >I'm running 1.2.7 on a Linux 2.2.14 system.
> >I have a master Ldap server and two replicate servers.
> 
> Are all servers and tools from 1.2.7?

yep all 1.2.7

> 
> >I have a particular attribut which contains some flags :
> >--> at: bu,cp
> >Adding a flag is OK even on the slapves server but when I want to remove
> >all the flags, it works fine on the master ldap server but there is no
> >replication for this modification on the slaves. (The attribut 'at' is
> >not require in the objectclass so it can be empty or missing).
> 
> Using ldap command line tools or what?   Please repeat using
> ldapmodify.

whatever you want: command line (ldapmodify), api (Net::LDAPapi,
Net::Ldap ...)

> 
> >Here is what I found in the slurpd.replog :
> >
> >Here I just add the flag 'bu' to the attribut at :
> >replica: ldap2.priv2
> >replica: ldap3.priv2
> >time: 949589247
> >dn: L=AO005-2,M=AO005,C=MYCOM,T=B
> >changetype: modify
> >replace: at
> >at: bu
> >
> >Here I removed this flag :
> >replica: ldap2.priv2
> >replica: ldap3.priv2
> >time: 949589253
> >dn: L=AO005-2,M=AO005,C=MYCOM,T=B
> >changetype: modify
> >replace: at
> >at:
> 
> It appears the client sent an modify/replace without
> any values.  In OpenLDAP 1.x, this is considered an
> error.  The server should have reported a protocolError
> "No values given" error.   Is it possible that the
> master is actually something other than OpenLDAP 1.x,
> say OpenLDAP-devel?

The master is really 1.2.7
What I don't understand is that since the modification is accepted on
the master and the value is right on it, why slurpd (or slapd via
slurpd.replog) is not capable of doing the same thing on the slaves ?
Actually how is it possible that slapd produces log for slurp which are
wrong ? 



--
Olivier Aussage,  oau@oleane.net