Proposed solution for the "pkideployment.cfg" template file . . .
by Matthew Harmsen
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
12 years, 6 months
adding subsequent OCSPs
by Andrew Wnuk
This patch corrects process of attaching OCSP subsystem to CA.
It improves handling of adding subsequent OCSP subsystems to CA.
Bugs: 804179 and 804176.
12 years, 6 months
[PATCH] 45 - Change selinux context for legacy instances
by Ade Lee
In the new selinux policy, pki_ca_t etc. are all replaced by
pki_tomcat_t. To allow old instances to work under dogtag 10, the
context in the run scripts needs to change.
Also added a rule needed by selinux policy.
12 years, 6 months