[Freeipa-devel] [PATCH 0365] Remove unused KRA code from ipa-server-install

[Alexander Bokovoy]

On Mon, 14 Dec 2015, David Kupka wrote:
>On 14/12/15 15:05, Alexander Bokovoy wrote:
>>On Mon, 14 Dec 2015, David Kupka wrote:
>>>On 30/11/15 16:31, Martin Basti wrote:
>>>>First instance of KRA should be installed only by ipa-kra-install
>>>>
>>>>Patch attached.
>>>>
>>>>
>>>>
>>>>
>>>Hi,
>>>patch works, but I don't like the approach.
>>>
>>>Do we really want to remove '--setup-kra' option from ipa-server-install?
>>>Why do we remove '--setup-kra' while keeping '--setup-dns'? Why do we
>>>keep installing PKI CA when it can be also installed later?
>>Yes, we do want. Adding the option was an error in the first place. This
>>patch fixes the error.
>>
>>>I would love if 'ipa-server-install' installed only the bare minimum
>>>needed and then other features was added using ipa-{feature}-install
>>>but also I don't mind one almighty installer that can install all
>>>possible combinations of features.
>>>But this is neither of it. This just brings another inconsistency into
>>>FreeIPA behavior.
>>We don't have --with-adtrust either. And we don't want it.
>>
>Ok, then are we aiming for 'ipa-server-install' that only installs the 
>bare minimum and everything else should be installed later?
>
>Or, do we decide per feature if it's appropriate to include it in 
>'ipa-server-install'? What are the criteria in this case?
Per feature decision is a bit better description of an ad-hoc process we
have so far.

As we had this discussion with Simo today, let me quickly capture
arguments for both. We typically allow options in ipa-server-install for
features that can be present and used very early. Certificates are
issued early in the process, DNS records are critical to exist before
hosts can be added and can start using Kerberos and so on. However,
trust to AD cannot be established to 'just deployed' FreeIPA realm, you
need to pre-configure your and that remote realm.

Certificates were in particular important part of the story before we
added support for GSSAPI authentication between replicas (4.3 release is
going to have it). This meant we were constrained by the fact that some
entity had to issue certificates before we even create a replica.

I was arguing that having KRA would require us to have full fledged CA
as we depend on ability to issue certificates for KRA feature to be
useful as well. While standard CA is somewhat optional in the case only
end-point service certs are needed (Let's Encrypt is a solution there),
having KRA means use of some CA. So to me having KRA means we have CA
already, why not to simply merge the two setting into --setup-ca at all?

Separate installers also were used in past as a gap-bridging tool to
allow people to upgrade their old deployments and gain new
functionality. So separate installer has another function than just
deploying a service.

Having --with-kra option thus makes less sense. We can consider KRA
functionality to be in a default feature set at some point, that would
still require us to have a separate installer, ipa-kra-install, to allow
extending old deployments to provide new feature.

-- 
/ Alexander Bokovoy