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 [ ipa.example.com] to your /etc/hosts file
>>> in some cases. Actually, it's
>>> 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 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/localh...@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 with the $HOSTNAME does not work, could
>>> 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

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

Reply via email to