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/[email protected] 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 -- 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
