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

[Ade Lee]

ACK
On Thu, 2013-01-31 at 11:29 -0600, Endi Sukma Dewata wrote:
> New patch attached.
> 
> On 1/8/2013 11:23 PM, Ade Lee wrote:
> > 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.
> 
> This has been added.
> 
> >>>> 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.
> 
> A confirmation prompt has been added. I don't think it's necessary to 
> print out the choices again because most likely you can still see them 
> on the screen.
> 
> > 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.
> 
> The doc is available here:
> http://pki.fedoraproject.org/wiki/Interactive_Installation
> 
> >>>> 5. For subsystem type - entering something incorrect - like RAT for
> >>>> example, causes an unsightly traceback.
> >>
> >> Will do the error checking in follow up.
> >>
> > OK
> 
> Error checking has been added.
> 
> >>>> 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.
> 
> As discussed, since the interactive installation doesn't support clone 
> or subordinate CA, the issuing CA will be identical to the security 
> domain, so it's not necessary to prompt for the issuing CA separately.
> 
> >>>> 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.
> 
> Prompts for importing and exporting admin certificates have been added.
>