1:02 p.m.
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_...
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel