[Pki-devel] Proposed solution for the "pkideployment.cfg" template file . . .

Everyone, It has been brought to my attention (and rightly so) that the 'pkideployment.cfg' file required by the 'pkispawn' executable is confusing to use. One suggestion was simply to rename the file from 'pkideployment.cfg' to something like 'pkideployment.cfg.template' to denote that this is actually a template, and not an actual final configuration file, and rely solely upon a well-written man page (see TRAC Ticket #227 - Dogtag 10: Document 'pkideployment.cfg <https://fedorahosted.org/pki/ticket/227>') which is not slated to be finished until the final phase of the Dogtag 10 release. Not everyone likes this suggestion. Another suggestion was to create separate template files for all the various "flavors"/"configurations", but I am not in favor of this approach as it leads to a problem of keeping too much identical information in sync across the various template files. A slight alternative to this would be to create separate sectional files that are pasted together to create a single configuration file (which in my opinion is way too complicated for what should be a relatively simple configuration file). Therefore, I would like to suggest another alternative -- rather than creating one or more "static" templates, I would like to suggest the creation of a simple python script which generates a configuration file suitable for the user's subsystem choice. For example, this simple script could be used to generate a suitable configuration file which could easily be edited by an end-user to produce a 'pkideployment.cfg' configuration file to any one of the following: * CA * KRA * OCSP * TKS * RA * TPS * CA Clone * KRA Clone * OCSP Clone * TKS Clone * External CA (stage 1) * External CA (stage 2) * Subordinate CA 'TRAC Ticket #227 - Dogtag 10: Document 'pkideployment.cfg <https://fedorahosted.org/pki/ticket/227>' will still be utilized to provide details on what all of the various name/value pairs are used for (along with both their resident default values as well as the computed default values of keys which are purposefully left unassigned), as well as provide detailed examples. Please fill free to comment in response to this email and suggest any other alternatives. If the alternative that I suggest here is approved of, I am willing to writeup a brief design document for such a 'pkispawn pkideployment.cfg' configuration file generator. -- Matt