[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
(ITS#9486) slapo-unique spins its wheels on a non-trivial olcUniqueURI spec
- To: openldap-its@OpenLDAP.org
- Subject: (ITS#9486) slapo-unique spins its wheels on a non-trivial olcUniqueURI spec
- From: gray@nxg.name
- Date: Fri, 13 Sep 2019 15:34:04 +0000
- Auto-submitted: auto-generated (OpenLDAP-ITS)
Full_Name: Norman Gray
Version: 2.4.48
OS: FreeBSD 12.0
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (130.209.45.140)
A plausible-looking spec in olcUniqueURI causes slapadd to spin its wheels
indefinitely.
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
If I do this, however, then slapadd spins its wheels when the `slapd.ldif` is
loaded into an otherwise empty configuration (ie, this happens at configuration
time, before any records/objects are loaded):
$ 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.
The idea is that the uidnumber attribute should be unique across the two OUs,
ou=dept-A and ou=dept-B. Whether or not this is a valid spec is another issue;
even if it's invalid, it shouldn't cause this behaviour; if the spec is invalid,
it should produce a terminal error.
Looking at the code in servers/slapd/overlays/unique.c, nothing leaps out as an
obvious error (ie, I'm not claiming I have a fix for this).
There was a brief thread about this on openldap-technical:
<https://www.openldap.org/lists/openldap-technical/201909/msg00031.html>
Configuration:
# /usr/local/libexec/slapd -VVV
@(#) $OpenLDAP: slapd 2.4.48 (Sep 10 2019 13:30:19) $
root@hermite.physics.gla.ac.uk:/var/ports/usr/ports/net/openldap24-server/work/openldap-2.4.48/servers/slapd
Included static overlays:
constraint
syncprov
unique
Included static backends:
config
ldif
relay
# freebsd-version
12.0-RELEASE-p9
This is the most recent currently-packaged version of OpenLDAP on FreeBSD.