Comments
rcritten
@dsoumis can you take a look?
Initial testing look better. It is raising a 404 error as expected but unless we also pass application/json with the Accept header we get xml-based error responses. We didn't have to pass this in in the past, though it's more correct to do so.
I tested a single server upgrade from current IPA reeipa-server-4.12.2-15 and python3-dogtag-pki-11.6.0-0.3.alpha1 to the bits in the side tag successfully. This included testing creating, archiving and retriving from a kra vault. I then uninstalled IPA on the server and did a fresh install along with the same set of tests.
I did the build targeting the side tag but it hasn't been added yet.
Working for me.
Simple smoke test with IPA CA + KRA and looks good.
Tested that no VLV errors are reported from the IPA certificate tests. All tests passed in multiple runs. Prior to this failures were 100% reproducible.
Works for me.
Works for me.
Working for me.
Tested server, replica, DNS and KRA installations.
Tested server, replica, DNS and KRA installations.
Works for me. I also tested revocation and pwpolicy
Tested with ipa server and it worked fine
This is causing IPA CI to fail. I'm not completely sure why. The behavior we see is that the current principal is cifs/<fqdn> when we expect it to be something else.
The AVC we see is:
type=AVC msg=audit(1657297049.999:3709): avc: denied { sendto } for pid=13209 comm="smbcontrol" path="/var/lib/samba/private/msg.sock/13151" scontext=unconfined_u:unconfined_r:smbcontrol_t:s0-s0:c0.c1023 tcontext=system_u:system_r:winbind_rpcd_t:s0 tclass=unix_dgram_socket permissive=0
That is fine with me.