Greetings.
I'm having difficulty creating a non-trivial olcUniqueURI spec. Can anyone advise me?
The problems are:
* A plausible-looking spec in olcUniqueURI causes slapadd to spin its wheels indefinitely. * The manpage doesn't make it terribly clear what I should expect from a plausible-looking spec.
Details follow:
I want to specify something like
dn: olcOverlay=unique,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcUniqueConfig olcOverlay: unique olcUniqueURI: ldap:///ou=dept-A,o=example?uidnumber?sub ldap:///ou=dept-B,o=example?uidnumber?sub
The idea is that the uidnumber attribute should be unique across the two OUs, ou=dept-A and ou=dept-B.
If I do this, however, then slapadd spins its wheels:
$ rm -R /usr/local/etc/openldap/slapd.d/* $ su -m ldap -c "slapadd -d255 -n 0 -F /usr/local/etc/openldap/slapd.d -l /usr/local/etc/openldap/slapd.ldif" ... ... 5d77d377 >>> dnPrettyNormal: <olcOverlay=unique,olcDatabase={1}mdb,cn=config> 5d77d377 <<< dnPrettyNormal: <olcOverlay=unique,olcDatabase={1}mdb,cn=config>, <olcOverlay=unique,olcDatabase={1}mdb,cn=config> 5d77d377 <= str2entry(olcOverlay=unique,olcDatabase={1}mdb,cn=config) -> 0x800d4eca8 5d77d377 oc_check_required entry (olcOverlay=unique,olcDatabase={1}mdb,cn=config), objectClass "olcUniqueConfig" 5d77d377 oc_check_allowed type "objectClass" 5d77d377 oc_check_allowed type "olcOverlay" 5d77d377 oc_check_allowed type "olcUniqueURI" 5d77d377 oc_check_allowed type "structuralObjectClass" 5d77d377 >>> dnNormalize: <olcOverlay={1}unique> 5d77d377 <<< dnNormalize: <olcOverlay={1}unique> 5d77d377 ==> unique_db_init 5d77d377 ==> unique_new_domain <ldap:///ou=dept-A,o=example?uidnumber?sub ldap:///ou=dept-B,o=example?uidnumber?sub> 5d77d377 >>> dnPrettyNormal: <ou=dept-A,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-A,o=example>, <ou=dept-A,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> 5d77d377 >>> dnPrettyNormal: <ou=dept-B,o=example> 5d77d377 <<< dnPrettyNormal: <ou=dept-B,o=example>, <ou=dept-B,o=example> ... ^C
and so on and on and on, apparently indefinitely.
slapo-unique(5) says that the syntax here is:
unique_uri <[strict ][ignore ]URI[URI...]...> Configure the base, attributes, scope, and filter for uniqueness checking. Multiple URIs may be specified within a domain, allowing complex selections of objects. Multiple unique_uri statements or olcUniqueURI attributes will create independent domains, each with their own independent lists of URIs and ignore/strict settings.
Keywords strict and ignore have to be enclosed in quotes (") together with the URI.
The LDAP URI syntax is a subset of RFC-4516, and takes the form:
ldap:///[base dn]?[attributes...]?scope[?filter]
(I'm taking it that there should be a space between those `URI[URI...]`)
in servers/slapd/overlays/unique.c, the comment above `unique_new_domain` says instead
* domain_specs look like * * [strict ][ignore ]uri[[ uri]...] * e.g. "ldap:///ou=foo,o=bar?uid?sub ldap:///ou=baz,o=bar?uid?sub" * "strict ldap:///ou=accounts,o=bar?uid,uidNumber?one" * etc *
So that's clearly permitting multiple URIs -- perhaps the quotes are required (as the manpage hints). But if I try
olcUniqueURI: "ldap:///ou=dept-A,o=example?uidnumber?sub ldap:///ou=dept-B,o=example?uidnumber?sub"
...then I get
5d77d617 ==> unique_new_domain <"ldap:///ou=dept-A,o=example?uidnumber?sub ldap:///ou=dept-B,o=example?uidnumber?sub"> 5d77d617 olcUniqueURI: value #0: <"ldap:///ou=dept-A,o=example?uidnumber?sub ldap:///ou=dept-B,o=example?uidnumber?sub"> invalid ldap urilist
from slapadd (so that's not the problem). But the example there does look VERY much like what I tried.
So:
* I'm pretty sure I shouldn't be able to make slapadd spin its wheels like that. * The manpage text might be a little too telegraphic. While I'm sure it's not _wrong_, it is quite hard to go from that text to a working spec with any confidence.
Googling olcUniqueURI produces very little of use. Is this not the correct way to do this?
This looks somewhat similar, in symptoms and module, to ITS#8162, but it does seem distinct.
Thanks for any pointers.
Best wishes,
Norman
On 9/10/19 7:20 PM, Norman Gray wrote:
The problems are: * A plausible-looking spec in olcUniqueURI causes slapadd to spin its wheels indefinitely. [..] dn: olcOverlay=unique,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcUniqueConfig olcOverlay: unique olcUniqueURI: ldap:///ou=dept-A,o=example?uidnumber?sub ldap:///ou=dept-B,o=example?uidnumber?sub
The above is invalid. Your LDIF should contain separate attribute values for each unique URI:
olcUniqueURI: ldap:///ou=dept-A,o=example?uidnumber?sub olcUniqueURI: ldap:///ou=dept-B,o=example?uidnumber?sub
Of course slapd should not run crazy because of this.
You can look at a running example config (cn=config read-only):
https://demo.ae-dir.com/web2ldap/read?ldapi://%2Fopt%2Fae-dir%2Frun%2Fslapd%...
Ciao, Michael.
Michael, hello.
Thanks for your response.
On 10 Sep 2019, at 19:33, Michael Ströder wrote:
The above is invalid. Your LDIF should contain separate attribute values for each unique URI:
olcUniqueURI: ldap:///ou=dept-A,o=example?uidnumber?sub olcUniqueURI: ldap:///ou=dept-B,o=example?uidnumber?sub
The problem is that both the manpage and the source-code comments seem to state that the attribute can take multiple values. Quoting from the manpage:
Multiple URIs may be specified within a domain, allowing complex selections of objects. Multiple unique_uri statements or olcUniqueURI attributes will create independent domains
I interpret that as saying that each olcUniqueURI attribute corresponds to, or implies, an 'independent domain', and that 'Multiple URIs may be specified within a domain' indicates that a domain can be specified by multiple ldap:/// URIs (though it doesn't say, for example, whether these are composed using UNION or something else). That is, if this text _isn't_ intended to say that there may be multiple olcUniqueURI attributes, each of which can have multiple URIs, then it should be rewritten.
I would interpret your rewritten version as saying that uidnumber attributes should be unique in ou=dept-A, and that they should be unique in ou=dept-B (ie, they are independent), but not that they should be unique in (ou=dept-A UNION ou=dept-B), which is what I want.
So there is at least a documentation gap here.
Of course slapd should not run crazy because of this.
Is there enough information in my previous message for me to add a reasonable ITS report, do you think?
You can look at a running example config (cn=config read-only):
Thanks -- this is very useful (and also nudges investigating Ædir further up my list). I'll study those.
Best wishes,
Norman
Greetings.
On 11 Sep 2019, at 11:09, Norman Gray wrote:
So there is at least a documentation gap here.
Of course slapd should not run crazy because of this.
Is there enough information in my previous message for me to add a reasonable ITS report, do you think?
I've added ITS#9486 and ITS#9488, referring to the wheel-spinning and the documentation, respectively. I hope these are useful.
Best wishes,
Norman
--On Friday, September 13, 2019 7:29 PM +0100 Norman Gray gray@nxg.name wrote:
I've added ITS#9486 and ITS#9488
These are ITSes #9077 and #9079 after fixing the ITS database.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
openldap-technical@openldap.org