[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
dn="suregid=86c9593cf61311d2ae660800209269ec,cn=People,dc=Stanford,dc=edu"
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
--
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