The test case is: Create an entry like:
dn: uid=new_account1,dc=example,dc=com cn: new_account1 gidNumber: 222 homeDirectory: /home/mYhOmEdIrEcToRy <<< this the the value with upper cases objectClass: top objectClass: posixAccount uid: new_account1 uidNumber: 111
Index 'homedirectroy' with caseExactIA5Match/caseIgnoreIA5Match Matching Rule
It will create the index keys like:
:caseExactIA5Match:/home/myhomedirectory (note the index key contains a lower case tag) :caseIgnoreIA5Match:/home/myhomedirectory =/home/mYhOmEdIrEcToRy
The the entry can not be retrieved with:
ldapsearch -LLL -D "cn=directory manager" -w password -b "uid=new_account1,dc=example,dc=com" "(homeDirectory=/home/mYhOmEdIrEcToRy)" ldapsearch -LLL -D "cn=directory manager" -w password -b "dc=example,dc=com" "(homeDirectory:caseIgnoreIA5Match:=/home/mYhOmEdIrEcToRy)" ldapsearch -LLL -D "cn=directory manager" -w password -b "dc=example,dc=com" "(homeDirectory:caseIgnoreIA5Match:=/home/MYhomeDIRECTORY)"
but not with
ldapsearch -LLL -D "cn=directory manager" -w password -b "dc=example,dc=com" "(homeDirectory:caseExactIA5Match:=/home/mYhOmEdIrEcToRy)"
With caseExactIA5Match MR in the filter, the search is indexed. But the 'filter:"(homeDirectory:caseExactIA5Match:=/home/mYhOmEdIrEcToRy)"' does not exist in the index (it is stored as ':caseExactIA5Match:/home/myhomedirectory' With the 'filter:"(homeDirectory:caseExactIA5Match:=/home/myhomedirectory)"' the key exists in the index (candidate_list=1), but then does not match the filter evaluation when returning the entry.
Note a base search returns the entry:
ldapsearch -LLL -D "cn=directory manager" -w password -s base -b "uid=new_account1,dc=example,dc=com" "(homeDirectory:caseExactIA5Match:=/home/mYhOmEdIrEcToRy)"
CI testcase to be attached
attachment ticket48745_test.py
This bug has a different symptom as https://fedorahosted.org/389/ticket/48746 but the fix, involving the same part of code, was fixed in https://fedorahosted.org/389/ticket/48746#comment:6.
The test case of both bugs is different, but the test case for 48745 was also committed with 48746.
This bug is closed as duplicate of 48746
The bug fix https://fedorahosted.org/389/ticket/48746 introduced a regression that is fixed with https://fedorahosted.org/389/ticket/48844.
The fix of 48844 does not fix 48745, so I am reopening it.
attachment 0002-Ticket-48745-Matching-Rule-caseExactIA5Match-indexes.patch
ds/dirsrvtests/tests/tickets/ticket48362_test.py:273: SyntaxWarning: name 'installation1_prefix' is assigned to before global declaration global installation1_prefix
Some thing like this should fix it:
{{{ --- a/dirsrvtests/tests/tickets/ticket48362_test.py +++ b/dirsrvtests/tests/tickets/ticket48362_test.py @@ -14,9 +14,6 @@ from lib389.utils import * logging.getLogger(name).setLevel(logging.DEBUG) log = logging.getLogger(name)
- PEOPLE_OU='people' PEOPLE_DN = "ou=%s,%s" % (PEOPLE_OU, SUFFIX) MAX_ACCOUNTS=5 @@ -36,14 +33,9 @@ class TopologyReplication(object):
@pytest.fixture(scope="module") def topology(request): - global installation1_prefix - if installation1_prefix: - args_instance[SER_DEPLOYED_DIR] = installation1_prefix
# Creating master 1... master1 = DirSrv(verbose=False)
args_instance[SER_DEPLOYED_DIR] = installation1_prefix args_instance[SER_HOST] = HOST_MASTER_1 args_instance[SER_PORT] = PORT_MASTER_1 args_instance[SER_SERVERID_PROP] = SERVERID_MASTER_1 @@ -59,8 +51,6 @@ def topology(request):
# Creating master 2... master2 = DirSrv(verbose=False) - if installation1_prefix: - args_instance[SER_DEPLOYED_DIR] = installation1_prefix args_instance[SER_HOST] = HOST_MASTER_2 args_instance[SER_PORT] = PORT_MASTER_2 args_instance[SER_SERVERID_PROP] = SERVERID_MASTER_2
}}}
Otherwise, looks good, the tests pass for me, and it builds correctly, so I'm happy to ack this.
Thanks William for the review. I did update ticket48632_test.py.
'''git push origin master''' Counting objects: 11, done. Delta compression using up to 8 threads. Compressing objects: 100% (11/11), done. Writing objects: 100% (11/11), 1.71 KiB | 0 bytes/s, done. Total 11 (delta 9), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git 7ebc170..d975431 master -> master
commit d975431 Author: Thierry Bordaz tbordaz@redhat.com Date: Fri May 20 11:49:29 2016 +0200
Description: Fixing a minor coverity defect introduced by #48745.
Defect type: REVERSE_INULL plugin_mr.c:671: check_after_deref: Null-checking "pi" suggests that it may be null, but it has already been dereferenced on all paths leading to the check. Moving the NULL check back to the original position.
Pushed to master: 43d5ac6..a0b8f46 master -> master commit a0b8f46
Thierry, the milestone is 1.3.4.9. Do you think this fix is needed for F23? If not, can we reset it to 1.3.5.x? Thanks!
Hi Noriko,
Several fixes were done in MR plugin code. All these fixes rely on https://fedorahosted.org/389/ticket/48270 These fixes were: https://fedorahosted.org/389/ticket/48497 https://fedorahosted.org/389/ticket/48745 https://fedorahosted.org/389/ticket/48746 https://fedorahosted.org/389/ticket/48844
48270 is fixed in 1.3.5.1. So I agree that the milestone for this ticket should be > 1.3.5.1 Also I think that the milestone for 48497, 48745, 48746 should also be > 1.3.5.1, right ?
{{{ git log --oneline | egrep 'bump|48270|48497|48745|48746|48844' f4cfadb bump version to 1.3.5.5 d975431 Ticket 48745 Matching Rule caseExactIA5Match indexes incorrectly values with upper cases 7ebc170 Ticket 48844 Regression introduced in matching rules by DS 48746 962116b bump version to 1.3.5.4 6575db8 Ticket 48497 - uncomment pytest from CI test 0e4b061 bump version to 1.3.5.3 83d57ee bump version to 1.3.5.2 83f3f44 bump version to 1.3.5.1 dde5b62 Ticket 48746: Crash when indexing an attribute with a matching rule b9dd886 Ticket 48497 test case f230d32 ticket: 48497 extended search without MR indexed attribute prevents later indexing with that MR e033d4b Ticket 48270: test case 3752886 Ticket 48270: fail to index an attribute with a specific matching rule
Thanks for the clarification, Thierry. I'm happy about 1.3.5.x. My question is actually on 1.3.4.x. I wanted to make sure if you want to have this 48745 fix in 1.3.4.x branch or not.
I ran the same grep on the 389-ds-base-1.3.4 branch. Then I found 48497 and 48746. Do you think freeipa needs to have other fixes 48270, 48745 and 48844 in 389-ds-base-1.3.4.12? Please note that 1.3.4 is running on F23. Thanks! {{{ $ git log --oneline | egrep 'bump|48270|48497|48745|48746|48844' 7715ac1 bump version to 1.3.4.11 5233e61 bump version to 1.3.4.10 c6ebe12 Ticket 48497 - uncomment pytest from CI test 718bcf2 bump version to 1.3.4.9 cba64d1 Ticket 48746: Crash when indexing an attribute with a matching rule 70670f2 ticket: 48497 extended search without MR indexed attribute prevents later indexing with that MR }}}
Looking at 1.3.4:
Metadata Update from @tbordaz: - Issue assigned to tbordaz - Issue set to the milestone: 1.3.4.9
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/1805
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.