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/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? 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 -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code