#4858 ipa-server-install crashed on certmonger having duplicate requests
Closed: wontfix 5 years ago Opened 9 years ago by mkosek.

ipa-server-install still crashes when there are some leftovers from previous uninstallation:

# ipa-server-install
...
  [16/27]: enabling CRL and OCSP extensions for certificates
  [17/27]: setting audit signing renewal to 2 years
  [18/27]: configuring certificate server to start on boot
  [19/27]: restarting certificate server
  [20/27]: requesting RA certificate from CA
  [21/27]: issuing RA agent certificate
  [22/27]: adding RA agent as a trusted user
  [23/27]: configure certmonger for renewals
  [24/27]: configure certificate renewals
  [25/27]: configure RA certificate renewal
  [26/27]: configure Server-Cert certificate renewal
  [27/27]: Configure HTTP to proxy connections
Done configuring certificate server (pki-tomcatd).
Configuring directory server (dirsrv): Estimated time 10 seconds
  [1/3]: configuring ssl for ds instance
  [error] DBusException: org.fedorahosted.certmonger.duplicate: Certificate at same location is already used by request with nickname "20150114035631".
Unexpected error - see /var/log/ipaserver-install.log for details:
DBusException: org.fedorahosted.certmonger.duplicate: Certificate at same location is already used by request with nickname "20150114035631".

# ipa-getcert list
Number of certificates and requests being tracked: 7.
Request ID '20150114035631':
    status: MONITORING
    stuck: no
    key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-MKOSEK-F21-TEST',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-MKOSEK-F21-TEST/pwdfile.txt'
    certificate: type=NSSDB,location='/etc/dirsrv/slapd-MKOSEK-F21-TEST',nickname='Server-Cert',token='NSS Certificate DB'
    CA: IPA
    issuer: CN=Certificate Authority,O=MKOSEK-F21.TEST
    subject: CN=ipa.mkosek-f21.test,O=MKOSEK-F21.TEST
    expires: 2017-01-14 03:56:30 UTC
    key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
    eku: id-kp-serverAuth,id-kp-clientAuth
    pre-save command: 
    post-save command: 
    track: yes
    auto-renew: yes

It would be better to either fix it on the fly (and delete this request) or shout early before running this installation phase.


Reproducer for my case:

  • Install server
  • Stop DS instance
  • rm -rf /etc/dirsrv/slapd-*/ /var/lib/dirsrv/s*
  • Uninstall server
  • Install server again

Is it safe to assume that the conflicting request is an orphan from previous broken (un)installation? If yes, such request can be removed and recreated without further concerns.

I tend to be cautious when it comes to automatically removing any data.

We know what the certmonger requests look like. Is it overkill to test for the early on in the installer and quit of they exist?

We can check, complain and quit. But if the request is created by someone else (user, other service) then the LBYL approach won't work because the request can be created between the check and the attempt to create it by installer.

Usually these certificates are generated under control of freeipa and so are the tracking requests but I'm not sure if this is the only scenario.

I am not worried too much for someone creating the request between check and the failing step, this is corner case. Check in the beginning of the installation + maybe even fixing DS uninstall to remove the tracker would be fine.

Processing 4.2 backlog. This ticket was found as something that is not a priority for the nearest releases.

But as usual, please feel free to discuss your use cases or contribute patches, to make that happen sooner!

Metadata Update from @mkosek:
- Issue assigned to someone
- Issue set to the milestone: Future Releases

7 years ago

Thank you taking time to submit this request for FreeIPA. Unfortunately this bug was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfil this request I am closing the issue as wontfix. To request re-consideration of this decision please reopen this issue and provide additional technical details about its importance to you.

Metadata Update from @rcritten:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

5 years ago

Login to comment on this ticket.

Metadata