[Pki-devel] [PATCH] PKI Deployment Framework PKI TRAC issues (07/28/2012)
Ade Lee
alee at redhat.com
Mon Jul 30 18:02:16 UTC 2012
Comments inline.
On Sat, 2012-07-28 at 22:40 -0700, Matthew Harmsen wrote:
> This patch documents continued implementation of the PKI Deployment
> Framework based upon the revised filesystem layout documented here:
> * http://pki.fedoraproject.org/wiki/PKI_Instance_Deployment#CA_.2F_KRA_.2F_OCSP_.2F_RA_.2F_TKS_.2F_TPS
> This patch addresses the following issues:
> * TRAC Ticket #263 - Dogtag 10: Fix 'pkidestroy' problem of
> sporadically "not" removing
> "/etc/sysconfig/{pki_instance_id}" . . .
> * TRAC Ticket #264 - Dogtag 10: Enable various other subsystems
> for configuration . . .
> * TRAC Ticket #261 - Dogtag 10: Revisit command-line options of
> 'pkispawn' and 'pkidestroy' . . .
> * TRAC Ticket #268 - Dogtag 10: Create a parameter for optional
> restart of configured PKI instance . . .
> * TRAC Ticket #270 - Dogtag 10: Add missing parameters to
> 'pkideployment.cfg' . . .
> * TRAC Ticket #265 - Dogtag 10: Provide configurable options for
> PKI client information . . .
> * TRAC Ticket #275 - Dogtag 10: Add debug information (comments)
> to Tomcat 7 "logging.properties"
> * TRAC Ticket #276 - Dogtag 10: Relocate all 'pin' data to the
> 'sensitive' dictionary
> * TRAC Ticket #277 - Dogtag 10: Create an 'archive' for
> 'manifest' and 'pkideployment.cfg' files
>
> WARNING: Due to some of the changes to the command-line parameters
> (mainly the introduction of a dependency on the existence of a new
> symlink), instances previously created with the old "pkispawn" will
> once again need to be removed by the old "pkidestroy" PRIOR to the
> installation of this patch.
>
> Note: You will definitely need to establish the following "passwords"
> in your copy of "pkideployment.cfg" in order to install a "CA":
>
>
> * pki_admin_password
> * pki_client_pkcs12_password
> * pki_ds_password
> * pki_security_domain_password
> I ran the following command: pkispawn -s CA
> -f /tmp/pki/pkideployment.cfg -vvv
>
> Unfortunately, for me, out-of-the-box installation failed with
> the following problem:
> * pkispawn : ERROR ....... port 8080 has invalid
> selinux context http_cache_port_t
> This error occurred despite downloading the latest SELinux
> policies on my 64-bit Fedora 17 box and compiling
> 'pki-selinux' against them.
>
> The work-around that I used was to edit
> "/usr/lib/python2.7/site-packages/pki/deployment/initialization.py" and comment out the call to "util.configuration_file.verify_selinux_ports()" in the 'spawn()' method.
>
> Re-running the command 'pkispawn -s CA
> -f /tmp/pki/pkideployment.cfg -vvv' now produces the following
> error:
> pkispawn : INFO ... populating
> 'pki.deployment.selinux_setup'
> Traceback (most recent call last):
> File "/bin/pkispawn", line 225, in <module>
> main(sys.argv)
> File "/bin/pkispawn", line 212, in main
> rv = instance.spawn()
> File
> "/usr/lib/python2.7/site-packages/pki/deployment/selinux_setup.py", line 69, in spawn
> port1.add(port, "tcp", "s0",
> config.PKI_PORT_SELINUX_CONTEXT)
> File
> "/usr/lib64/python2.7/site-packages/seobject.py", line
> 1045, in add
> self.__add(port, proto, serange, type)
> File
> "/usr/lib64/python2.7/site-packages/seobject.py", line
> 1002, in __add
> raise ValueError(_("Port %s/%s already defined") %
> (proto, port))
> ValueError: Port tcp/8080 already defined
> My work-around to fix to this error is to remove the symlinks
> which call the 'selinux_setup.py' scriptlet for both
> 'pkispawn' and 'pkidestroy':
> * rm /usr/share/pki/deployment/spawn/*/035_selinux_setup
> * rm /usr/share/pki/deployment/destroy/*/985_selinux_setup
> Unfortunately, at this stage, sufficient installation has been
> made which prevents a new installation, and 'pkidestroy' in
> its current incarnation
> will be unable to completely remove the instance. Therefore,
> presuming an instance name of 'pki-tomcat', run the following
> commands:
> * rm -rf /var/lib/pki
> * rm -rf /etc/pki/pki-tomcat/
> * rm -rf /etc/sysconfig/pki
> * rm -rf /var/log/pki
> * rm /etc/sysconfig/pki-tomcat (this command will fail,
> as it has not yet been created)
> Re-running the command 'pkispawn -s CA
> -f /tmp/pki/pkideployment.cfg -vvv'should now run to
> successful completion!
>
I expected this problem to surface because until now, I had not figured
out how to address the selinux definition of the ports. Until now, we
have defined our own port types (pki_ca_port_t) and the like, but the
standard ports used by tomcat are already defined as http_port_t and
mxi_port_t and http_cache_port_t.
The answer to this is simply, following dwalsh's suggestion, to just use
the defined port types (http_port_t etc.) In fact, when we rewrite the
policy to use a tomcat domain, the permissions to use such ports will be
defined already by the tomcat domain.
For migration purposes, we will define type aliases for the old
pki_*_port_t types.
The upshot of all this is that a new pki-selinux patch is needed. You
can work around this by making a copy of the config file and changing
the ports to use non-standard ports for now.
> To test this patch, run the test instructions documented in
> earlier patches for installing the Admin Cert.
> Note that the 'ca_admin_cert.p12' file is now located under
> '/var/lib/pki/{pki-instance-id}/conf/alias/ca_admin_cert.p12',
> and since a browser may not
> have the appropriate permissions to traverse past the
> '/var/lib/pki' directory, the administrator will need to make
> this file available (i. e. - copy it to /tmp).
>
I was a little surprised at the usage of pki_client_pkcs12_path as a
directory, rather than the location of the file itself. I do like the
fact that you put it under alias with the name ca_admin_cert.p12,
clearly showing which subsystem it belongs to.
I ended up preferring to use that default location instead and just
copying out that file to the right place for me. I think most people
would do that too to avoid the permissions issues - and so I think we
should remove that option and just put it under alias.
Similarly, there is an option of where to put the backup file. To avoid
permissions issues, someone would either have to create a directory with
the right selinux and file permissions - or use something like /tmp. A
better option would be to put the file into the alias directory and have
the user copy it out from there.
So I think we should probably remove the backup file location option
too. I also don't think we need to name the file according to the type
of installation (clone vs. subordinate vs. external). A simple name
including the subsystem is sufficient. Its also not needed to add a
timestamp - because of where it is -- in the alias directory -- we know
which subsystem its associated with. This is also important because we
need to know the filename ahead of time to be able to copy it out.
> Please note, that although KRA, OCSP, and TKS installations
> will run to completion, at the present time, a crash occurs in
> the invocation of the java configuration
> client (quite possibly due to the specification of
> incorrect/incomplete parameters for these subsystems).
>
Ok -we should look into this post-alpha.
Other comments:
1. I'm not sure I understand the check. According to this, if token
name is empty, then you need a token password? Is an empty token name
default to internal?
if not len(master['pki_token_name']) or\
not master['pki_token_name'] == "internal":
if not sensitive.has_key('pki_token_password') or\
not len(sensitive['pki_token_password']):
config.pki_log.error(
log.PKIHELPER_UNDEFINED_CONFIGURATION_FILE_ENTRY_2,
"pki_token_password",
master['pki_deployment_cfg'],
extra=config.PKI_INDENTATION_LEVEL_2)
sys.exit(1)
2. In pkiparser, we can simplify the code that specifies
pki_client_admin_cert_p12 by setting {subsystem}_admin_cert.p12, rather
than a series of conditionals based on subsystem type.
> Thanks,
> -- Matt
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
More information about the Pki-devel
mailing list