Nightly test failure in IPA server installation #5332
Comments
|
FYI, we also discuss this regression in Fedora: https://bodhi.fedoraproject.org/updates/FEDORA-2022-e9c10b569e This is definitely a huge regression for us as it breaks all client code out there in all distributions. A mere check for whether this is IPA server is not working anymore. |
|
@Firstyear |
|
Okay. That means there are new and improved filter logs. We need those to diagnose this. |
|
The second thing to raise here is that @mreynolds389 confirmed that these patches passed with freeipa, so how was this missed in ipa's testing, and now causing "an issue via bodhi". |
|
@Firstyear I don't believe @mreynolds389 tested the same thing against IPA. It is clearly breaking our nightly tests when using 389-ds nightly build. I think what @mreynolds389 talks about is https://pagure.io/freeipa/issue/9153 (389-ds issue #5289), which is different from this use case. |
|
@Firstyear the tests were executed using this build: https://copr.fedorainfracloud.org/coprs/g/389ds/389-ds-base-nightly/build/4460276/ |
|
@Firstyear I have provided logs to Mark at the bodhi update. Here is the same log pasted, this is a diff for |
|
I am looking into this to find a simple reproducer. Now IPA does have an aci that already allowed "info": aci: (targetfilter="(objectclass=domain)")(targetattr="objectclass || dc || info ACI code shows that access was granted to both subtree/base searches, but "test_fitler_access" is returning -1 for the base search which is blocking the entry from being returned. So it is ACI related, but I'm not sure how yet. |
|
I still can not reproduce the issue outside of IPA but this is an interesting observation. An exact filter works with base search, but a substring search does not: Still investigating... |
|
Update: The problem is that with base search we are not normalizing the filter in the pblock. We normalize the filter in the search result set, but not in the pblock, and the pblock filter is what is used in ldbm_back_next_search_entry(). Instead we use the "intended filter" which was not normalized. To reproduce: On the root node entry set "info" which has a CIS syntax (so case should not matter, but as you'll see it will): Then we try this search which should work but it does not: Change the case of the filter attribute value to lowercase and it works: The second search works because in the code we have marked the filter as normalized, but in fact it is not. So by using the lower case value it does find the entry because we did the normalization ourselves. So filter normalization is not happening correctly on base searches. |
When is the normalising step occuring? Can you point me to the line of code? Or will you just do a PR? (I can't really look today :( ) |
|
So the problems happens in ldbm_search.c:1760 With substring searches the "filter_intent" has been normalized, but for base searches it has not (but the "filter" variable in this function is normalized). at line 1469 we have: So above we flag the filter as normalized in the pblock and the local variable "filter" is set to the normalized filter, but we use "filter_intent" when calling "slapi_vattr_filter_test()" which in the base search case is not normalized. Notice that sf_initial's case "IPA" vs "ipa": I "think" the issue might be that for substring searches we modify the filter to include objectclass=referral, and I think that's were we normalize the filter in the pblock (not sure on that though). I'll try to continue to look into this today, but I will be out most of Thursday and Friday... |
|
Here is a hack fix :-) |
|
I would rather fix in in build_candidate_list in the LDAP_SCOPE_BASE case ... |
I tried it but it doesn't help. Based on your recommendation I revised my "fix" which is a little cleaner, but it still feels like a hack |
Bug Description: Due to a mistake in the optimiser rework the filter as intended was not normalised, causing some searches to fail Fix Description: Always normalise both filters. fixes: 389ds#5332 Author: William Brown <william@blackhats.net.au> Review by: ???
|
I think there is a better fix: I also want a test case for this, but I have another bug from a SUSE customer to deal with RN. :( |
|
Testcase: |
Bug Description: Due to a mistake in the optimiser rework the filter as intended was not normalised, causing some searches to fail Fix Description: Always normalise both filters. fixes: 389ds#5332 Author: William Brown <william@blackhats.net.au> Review by: mreynolds (Thanks!) Signed-off-by: Mark Reynolds <mreynolds@redhat.com>
Bug Description: Due to a mistake in the optimiser rework the filter as intended was not normalised, causing some searches to fail Fix Description: Always normalise both filters. fixes: #5332 Author: William Brown <william@blackhats.net.au> Review by: mreynolds (Thanks!) Signed-off-by: Mark Reynolds <mreynolds@redhat.com>
Bug Description: Due to a mistake in the optimiser rework the filter as intended was not normalised, causing some searches to fail Fix Description: Always normalise both filters. fixes: #5332 Author: William Brown <william@blackhats.net.au> Review by: mreynolds (Thanks!) Signed-off-by: Mark Reynolds <mreynolds@redhat.com>
Bug Description: Due to a mistake in the optimiser rework the filter as intended was not normalised, causing some searches to fail Fix Description: Always normalise both filters. fixes: #5332 Author: William Brown <william@blackhats.net.au> Review by: mreynolds (Thanks!) Signed-off-by: Mark Reynolds <mreynolds@redhat.com>
Doesn't build with glibc 2.39. There's a potential fix documented in 389ds/389-ds-base#5332, but the package is too old for the patch to apply, so I'll mark it as broken for now and leave it to the maintainer to update & fix.
Doesn't build with glibc 2.39. There's a potential fix documented in 389ds/389-ds-base#5332, but the package is too old for the patch to apply, so I'll mark it as broken for now and leave it to the maintainer to update & fix.
The IPA tests using the nightly build of 389-ds (from the copr repo @389ds/389-ds-base-nightly) are failing during IPA server installation, in the discovery phase of ipa-client-install. See for instance PR #1764 with the folllowing test:
automember(Report, logs):Investigations
The code is doing the equivalent of the following LDAP command to check if the server is an IPA server:
and the command doesn't find any entry. Note that without the
-s baseoption, the entry is properly returned:Installed packages: 389-ds-base-2.2.1-202206031947git9763e161e.fc36.x86_64
Companion issue logged against IPA: https://pagure.io/freeipa/issue/9170
The text was updated successfully, but these errors were encountered: