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

[Petr Spacek]

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.


> 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