Re: [Freeipa-devel] What would break if loopback addresses were allowed for IPA server?
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/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 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
Re: [Freeipa-devel] What would break if loopback addresses were allowed for IPA server?
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
Re: [Freeipa-devel] What would break if loopback addresses were allowed for IPA server?
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. > 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
Re: [Freeipa-devel] What would break if loopback addresses were allowed for IPA server?
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. 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)? 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. -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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
Re: [Freeipa-devel] What would break if loopback addresses were allowed for IPA server?
On 21.09.2016 12:01, Jan Pazdziora wrote: Hello, 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? Thanks, I'm not aware of anything that should prevent us to have just loopback address (installation without DNS) on server. It is somehow weird to not have any other address unicast address assigned, but cloud world strikes. IIRC in past there might be issue with some services (KDC? not sure) that cannot run only with loopback address, but I dont think that this is an issue nowadays. This needs investigation, please file a ticket and we may allocate human and time for this :) Martin^2 -- 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
[Freeipa-devel] What would break if loopback addresses were allowed for IPA server?
Hello, 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? Thanks, -- Jan Pazdziora Senior Principal Software Engineer, Identity Management Engineering, Red Hat -- 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
