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.