[Pki-devel] [PATCH] 199 Added interactive subsystem installation.
Ade Lee
alee at redhat.com
Wed Jan 9 05:23:08 UTC 2013
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.
More information about the Pki-devel
mailing list