#1196 serverCertNick.conf is replaced when second subsystem is installed.
Closed: Fixed Opened by vakwetu.

It is possible to specify a different nickname than the default for the server cert,
This nickname is stored in the serverCertNick.conf file to be read by jss on startup. Whe pkispawn is invoked to create this system, serverCertNick.conf is created and the correct nickname is inserted.

If you invoke pkispawn to add another subsystem (say a kra) to an existing instance, then the serverertNick.conf file will be overwritten again. If you do not specify the modified nickname in your config file, then a default nick will be written, and when the server is restarted, SSL connections will fail.

Subsequent invocations of pkispawn should not rewrite the serverCertNick.conf file in an existing instance.

Suggested milestone 10.2.1


Based upon CS/DS meeting of 11/10/2014: 10.2.1

This ticket seems to be a subset of ticket #664. There are probably other shared files being overwritten during additional subsystem installations, but the problem with serverCertNick.conf may need to be fixed sooner.

After discussion with vakwetu on 12/12/2014, it was determined that this ticket could be moved to 10.2.2.

Per 10.2.2 Triage meeting of 02/24/2015: 10.2.3

Contents of PKI TRAC Ticket #664 - pkispawn overwrites files when adding subsystem to existing instance was merged into this ticket:

When adding a new subsystem into an existing instance pkispawn will regenerate Tomcat configuration files such as serverCertNick.conf and server.xml. So if there are subsystem-specific settings in those files they will get replaced by the settings of the new subsystem.

For example the serverCertNick.conf on a CA may initially contain the following value:

Server-Cert cert-pki-ca

When KRA is added to the same instance it could change to this:

Server-Cert cert-pki-kra

One possible solution is to not regenerate Tomcat configuration files. This means the contents of those files are controlled by the first subsystem and if the second subsystem defines a different value it will get ignored, which may be confusing to the admin.

Another solution is to verify that the second subsystem does not define different values for the parameters that will go into Tomcat configuration files. Otherwise, the installation should fail.

Another possible solution is to split Tomcat configuration from subsystem configuration into separate deployment files. When adding a new subsystem to an existing instance only the subsystem configuration is required so the admin will not accidentally change the Tomcat configuration.

commit 34d7a671cf9d884135bf50f89f5f420ce697d1b4
Author: Ade Lee alee@redhat.com
Date: Wed Apr 29 11:11:41 2015 -0400

Trac Ticket 1196 - serverCertNick.conf is replaced incorrectly
When second subsystem is installed, serverCertNick.conf and other top level
tomcat config files should not be replaced.

Metadata Update from @vakwetu:
- Issue assigned to vakwetu
- Issue set to the milestone: 10.2.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/1758

If you want to receive further updates on the issue, please navigate to the
GitHub issue and click on Subscribe button.

Thank you for understanding, and we apologize for any inconvenience.

Metadata