Comments

35 Comments

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.

@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

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.