Re: Problem with overlay uniqe

[Michael Ströder <michael@stroeder.com>]

masarati@aero.polimi.it wrote:
>> Ruud Baart wrote:
>>> I use slapd 2.4.23 (debian package) with some overlays: syncprov, unique
>>> and
>>> valsort. I have a problem with the unique overlay.
>>>
>>> This is the unique constraint:
>>> olcUniqueURI:
>>> ldap://ou=Workstations,ou=Devices,dc=example,dc=com/?uid?sub
>>
>> This is not a valid LDAP URL. Probably this should be this LDAP URL with
>> emtpy hostport part:
>>
>> ldap:///ou=Workstations,ou=Devices,dc=example,dc=com?uid?sub
>>
>> See http://www.ietf.org/rfc/rfc4516.txt for syntax of LDAP URLs.
> 
> Good catch; please note that the original URI was valid, but it meant
> 
> $ ./libraries/libldap/urltest
> 'ldap://ou=Workstations,ou=Devices,dc=example,dc=com/?uid?sub'
> generic LDAP url
> PROTO: ldap
> HOST: ou=Workstations,ou=Devices,dc=example,dc=com
> PORT: 389
> ATTRS:
> 	uid
> SCOPE: sub
> URL: ldap://ou=Workstations,ou=Devices,dc=example,dc=com:389/?uid?sub

Academic nitpicking mode on: ;-)

No matter what OpenLDAP's (and python-ldap's) LDAP URL parser let pass through
because of ldapi URLs I don't think that the original URI was valid because a
DN is not a valid host [COLON port] part.

See section 2. of RFC 4516:
[..]
      ldapurl     = scheme COLON SLASH SLASH [host [COLON port]]
                       [SLASH dn [QUESTION [attributes]
                       [QUESTION [scope] [QUESTION [filter]
                       [QUESTION extensions]]]]]
                                      ; <host> and <port> are defined
                                      ;   in Sections 3.2.2 and 3.2.3
                                      ;   of [RFC3986].
[..]

> This error would have been caught if unique_new_domain_uri() checked that
> the host portion be empty, to indicate a local URI, as in many other
> functionalities of OpenLDAP's slapd.  I suggest an ITS be filed to
> strengthen misconfiguration detection.

My ITS will be ignored anyway. So better you should file one.

Ciao, Michael.