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

[ando@sys-net.it]

> 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:

The encoding is simply a way to show values which are not easily
printable.  A leading or trailing space makes values be represented in
base64 to make clear the extra space is actually part of the value.

>
> "cn: major "
> "cn:major "

In this case, the two values are identical if provided via ldapmodify,
because the first space(s) after a single ':' is(are) eaten.
even "cn:  major " would be parsed the same (i.e. "major ").
I don't know how your app parses this; to have " major" you definitely
need to use "cn:: IG1ham9y" from the command line.

>
> 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.

The replication working I think can be related to slurpd replication
exploiting the SLURPD_FRIENDLY code... (see servers/slapd/add.c)

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it




    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497