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:
> During the discussion, we came to an interesting question:
> What would break if loopback addresses were allowed for IPA
> 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. 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: 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
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.
Senior Principal Software Engineer, Identity Management Engineering, Red Hat
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code