[Date Prev][Date Next]
Re: add,modify rules not consistent (ITS#3138)
> Well, I have not done this via the command line. We use a java
> application to write the values between our sybase database and
> 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)
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497