[Freeipa-devel] What would break if loopback addresses were allowed for IPA server?

[Simo Sorce]

On Mon, 2016-10-17 at 09:02 +0200, Petr Spacek wrote:
> On 27.9.2016 14:31, Jan Pazdziora wrote:
> > On Wed, Sep 21, 2016 at 12:01:44PM +0200, Jan Pazdziora wrote:
> >>
> >> I've recently hit again the situation of IPA installer not happy
> >> about the provided IP address not being local to it, this time in
> >> containerized environment:
> >>
> >> 	https://bugzilla.redhat.com/show_bug.cgi?id=1377973
> >>
> >> During the discussion, we came to an interesting question:
> >>
> >> 	What would break if loopback addresses were allowed for IPA
> >> 	server?
> >>
> >> Of course, the idea is that it would only be used for installation and
> >> then IPA would change its IP address in DNS to whatever is the real IP
> >> address under which it is accessible.
> >>
> >> Where does the allow_loopback=False requirement in the installer come
> >> from and what would break if it was removed altogether?
> > 
> > I also see messages like
> > 
> > 	Adding [10.11.12.13 ipa.example.com] to your /etc/hosts file
> > 
> > in some cases. Actually, it's
> > 
> > 	10.11.12.13 ipa.example.com ipa
> > 
> > which gets added so the message is not accurate.
> > 
> > Modification of /etc/hosts itself seems unfortunate. Should the IP
> > address change in the future, there will be one more place where
> > the IP address stays hardcoded.
> > 
> > I wonder why
> > 
> > 	hosts:      files dns myhostname
> > 
> > isn't enough, and whether
> > 
> > 	hosts:      files myhostname dns
> > 
> > might actually be better order.
> 
> Theoretically yes. Practically it will break Dogtag and other components which
> are not able to cope up with link-local addresses returned from myhostname module.
> 
> 
> > When the value is not in /etc/hosts,
> > I see weird startup issues, presumably because individual components
> > time out resolving $HOSTNAME, so systemctl start ipa fails. Perhaps
> > it has something to do with named being up at that point, rather than
> > unreachable, just not resolving anything yet. Chicken and egg.
> > 
> > I wonder why we cannot add ipa.example.com to 127.0.0.1. I've tried
> > that and have seen
> > 
> > 	named-pkcs11[453]: LDAP error: Local error: SASL(-1): generic
> > 	failure: GSSAPI Error: Unspecified GSS failure.  Minor code
> > 	may provide more information (Server
> > 	ldap/localhost at EXAMPLE.TEST not found in Kerberos database):
> > 	bind to LDAP server failed
> > 
> > which suggests something derives the hostname and thus the principal
> > from the IP address used. Why is not $HOSTNAME used everywhere? What
> > part of the system cares about the IP address (and the reverse
> > resolution)?
> 
> AFAIK FQDN is used everywhere. The "localhost" name might be coming from
> Kerberos name canonicalization, which works like this:
> FQDN (name resolution) record-> IP address (IP address resolution)->new name.
> 
> You might try to add rdns=false to [libdefaults] section in /etc/krb5.conf. It
> should be default anyway, but why not try it explicitly.
> 
> Also, I would try if dns_canonicalize_hostname=false makes any difference or not.

Btw this attribute came up also elsewhere, I think we should consider
changing ipa-client-install (or SSSD) to make
dns_canonicalize_hostname=false the default in IPa installs.

Should we open a ticket for that?

Simo.

> 
> > If overloading 127.0.0.1 with the $HOSTNAME does not work, could
> > 127.0.0.2 do the trick? It seems to work for subsequent starts (did
> > not try it during ipa-server-install) in containers.
> 
> It will likely suffer with very similar problems. It if works, it works just
> accidentally and might break at any time in future.
> 
> Before we touch IP address/domain name logic, we need to agree how it should
> behave.
> 
> What is the purpose of --ip-address option?
> a) Specify IP addresses used in DNS.
> ab) What checks should be performed on it?
> b) To bind deamons only to specific IP addresses instead of all interfaces?
> 
> I have seen requests for both. We need to decide what is the intended behavior
> and design it before making further changes. The spaghetti code is too
> intertwined for making any non-systematic changes.
> 
> -- 
> Petr^2 Spacek
> 


-- 
Simo Sorce * Red Hat, Inc * New York