11:23 p.m.
On Wed, 2013-01-09 at 09:12 +0700, Endi Sukma Dewata wrote:
On 1/9/2013 3:25 AM, Ade Lee wrote:
> 1. What does python -u do?
We're using different ways to display the messages: python/jython print,
python logging, jython javasystem.out. Apparently each of them has
separate buffer so the messages would not appear in the proper order
unless we disable buffering using -u.
OK
>> 1. We ought to have some code to ensure that only one invocation of
>> pkispawn or pkidestroy is running at a time. This is important for
>> selinux. Maybe this is a separate ticket.
I opened this ticket:
https://fedorahosted.org/pki/ticket/470
>> 2. We should prompt for passwords twice and confirm that the passwords
>> match (as they are not displayed).
Agreed, the initial patch was meant to provide the basic functionality.
I'm planning to add verifications & error checking in a follow up patch.
However, we should only do password verification for passwords that we
create. In this case we'll do it for the admin password only.
For DS we're only using an existing password, so I don't think we should
verify it. The DS password was created and verified during DS
installation. I believe the PKI UI also doesn't require DS password
verification.
Same thing for security domain password, the password is already
verified when we create the security domain itself. When we create KRA
we're only using the password.
The password verification is mostly for sanity checking purposes. It is
possible that the password that is entered for the DS password is
mis-typed. Having ham-fisted fingers, I tend to do that. As the
password is not displayed, its unclear until you actually start the
installation whether the password was mis-typed. On the other hand, you
are unlikely to mistype a password twice.
So, I think it should be done for all passwords.
>> 3. After all inputs are entered, it would be good to output
something
>> like "Starting installation ...". It would also be good to print out
>> the choices made, and allow them to go back and change them by typing
>> "back" - just like DS does.
OK, will add in follow up. If you type "back" you'd need to re-enter
everything, is that ok?
Yes - and I understand, re-enter everything meaning that you have to go
through the prompts again.
>> 4. Man page for pkispawn and pkidestroy needs to be updated.
Similarly
>> for pkispawn -h.
OK. For the help page (-h) the -f option should be made optional (the -s
option is already fixed). Any other changes to the help page?
Thats probably fine.
For the man page I opened this ticket:
https://fedorahosted.org/pki/ticket/471
Ok - I am interested in how this is documented. In particular, we want
to be careful to explain exactly what type of installation is available
using the interactive install. I would suggest writing this first - so
that we can decide if we agree on this - and if the options need to
change accordingly.
>> 5. For subsystem type - entering something incorrect - like
RAT for
>> example, causes an unsightly traceback.
Will do the error checking in follow up.
OK
>> 6. When installing a KRA, you are prompted for a security
domain admin
>> certificate --why?
I think the prompt is wrong, it should have been "Import admin
certificate" instead of "Security domain certificate".
The default pki_admin_cert_file for KRA would point to the CA admin cert
in KRA's client dir. This will not work if the CA and KRA are installed
on different instances. By prompting for the cert, it will allow you to
enter the CA admin cert in the CA's client dir. If they are installed in
the same instances you can just accept the default value.
What's actually the difference between pki_admin_cert_file and
pki_client_admin_cert, is one for import and the other for export? Do
they contain the same certificate?
>> 7. When installing KRA (and OCSP and TKS), you need to be prompted for
>> connection info to two CA's -- the security domain CA, and the issuing
>> CA. These need not be the same.
What are the parameters for the issuing CA? Do you have an example?
How common is it to have different CA's for the security domain and
issuing CA? Note that in the interactive mode we can limit ourselves to
support the most common scenarios only.
This goes back to my statements about the man page. We need to decide
exactly what we are supporting in the interactive install.
I think its reasonable for the CA to be not the same as the security
domain CA.
>> 8. How do you handle the admin cert ie. whether to create a
new admin or
>> reuse the cert of an old admin? I suspect this is related to question 6
>> above.
The default pki_import_admin_cert for non-CA subsystems is True. So
right now it only supports reusing the old admin cert, that's why in #6
you're asked for the cert. I'll fix the logic to use pki_import_admin_cert.
There are several ways to handle this:
a) Add another prompt asking whether to create or reuse the admin cert.
b) Don't support that in the interactive mode. You'd have to use a
config file.
Which one would you suggest?
I like option (a) -- and if the choice is to reuse an
admin cert, prompt
for its location.
>> 9. It would be nice if the interactive script wrong out a config file
>> (maybe with passwords XXX'ed out) after the install.
The user config file will be stored in the registry with the passwords
intact just like in the non-interactive mode. Is this sufficient?
Yes.