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

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

Reply via email to