As of now due to some error, we only support cloning two OCSP servers. Of course we want to support an arbitrary number of clones for this feature to be truly useful.
The theory on the problem has to do with replica id's of the various clones. The CA and KRA make use of a framework designed to maintain replica id ranges, in order to avoid such collisions.
The fix will likely be to implement the replica ranges for the OCSP as done in the CA and KRA.
A related ticket was found first that will be closing: Ticket #1358
During work on a ticket to diagnose an issue with creating a clone of an OCSP using pkispawn, this problem was discovered as follows:
Create the master ca and ocsp on a host. On the same host create a clone of the ocsp after creating another directory server instance to hold the data for all the clones. This failed due to another ticket as described. Used pkidestroy to dispose of the aborted ocsp clone instance attempt. Re-ran the same pkispawn test, using the exact same install cfg file to re-attempt the clone with the exact same parameters.
This operation failed earlier than the previous test due to a different case. This time it failed because the cloned OCSP's debug log is reporting a problem with negotiating the various replication agreement steps.
Took a quick shot at this by updating the OCSP's config to have the replica id range settings included. More info on the problem:
This did not work due to the fact that there is some code in the java configuration classes that is checking to see if the subsystem is a kra or ca before processing those entries. The code checks for a kra or ca and then does a block where it updates the replica id range AND the serial number AND request range.
This is skipped for OCSP since I"m not sure the OCSP even has any of this data.
I think the replica id stuff will have to be retrofitted to OCSP for this to work. This will take more investigation to best determine a course of action..
Per PKI Bug Council of 06/23/2016: 10.4
Metadata Update from @jmagne: - Issue set to the milestone: UNTRIAGED
Metadata Update from @mharmsen: - Custom field feature adjusted to '' - Custom field proposedmilestone adjusted to '' - Custom field proposedpriority adjusted to '' - Custom field reviewer adjusted to '' - Custom field version adjusted to '' - Issue close_status updated to: None - Issue set to the milestone: 10.4 (was: UNTRIAGED)
Per CS/DS Meeting of August 7, 2017, it was determined to move this issue from 10.4 ==> FUTURE.
Metadata Update from @mharmsen: - Issue set to the milestone: FUTURE (was: 10.4)
Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.
This issue has been cloned to GitHub and is available here: https://github.com/dogtagpki/pki/issues/2026
If you want to receive further updates on the issue, please navigate to the GitHub issue and click on Subscribe button.
Subscribe
Thank you for understanding, and we apologize for any inconvenience.
Metadata Update from @dmoluguw: - Issue close_status updated to: migrated - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.