On 14.12.2015 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.

patch works, but I don't like the approach.

Do we really want to remove '--setup-kra' option from
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?

Because KRA is a separate component that does something completely different than a CA and is configured separately even in Dogtag. The logic here is exactly the reverse - if you want to install KRA, you have to install (Dogtag) CA, not the other way around, so merging both into --setup-ca does not make sense.

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.

We can always have both. With the new installer framework it is trivial to fold installers like this without code duplication. It is still work in progress though, so I would prefer not to add --setup-kra to ipa-server-install now (if ever).

Jan Cholasta

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to