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(a)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_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