-----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....
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-----