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
I try to add a ldif like this:
dn: uid=userabc,ou=MozillaAddressBook,ou=Users,dc=example,dc=com objectClass: person ... objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: .. ... uid: userabc ...
with ldapadd I get:
ldap_add: Constraint violation (19) additional info: some attributes not unique
When I remove the unique constraint the ldif file is accepted.
It seems to me that something is wrong: the base of olcUniqueURI is different from the base where I try to add a entry. I don't understand this. Is the olcUniqueURI wrong?
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.
Ciao, Michael.
Thank you, now its works. I've been blind and I should have been alarmed by the "/?" part in the olcUniqueURI.
Op 11-8-2011 12:21, Michael Ströder schreef:
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.
Ciao, Michael.
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
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.
p.
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.
--On Thursday, August 11, 2011 10:47 PM +0200 Michael Ströder michael@stroeder.com wrote:
My ITS will be ignored anyway. So better you should file one.
False. A quick perusal of the ITS system shows this is a blatant misrepresentation of the facts. ITSes that you file are most certainly not ignored. This sort of negative and false commentary is not productive.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
--On Thursday, August 11, 2011 10:47 PM +0200 Michael Ströder michael@stroeder.com wrote:
My ITS will be ignored anyway. So better you should file one.
False. A quick perusal of the ITS system shows this is a blatant misrepresentation of the facts. ITSes that you file are most certainly not ignored. This sort of negative and false commentary is not productive.
ITS#6928
Ciao, Michael.
Michael Ströder wrote:
Quanah Gibson-Mount wrote:
--On Thursday, August 11, 2011 10:47 PM +0200 Michael Ströder michael@stroeder.com wrote:
My ITS will be ignored anyway. So better you should file one.
False. A quick perusal of the ITS system shows this is a blatant misrepresentation of the facts. ITSes that you file are most certainly not ignored. This sort of negative and false commentary is not productive.
ITS#6928
Or counter-examples, ITS#6879, #6899.
Or side example ITS#6942. Nobody is singling you out but yourself. Volunteers work on this project when they're able. That has always been the case. If nobody volunteers to tackle any work, then the work doesn't happen.
[...] I suggest an ITS be filed to strengthen misconfiguration detection.
My ITS will be ignored anyway. So better you should file one.
The suggestion actually was for the original poster, although I was admittedly replying to your message, with the original poster in CC.
However, I also find your pessimistic attitude inappropriate, since several ITSes submitted by you have been dealt with, and in many cases successfully addressed (i.e. the problem was solved, and the fix released). Currently there are 111 ITS in incoming; some have been there for years. Only few of them have been submitted by you. You seem to be a pretty good tester (I should say a dam..d good tester) as you can produce so many unusual conditions that can hardly be reproduced and thus successfully dealt with. Whenever possible, ITS submitted by you (as well as by others) have been dealt with based on developers' availability, competence in the specific area of the ITS and so. So I would be more optimistic. In any case, I'll open (and close) the ITS, as the fix is definitely trivial.
p.
openldap-technical@openldap.org
-
Howard Chu -
masarati＠aero.polimi.it -
Michael Ströder -
Quanah Gibson-Mount -
Ruud Baart