Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
I believe this is not a bug, but just a misunderstanding of the documentation.
olcUniqueURI: ldap:///dc=my-domain,dc=com?mail?sub?
olcUniqueURI: ignore ldap:///cn=usr1,dc=my-domain,dc=com?mail?sub?
The documentation says, that the attributes are checked when add, modify, and modrdn operations are performed. When some matching entry is found, the operation is rejected. And the rules are evaluated sequentially. I understand from this statement, that the rules are evaluated sequentially.
And 'ignore' works different than you expect. Documentation says, that by specifying this prefix, uniqueness of all non-operational attributes is enforced, except those listed.
In fact, the second entry you are trying to add (cn=usr1,dc=my-domain,dc=com) would be rejected by both of the rules. The first one because of non-uniqueness of mail attribute, the second one because of non-uniqueness of objectClass.
I suppose you wanted something like (simplified):
olcUniqueURI: ldap:///?mail?sub?(!(cn=usr1))
Closing this bug as NOTABUG.
Created attachment 514000 [details] Slapd configuration file Description of problem: Overlay unique ignore parameter doesn't funcion (same funcionality as unique parameter missing in configuration) Version-Release number of selected component (if applicable): openldap-servers-2.4.23-15.el6 How reproducible: always Steps to Reproduce: 1.slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d/ (slapd.conf is in attachement) 2.add entry dn: cn=usr2, dc=my-domain,dc=com objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: top cn: usr2 sn: usr2 mail: usr2 uid: usr2 dn: cn=usr1,dc=my-domain,dc=com objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: top cn: usr1 sn: usr1 mail: usr2 uid: usr1 Actual results: adding new entry "cn=usr2,dc=my-domain,dc=com" adding new entry "cn=usr1,dc=my-domain,dc=com" ldap_add: Constraint violation (19) additional info: some attributes not unique Expected results: Add operation should pass