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

[Petr Spacek]

On 17.10.2016 17:55, Simo Sorce wrote:
> 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?

I would leave it for Jan so we know that it has desired effect in his setup.

Petr^2 Spacek

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