@abbra is there an aci that allows "search" access to the attribute "info"?
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):
[03/Jun/2022:18:03:11.934907329 -0400] conn=14 op=3 SRCH base="cn=dns,dc=test,dc=openqa,dc=fedoraproject,dc=org" scope=2 filter="(|(objectClass=idnsZone)(objectClass=idnsSecKey)(objectClass=ipk11PublicKey))" attrs=ALL
[03/Jun/2022:18:03:11.952468921 -0400] conn=14 op=3 RESULT err=0 tag=121 nentries=0 wtime=0.000511034 optime=0.017565393 etime=0.018072245
Regression in UI
This update has been unpushed.
@adamwill yes someone is looking into DogTag as we speak . I expect to see an update by the end of the week
Yeah, it is the same issue, but it's a CVE fix that is causing the problem. Can't exactly back it out, but we can wait for DogTag to fix it (should be a simple fix for them).
This update has been unpushed.
This update has been unpushed.
This update has been unpushed.
I am going to be doing a completely fresh build. We have found other regressions in 1.4.2.6. These are all fixed now, so I'm just going to do a 1.4.2.7 build. Thanks for testing the patches you applied though!!!
I wasn't able to backport the patch because pagure wasn't letting anyone do anything over git (ssh). There are other regressions in this build. https://bugzilla.redhat.com/show_bug.cgi?id=1791342
I don't think this build should have been pushed to stable :-/
Yeah I just fixed it, doesn't look like this commit was even manually tested, errrr! Anyway need to do new builds now...
Nevermind, I think I found the problem. Working on a new build
Any chance you can grab the /etc/dirsrv/slapd-YOUR_INSTANCE/dse.ldif file from that system? The failure is occurring when parsing this file.
This update has been unpushed.
This build has a known regression, Issue 50620
It's definitely crashing, and I think I know which issue it might be but we do need a core file to verify. Ideally if you could get us the stack trace from the system after the crash that would be easier: Attach gdb to core file and run "thread apply all bt full". Or, attach gdb to ns-slapd before the test is run and catch the crash live (then run "thread apply all bt full")
This update has been unpushed.
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.