FreeIPA: on a replica, ipa ca-del subca fails with @pki/master repo #4669
Comments
|
@flo-renaud I am trying to reproduce this error using latest version from copr and two containers but I get no error. The setup is very similar but the dns is not configure. I tried to add dns configuration but get some problems with docker. Could you verify if the problem is still present and/or the dns is relevant to get the error? Thanks |
|
@fmarco76 yes the problem is still present. I did a setup similar to yours (no dns server setup) and the issue is still here. Did you also setup the CA role on the clone? |
I tried with and without the ca role with similar results. I'll do a new setup and playing with the parameter to get the error. I would be sure the error is still present before performing additional tests. |
|
OK @flo-renaud , after several tests I have found how to reproduce the error. The replica is generated differently in the clone workflow. I'll work on this. Thanks |
fmarco76
added a commit
to fmarco76/pki
that referenced
this issue
Feb 21, 2024
The tracking update allows to avoid reloading an authority if no changes have been done to the record. To verify the changes it is used the LDAP attribute `entryUSN` which is updated by DS server on any change. The tracker update mechanism has a race condition when an entry is modified by the `CAEngine`. When the method `modifyAuthorityEntry()` is invoked, this will update the tracker and no CA are reloaded by the `AuthorityMonitor` thread because the tracker is already to the newest value. However, in case of CA clones, when a sub CA is created in the primary CA, the clone will get the record but there is no serial. The CA is registered and when the related keys are retrieved the record is update with the serial. The update is done by the `modifyAuthorityEntry()` which will update the trackers. As a result the `AuthorityMonitor` will not update the CA object and when used it will miss the serial so some operations will fails. Since, the `trackerUpdate` method has not other impact has been removed so all trackers are managed by the `AuthorityMonitor`. Fix dogtagpki#4669
fmarco76
added a commit
that referenced
this issue
Feb 21, 2024
The tracking update allows to avoid reloading an authority if no changes have been done to the record. To verify the changes it is used the LDAP attribute `entryUSN` which is updated by DS server on any change. The tracker update mechanism has a race condition when an entry is modified by the `CAEngine`. When the method `modifyAuthorityEntry()` is invoked, this will update the tracker and no CA are reloaded by the `AuthorityMonitor` thread because the tracker is already to the newest value. However, in case of CA clones, when a sub CA is created in the primary CA, the clone will get the record but there is no serial. The CA is registered and when the related keys are retrieved the record is update with the serial. The update is done by the `modifyAuthorityEntry()` which will update the trackers. As a result the `AuthorityMonitor` will not update the CA object and when used it will miss the serial so some operations will fails. Since, the `trackerUpdate` method has not other impact has been removed so all trackers are managed by the `AuthorityMonitor`. Fix #4669
|
Hi @fmarco76 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The following issue happens when installing pki from @pki/master repository.
Scenario: install a server + replica with CA service, create a subca on the server, disable the subca on the replica and delete the subca on the replica. The command
ipa ca-delfails withipa: ERROR: Request failed with status 500: Non-2xx response from CA REST API: 500.Reproducer:
On the server:
On the replica:
Create a sub ca on the server:
Disable and delete the sub ca on the replica:
The last command fails.
The replica logs show that PKI is trying to find a subca with a dn cn=null,ou=certificateRepository,ou=ca,o=ipaca:
Version: dogtag-pki-ca-11.5.0-0.4.alpha7.20240214145232UTC.a064ebe7.fc39.noarch
The text was updated successfully, but these errors were encountered: