Re: The unique overlay: enforcing uniqueness in the union of trees
On Tue, Feb 06, 2024 at 12:29:37PM +, Norman Gray wrote:
> Greetings.
>
> How should I use the 'unique' overlay to enforce uniqueness of an
> attribute across two trees?
>
> I'd have thought that the following would work, to enforce uniqueness
> across ou=dept1 and ou=dept2, but it doesn't seem to.
>
> dn: olcOverlay=unique,olcDatabase={1}mdb,cn=config
> objectClass: olcOverlayConfig
> objectClass: olcUniqueConfig
> olcOverlay: unique
> olcUniqueURI: ldap:///ou=dept1,o=example?uidnumber?sub
> ldap:///ou=dept2,o=example?uidnumber?sub
>
> (and cf, slapd/overlays/unique.c:unique_new_domain).
>
> When I configure a server with this, and load two entities with the same
> uidNumber, the server doesn't object. I'm clearly misunderstanding
> something.
>
> The slapo-unique(5) manpage suggests that having two URIs juxtaposed
> like this is syntactically OK, but it doesn't make clear the
> semantics of this. I'd guessed that the above configuration would
> create a 'domain' which is the union of the two subtrees, but
> that doesn't seem to be the case.
Hi Norman,
you're right, the uniqueness domains aren't specified anywhere and the
overlay currently just runs through each URI independently. It also
checks that the entry matches the URI as well, so a DN like
"uid=u2,ou=dept1,o=example" is only checked against the first URI and
dept2 wouldn't be checked.
The next best thing I can see is if you create two URIs, one for each
dept2 and dept3 more or less like this:
ldap:///?uidnumber?sub?(|\
(entryDN:dnSubtreeMatch:=ou=dept1,o=example)
(entryDN:dnSubtreeMatch:=ou=dept2,o=example))
ldap:///?uidnumber?sub?(|\
(entryDN:dnSubtreeMatch:=ou=dept1,o=example)
(entryDN:dnSubtreeMatch:=ou=dept3,o=example))
That should trigger exactly as you need and cover the relevant parts of
the tree. Not sure it works when there's a lot of gluing going on but
worth a try.
Regards,
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
Re: The unique overlay: enforcing uniqueness in the union of trees
Quanah, hello. On 7 Feb 2024, at 19:26, Quanah Gibson-Mount wrote: > Since it was historically done this way, yeah, best thing is to slowly fix > the data until it can be done correctly. It's really a local case of NIS. Must. Die Norman -- Norman Gray : https://nxg.me.uk
Re: The unique overlay: enforcing uniqueness in the union of trees
--On Tuesday, February 6, 2024 4:27 PM + Norman Gray wrote: Store what department(s) they belong to as attribute in their user entry. I take the point, and I certainly wouldn't organise things this way if _I_ were king. In this case, though, dept1, dept2, and so on, are separate administrative domains, in both IT terms and real bureaucratic ones, and this is an attempt to bring some sort of coherence to a bit of historic anarchy (and yes, there is an ou=staff layer in the middle of the real trees). Everyone more-or-less agrees on the names and uidNumbers in dept1, but there might be a local 'norman' in both dept2 and dept3, or people in those trees with historically colliding UIDs. The result is that systems in dept2 will acknowledge users in ou=dept1 and ou=dept2, users in dept3 acknowledge ou=dept1 and dept3 but ignore ou=dept2, and so on. I expect that names will soon no longer be created in the deptN trees (pretty please?), in favour of the dept1 tree, and the ou=staff parts of those will atrophy, but I'll be retired by then. If there's a different way of approaching that particular problem, though, right now is the time for me to be rethinking this, so I'm open to challenge. Ah, ok I thought you were setting up a new server. Since it was historically done this way, yeah, best thing is to slowly fix the data until it can be done correctly. Sounds like it would take an institutional commitment to resolving the collisions to ever fix this fully. --Quanah
Re: The unique overlay: enforcing uniqueness in the union of trees
Quanah, hello. On 6 Feb 2024, at 16:03, Quanah Gibson-Mount wrote: > Questions about slapo-unique aside, this is a horrific way to organize your > data tree. I'd strongly advise creating a tree for people, like: > > cn=people,dc=example,dc=com > > uid=x,cn=people,dc=example,dc=com > uid=y,cn=people,dc=example,dc=com > > Store what department(s) they belong to as attribute in their user entry. I take the point, and I certainly wouldn't organise things this way if _I_ were king. In this case, though, dept1, dept2, and so on, are separate administrative domains, in both IT terms and real bureaucratic ones, and this is an attempt to bring some sort of coherence to a bit of historic anarchy (and yes, there is an ou=staff layer in the middle of the real trees). Everyone more-or-less agrees on the names and uidNumbers in dept1, but there might be a local 'norman' in both dept2 and dept3, or people in those trees with historically colliding UIDs. The result is that systems in dept2 will acknowledge users in ou=dept1 and ou=dept2, users in dept3 acknowledge ou=dept1 and dept3 but ignore ou=dept2, and so on. I expect that names will soon no longer be created in the deptN trees (pretty please?), in favour of the dept1 tree, and the ou=staff parts of those will atrophy, but I'll be retired by then. If there's a different way of approaching that particular problem, though, right now is the time for me to be rethinking this, so I'm open to challenge. Best wishes, Norman -- Norman Gray : https://nxg.me.uk
Re: The unique overlay: enforcing uniqueness in the union of trees
--On Tuesday, February 6, 2024 12:29 PM + Norman Gray wrote: Greetings. How should I use the 'unique' overlay to enforce uniqueness of an attribute across two trees? I'd have thought that the following would work, to enforce uniqueness across ou=dept1 and ou=dept2, but it doesn't seem to. Questions about slapo-unique aside, this is a horrific way to organize your data tree. I'd strongly advise creating a tree for people, like: cn=people,dc=example,dc=com uid=x,cn=people,dc=example,dc=com uid=y,cn=people,dc=example,dc=com Store what department(s) they belong to as attribute in their user entry. --Quanah
