Pierre-Emmanuel Brinette wrote:
> 1) both 2.0 and 2.2 are ancient. OpenLDAP 2.3 is mature, and 2.4 is
> about to exit beta stage. Unless the problem is related to a real
> software bug, and it persists either in HEAD/2.4 or in 2.3 code, this
> ITS will be closed.
Currently, I've no mean to use an openldap 2.3 unless exists an RPM
update package for RHEL 4 (or CentOS).
But the problem is that the request like
"attribute=a_string=another_string,..." worked fine with openldap 2.0
but not with openldap 2.2.
I'm not sure I made the point: both 2.0 and 2.2 are ancient.
The fact that something worked with 2.0 doesn't prove anything, as that
software was very poor in validating things, and very forgiving with
respect to syntax and specs compliance errors (which I value as a
defect, while others might see it as a "feature").
The fact that something does no longer work with 2.2 while it worked
with 2.0 is a pity, but it doesn't mean anything as well. Either (a)
2.0 was wrong, and 2.2 correctly detects an error, or (b) 2.0 was right,
and 2.2 introduced a bug, or (c) both were plainly wrong. In any case
2.2 is historical and no longer supported, so in cases (b) and (c) no
one on the OpenLDAP side is going to fix 2.2. You could try asking the
distributor of the packages you're using (YMMV).
What would make things totally different is the persistence of a problem
in 2.3 and 2.4. But the very existence of a problem has to be proven
yet. If you look at my analysis with dntest, you'll see that your DN
is split in
ldap_rdn2str() = "mds-vo-name=UPorto"
ldap_rdn2str() = "mds-vo-name=local"
ldap_rdn2str() = "o=grid"
Is this what you'd expect? Note that in GlueVOViewLocalID embedded '='
are expanded as '\3D'. If any of the commas/equals in the DN are
actually parts of the IA5 string, you'll need to escape them to have
them parsed as expected.
Ing. Pierangelo Masarati
OpenLDAP Core Team
via Dossi, 8 - 27100 Pavia - ITALIA
Office: +39 02 23998309
Mobile: +39 333 4963172