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

Re: add,modify rules not consistent (ITS#3138)

--On Monday, May 10, 2004 3:23 PM -0700 "Kurt D. Zeilenga" 
<Kurt@OpenLDAP.org> wrote:

> I did a similar test using OPENLDAP_REL_ENG_2_2 (which should be
> consistent with 2.2.11 in this area).
> replace: sn
> sn:: bWFqb3iq
> sn:: IG1ham9y
> and got
>   ldap_modify: Type or value exists (20)
>     additional info: sn: value #0 provided more than once
> Are you sure you're not trying to do?
> replace: sn
> sn: bWFqb3iq
> sn: IG1ham9y
> (note the ':' instead of '::')

Well, I have not done this via the command line.  We use a java application 
to write the values between our sybase database and OpenLDAP.

It itself has no idea of the encoding, the directory itself was encoding 
the values after they were received.  The program tried to write:

"cn: major "
"cn:major "

to the directory.  It got value #0 provided more than once if it was doing 
an ADD, and success if it was a replace.

I pulled these values straight out of the replog file created by OpenLDAP 
when the changes came in.  Not only did it work there, it worked when 
slurpd replicated it to all the replica's.  I just happened to be watching 
the slurpd replog at the time, because of our upgrade, which is why I saw 
this in the first place.

>From the LDAP log that generated the CN values:

May  8 23:35:33 ldap0.Stanford.EDU slapd[22400]: [ID 177021 local4.debug] 
conn=275 op=7 MOD 
May  8 23:35:33 ldap0.Stanford.EDU slapd[22400]: [ID 324647 local4.debug] 
conn=275 op=7 MOD attr=cn
May  8 23:35:33 ldap0.Stanford.EDU slapd[22400]: [ID 217296 local4.debug] 
conn=275 op=7 RESULT tag=103 err=0 text=


Quanah Gibson-Mount
Principal Software Developer
ITSS/TSS/Computing Systems
ITSS/TSS/Infrastructure Operations
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html