The 'pkispawn' and 'pkidestroy' executables are deployment utilities associated with a PKI administrator.
Consequently, it was recently determined that we should allow an administrator the ability to remotely configure (but never remotely install or destroy) a PKI instance.
Since we have recently decided to remove the legacy GUI browser configuration interface, remote configuration now requires the use of the 'pkispawn' utility.
As 'pkispawn' is currently packaged in the 'pki-server' package, it would be more appropriate to separate this utility along with its closely associated 'pkidestroy' utility into their own package ('pki-deploy').
Although the 'pki-deploy' package will have no dependency on any other client or server PKI package, the 'pki-server' package will include a dependency upon the 'pki-deploy' package such that it is always included on the server.
I'd suggest the package to be called pki-admin as it may include other administrative tools in the future. This package may depend on pki-base/tools if it's using the PKI client library/CLI to communicate with the server.
The current pkispawn and pkidestroy contain both installation and configuration code. The installation code actually makes more sense to stay in the pki-server package since it's dealing with the server files directly. In the future it might be possible to split the tools as follows and package them in the corresponding RPMs:
Replying to [comment:3 edewata]:
Changing title from 'pki-deploy' to 'pki-admin'.
The current pkispawn and pkidestroy contain both installation and configuration code. The installation code actually makes more sense to stay in the pki-server package since it's dealing with the server files directly. In the future it might be possible to split the tools as follows and package them in the corresponding RPMs: pki-server <install|uninstall> <instance name> pki-admin <configure|unconfigure> <server URL>
This would most likely entail a complete redesign and re-factoring of the existing code, documentation, and integration with other products, and will probably not occur in any of the Dogtag 10.2 timeframes.
Although a patch was originally generated which addressed this issue, it has been NACKed in favor of the following alternative approach:
* To prevent any disruption to existing products which integrate it, the 'pkispawn' executable will remain the CLI utilized to install and configure a PKI instance but will only consist of the portion which gathers all of the information for an instance and creates the master Python dictionary; additionally, 'pkispawn' will now always perform the generation of the client Admin keys and produce a CSR for the Admin certificate. Since the 'pkispawn' executable will now be allowed to be run remotely, it will no longer be contained within the 'pki-server' package. However, it will probably need to package the '/etc/pki/default.cfg' file.
* The 'pkideploy' executable will always have all of its data obtained from the 'pkispawn' executable, and will be responsible for exercising the appropriate 'scriptlets'. Although the 'pkideploy' executable will remain a part of the 'pki-server' package, since it is not intended to be a directly executed program, it will therefore be located under the '/usr/libexec' directory, and will always run with 'root' privilege.
If 'pkispawn' is run on the server, it will gather its information, generate the Admin Certificate Keys and produce a CSR, and send all of this data to the 'pkideploy' executable in order to install and configure a PKI instance. This will be the default case.
Similarly, if 'pkispawn' is run remotely as a client (after the server-side admin has first setup remote access for the client-side admin), it will gather its information, generate Admin Certificate Keys and produce a CSR, prompt for access to the server, and relay this information to the 'pkideploy' executable on the server side. We may want to include something like a "--remote" switch to distinguish whether configuration is on the local host or on a remote host.
In either case, we may simply perform an 'ssh' with the appropriate options to have 'pkispawn' invoke 'pkideploy' with the appropriate data as arguments.
Note that the Admin Certificate keys will always be generated on the machine which invokes the 'pkispawn' executable.
This also implies that there will no longer be the notion of an installed PKI instance that has not been configured, so the 'pki_skip_installation' and 'pki_skip_configuration' options and their associated code will need to be removed.
One question (at least) remains - since the 'pkispawn' executable and '/etc/pki/default.cfg' are no longer part of the 'pki-server' package, should they be: (a) included in a new 'pki-admin' package, or
(b) simply added to the 'pki-tools' package?
In either case, the package which contains it will be a dependency of the 'pki-server' package.
After discussions on IRC, it was determined with input from vakwetu and nkinder, that we would utilize the 'pki-tools' package for the decoupled 'pkispawn', and so this ticket has become superfluous. The design in comment #6 above has been moved to PKI TRAC Ticket #1119 - Allow 'pkispawn' to remotely configure a PKI instance.
Metadata Update from @mharmsen: - Issue assigned to mharmsen - Issue set to the milestone: 10.2 - 08/14 (August)
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/1681
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.
Login to comment on this ticket.