On Tue, 15 Dec 2015, David Kupka wrote:
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'.
It means we require DNS is there -- be it internal or as external
service provided by something else. There is no DNS-less install in
reality, something has to provide SRV records, you cannot have FreeIPA
deployment without DNS at all for some use cases -- for example, trust
to AD requires DNS infrastructure to exist.

The difference we have for DNS and CA/KRA is that we cannot work with
any other CA for all certificate types yet and KRA is simply not
supporting anything but Dogtag CA on the same IPA master, so --setup-kra
is implying --setup-ca, and thus could be simply merged into --setup-ca
once we decide KRA functionality is stable enough to be part of default
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?
It is always possible to merge functionality into a single installer but
I'm not sure we'll gain anything reasonable from it in this particular
case. Configuring trust is about two things: (a) setup software on IPA
master, and (b) create a number of special objects in both IPA and
Active Directory. To do (a) you can merge things into the installer but
to do (b) you need to perform operations on AD side and which operations
you would perform depends on what other choices you did when installed
IPA -- if you did not install internal DNS, you would need to create a
number of SRV records for IPA DNS zone first somewhere, then gain AD
admin credentials and perform trust-add somehow, whether directly or by
splitting the procedure into two different steps (shared secret case).
It means at some point such an installer would need to stop and wait
until someone else would complete required actions outside the scope of
IPA realm.

As I said, per-feature decisions are what drives our ad-hoc process. :)

--
/ Alexander Bokovoy

--
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