On Mon, 2013-02-04 at 17:39 -0800, Matthew Harmsen wrote:
On 02/01/13 11:54, Ade Lee wrote:
We want to use the admin interface for installation work. This patch moves the interfaces used in cloning from either the EE or agent interface to the admin one. See: http://pki.fedoraproject.org/wiki/8.1_installer_work_for_cloning
Specifically, 1. Change call to use /ca/admin/ca/getCertChain 2. Remove unneeded getTokenInfo servlet. The logic not to use this servlet has already been committed to dogtag 10. 3. Move updateNumberRange to the admin interface. For backward compatibility with old instances, the install code will call /ca/agent/updateNumberRange as a fallback. 4. Add updateDomainXML to admin interface. For backward compatibility, updateDomainXML will continue to be exposed on the agent interface with agent client auth. 5. Changed pkidestroy to get an install token and use the admin interface to update the security domain. For backward compatibility, the user and password and not specified as mandatory arguments - although we want to do that in future.
Please review, Ade
_______________________________________________ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel Alee,
Sorry, but I require some additional information to properly test this patch for a CA and its clone using a single machine. Hopefully, I can address these issues relatively quickly tomorrow after obtaining your answers.
I have pulled a new tree after the meeting this morning (which does not include the patches added at 3:49 P. M. by edewata), created a branch, applied all five of your changes, and built and installed the packages on a fresh x86_64 Fedora 18 system (e. g. - 'foobar.example.com').
In order to test the code, I would like to perform the following two tests using a single machine: 1. pkispawn using the new configuration servlet for both the CA and the CA Clone 2. pkispawn using the old GUI configuration (by specifying a DEFAULT value of pki_skip_configuration=True) for both CA and the CA Clone However, with the new interpolation model, I do not know every single value that needs to be overridden to have both the CA and CA Clone, as well as the two directory servers, on the same system.
I have the following: * installed a default directory server instance (e. g. - foobar) running on port 389 * installed a CA (e. g. - default configuration specifying backup keys in order to create the CA clone): [DEFAULT] pki_admin_password=XXXXXXXX pki_backup_password=XXXXXXXX pki_client_pkcs12_password=XXXXXXXX pki_ds_password=XXXXXXXX pki_security_domain_password=XXXXXXXX pki_backup_keys=True * successfully configured a browser, requested, enrolled, and issued a test certificate * installed a second directory server instance (e. g. - foobar-clone) running on port 8389 * about to install a CA Clone using the following parameters: [DEFAULT] pki_admin_password=XXXXXXXX pki_client_pkcs12_password=XXXXXXXX pki_ds_password=XXXXXXXX pki_security_domain_password=XXXXXXXX pki_security_domain_hostname=foobar.example.com pki_security_domain_https_port=8443 pki_ds_ldap_port=8389 pki_ds_ldaps_port=8636 [CA] pki_ajp_port=17009 pki_clone=True pki_clone_pkcs12_password=XXXXXXXX pki_clone_pkcs12_path=/etc/pki/pki-tomcat/alias/ca_backup_keys.p12 pki_clone_replicate_schema=True pki_clone_replication_master_port= pki_clone_replication_clone_port= pki_clone_replication_security=None pki_clone_uri=http://foobar.example.com:8443 pki_http_port=17080 pki_https_port=17443 pki_instance_name=pki-tomcat-ca-clone pki_tomcat_server_port=17005 Questions: * Are the two tests specified above sufficient to test your patch, or do I need to check the other two test cases of mixing an old GUI configuration (CA) with new configuration servlet (CA clone), and vice-versa? (I believe that this code will require re-testing under a separated ports model for versions of the product earlier than Dogtag 10). * What parameter(s) do I need to add to the CA Clone configuration file under what sections to reference the 'foobar-clone' directory instance? * What value, if any, do I need to supply to the 'pki_clone_replication_master_port'? * What value, if any, do I need to supply to the 'pki_clone_replication_clone_port'? * Should I leave 'pki_clone_replication_security=None'? * Are there any other parameters that I am missing, and if so, under what section should they be defined? * Are there any parameters specified that contain incorrect values? * Are any parameters specified in the incorrect sections? Thanks in advance, -- Matt
Matt, Here is the configuration I have for a master CA and a clone. Master: [DEFAULT] pki_admin_password=XXXXXX pki_backup_password=XXXXXX pki_client_pkcs12_password=XXXXXX pki_ds_password=XXXXXX pki_security_domain_password=XXXXXX pki_ds_ldap_port=55389 pki_ds_ldaps_port=55636 pki_security_domain_https_port=8623 pki_http_port=8620 pki_https_port=8623 pki_instance_name=pki-tomcat62 pki_client_database_purge=True [Tomcat] pki_ajp_port=8629 pki_tomcat_server_port=8625 Clone: [DEFAULT] pki_admin_password=XXXXXX pki_backup_password=XXXXXX pki_client_pkcs12_password=XXXXXX pki_ds_password=XXXXXX pki_security_domain_password=XXXXXX pki_ds_ldap_port=7489 pki_ds_ldaps_port=7436 pki_security_domain_hostname=alee-workpc.redhat.com pki_security_domain_https_port=8623 pki_http_port=8650 pki_https_port=8653 pki_instance_name=pki-tomcat65 pki_client_database_purge=True pki_security_domain_user=caadmin [Tomcat] pki_ajp_port=8659 pki_tomcat_server_port=8655 [CA] pki_clone=True pki_clone_pkcs12_password=XXXXXX pki_clone_pkcs12_path=/tmp/pki-tomcat62.p12 pki_clone_uri=https://alee-workpc.redhat.com:8623 pki_ds_base_dn=o=pki-tomcat62-CA pki_ds_database=pki-tomcat62-CA [KRA] pki_clone=True pki_clone_pkcs12_password=XXXXXX pki_clone_pkcs12_path=/tmp/pki-tomcat62.p12 pki_clone_uri=https://alee-workpc.redhat.com:8623 pki_ds_base_dn=o=pki-tomcat62-KRA pki_ds_database=pki-tomcat62-KRA These are the only parameters you absolutely need. With these configs, I did the following: 1. Installed a CA and a KRA in the master. 2. Installed a CA clone. 3. Installed a KRA clone. (or tried to .. There are issues in installing a KRA clone that are independent of this patch and for which I will be opening a ticket). Also, please make sure that syntax-checking is disabled in your DS. There is an issue in storing the security domain token on the master if syntax checking is enabled. I will open a ticket. To completely test, you really need to do all the steps above. I did step 3 as far as it went until it failed - but it was clear that the patch was working correctly. In addition, I also performed the above steps in the case where the master CA/KRA was an older instance - ie prior to this patch. In this case, I was testing the "fallback" options. Note that because the changes require config file changes (to web.xml) and a migration script has not yet been written, older instances that are running on newer PKI software will not expose the new servlets. So, they will act like old instances. Ade The