Michael Ströder michael@stroeder.com writes:

Ferenc Wagner wrote:

...

We use (among others) this unique domain in a database:

olcUniqueURI: ldap:///?gidNumber?sub?objectClass=posixGroup

so that we can't create two groups with the same gidNumber. The problem is that this rule also denies the creation of a posixAccount belonging to an already existing posixGroup. Of course there is no problem creating the account first and the group later. How could we overcome this ordering limitation?

This is a bug in slapo-unique ignoring the filter part:

http://www.openldap.org/its/index.cgi?findid=6825

You can work around this if your group entries all reside in a separate subtree and you use the DN portion in the olcUniqueURI value.

Hmm, now that you pointed this out, I find these two paragraphs of slapo-unique(5) contradictory:

Uniqueness is enforced by searching the subtree to ensure that the values of all attributes presented with an add, modify or modrdn operation are unique within the scope. For example, if uniqueness were enforced for the uid attribute, the subtree would be searched for any other records which also have a uid attribute containing the same value. If any are found, the request is rejected.

This does not seem to apply the filter to the object being added, matching the behaviour observed by me.

The filter component causes the domain to apply uniqueness constraints only to matching objects. e.g. ldap:///?cn?sub?(sn=e*) would require unique cn attributes for all objects in the subtree of the back-end database whose sn starts with an e.

This says that the filter is applied to the object being added, which makes more sense and would result in sensible behaviour.

So let me ask for clarification: which interpretation is the indended and the implemented one?