[Pki-devel] [PATCH] 199 Added interactive subsystem installation.

[Ade Lee]

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.