This seems to break openQA server deployment. After the server part proper is complete, when the server gets deployed as a client of itself, it seems to not believe the system is an IPA server:
Nothing obviously wrong in DS logs, but I suspect maybe its related to search filter changes. I do see this in the last search in the DS access log (which returns nothing, but I don;t know if it should):
It fails the ACL check for info=IPA* -- we probably need to add one more ACL here. Last time filter optimisations were added to 389-ds, we had to allow anonymous access to parentId attribute. This one works, so we actually get to analyze the entry and info attribute but the substring filter check fails:
Need aci logging enabled for more info. I'm trying to get a beaker box (which keeps aborting errr) so I can reproduce it with IPA, as I can not reproduce this outside of IPA.
This update has been submitted for testing by mreynolds.
This update's test gating status has been changed to 'ignored'.
This seems to break openQA server deployment. After the server part proper is complete, when the server gets deployed as a client of itself, it seems to not believe the system is an IPA server:
https://openqa.fedoraproject.org/tests/1288772#step/role_deploy_domain_controller/31
Logs are here.
This update has been obsoleted.
Nothing obviously wrong in DS logs, but I suspect maybe its related to search filter changes. I do see this in the last search in the DS access log (which returns nothing, but I don;t know if it should):
It fails the ACL check for
info=IPA*
-- we probably need to add one more ACL here. Last time filter optimisations were added to 389-ds, we had to allow anonymous access toparentId
attribute. This one works, so we actually get to analyze the entry andinfo
attribute but the substring filter check fails:info
attribute is using caseIgnoreSubstringMatch:Not sure why it fails to match "IPA*" to "IPA V2.0"...
Note that this happens with base search as opposed to subtree search. subtree search succeeds, base search fails. Easily reproducible.
@abbra is there an aci that allows "search" access to the attribute "info"?
There is no such ACI. I tried to add one and it did not help at all for the base-level search:
Logs show the same problem:
Need aci logging enabled for more info. I'm trying to get a beaker box (which keeps aborting errr) so I can reproduce it with IPA, as I can not reproduce this outside of IPA.
Here is what happens with base search of
info=IPA*
:actually, only the last two lines:
Here is combined log for ACI and filter logging: