-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > >>> What is the default behaviour if no equality type is defined? > From http://tools.ietf.org/html/rfc4512 > " > > If no equality matching is specified for the attribute type: > > - the attribute (of the type) cannot be used for naming; > - when adding the attribute (or replacing all values), no two > values may be equivalent (see 2.2); > - individual values of a multi-valued attribute are not to be > independently added or deleted; > - attribute value assertions (such as matching in search > filters and comparisons) using values of such a type cannot be > performed." > > Which means, you are not supposed to use it in a search filter. Ahh that's good to know. This kind of thing should be in the RHDS documentation as we couldn't find anything about the topic, and it's an invaluable piece of knowledge in solving this issue. > > However, 389 provides a default equality matching rule, which is > essentially a memcmp(3). When you create an index, it attempts to > use the equality matching rule to create the equality index. I guess > the indexing code is getting confused. Do you have > a /var/lib/dirsrv/slapd-INST/db/userRoot/maildeliveryoption.db4 > file? If so, does it have anything in it? dbscan > -f /var/lib/dirsrv/slapd-INST/db/userRoot/maildeliveryoption.db4 > The db4 file in question was empty. I am assuming that this indicates an issue with the indexing yielding no data, but if it was empty, and an index search was performed I am assuming that is why our search begins to return no data. > You can also force the indexing to use a particular matching rule - > see > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Indexes-Creating_Indexes.html#Creating_Indexes-Creating_Indexes_from_the_Command_Line > you specify the matching rule to use for the index by using the > nsMatchingRule attribute. > > However, I would advise you _not_ to use an attribute type without an > explicitly specified equality rule in a search filter. I have added the nsMatchingRule to our config, and upon re-index our searches work now. Thanks for this tip. That's a good piece of advice. I will also investigate our schemas and such that lack an equality rule, and I will see if they violate this. - -- Sincerely, William Brown -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUi13FAAoJEO/EFteBqAmaet8P+wez3dhlD0lAg9ZfsSFnQ4f0 Lxe7/mjl1/S39RQf8+9n4g6gXyWhTxgbgzhr1L9YKOPFs/8cnUgTaZ4ca27Ob2Rz pc8slWPV4QKEtgvtnC+m1mI0itKkQx9BnZChD2P7WpVS8QrBaCuni/OoCMVzJ8bM dmlt8xdAsXCPI/+DHFUMgMF5kDv3EzhdeOL5ONZkDpa2nOoYxO4n0FyEYdP1NIsw uiecTRy3+eMHSw9CWf2TgcYBmTCKWwLrXzJOMI5bqBLeA7XNY/in3AkrOgWu3AZc GYeVLuRsek5AiTQgxUYu57mg+u3BfwyK4YJHQi0I82XTM2mk3k3uS5LJlcW15G2L zRMj4TwJ7P8eFCeARmNVN7n9wbQiRTZrL89Ea5Qghd5aEGbTCt9g85PDoYDUonHn t4Vs5EMBrWuzzRuTrrDojFJ+NkK6ILQMCZ2Ub/x7lJ5Oimt1blXBhDslvTG3HzMR vInhmX9KHGuN8hAeQLX6xWZhBXLCOPXPwz9Pi2IB13Y+nwdDf0sfEJkgPLkdtNmG b6YCPMVwW/fehKvAi+0rKbwev40PtMUUbtBaj2LU0QYKf1WnWXOdnt2HupSOpX3o oKIIxOb2o4Q8erN6OW+KuzUAoyIlEie6gQwrFkCEinhA0ktfd5XXq09NZpjV09JS smU5IShdPA68wiRBTvZW =0M8O -----END PGP SIGNATURE----- -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
