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

[David Kupka]

On 14/12/15 16:54, Alexander Bokovoy wrote:
> 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.
>

The fact that the DNS records need to exist for some (core) IPA 
functionality does not necessary mean that we need DNS server installed 
as a part of FreeIPA. We even support DNS-less install and user is then 
responsible for maintaining DNS records in server of his choice.
IOW 'ipa-server-install --setup-dns' results in the same as 
'ipa-server-install && ipa-dns-install'.
In case of trust, would it be really impossible to preconfigure the 
remote realm and then provide all necessary information to 
'ipa-server-install --setup-trust'? Or is it just the way we're doing it 
right now for some maybe really good reason?
So the only reason to add the '--setup-<feature>' or '--with-<feature>' 
to ipa-server-install I can see is user comfort and ease of 
installation. That's good reason for me but in that case I still do not 
understand why do not include options that can be easily included.
-- 
David Kupka