On 20 September 2017 at 15:54, Alexander Bokovoy <abokovoy@redhat.com> wrote:I'm a bit tired to repeat this multiple times but FreeIPA does requireOk. By the look of this commit (to 4.5):
https://pagure.io/freeipa/c/bdf9a34dffdf4d7925208e5df9f69e39 27b88858
from this issue https://pagure.io/freeipa/issue/7083
It is (or was) the IPv6 problem.
We have an
[root@linuxidm ~]# cat /etc/sysctl.d/ipv6.conf
# Disable IPv6
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.ens160.disable_ipv6 = 1
We don't have the 'lo' interface defined in there, but it's never been an
issue.
The /etc/hosts entry for ::1 must have thrown ipa-server-upgrade.
IPv6 stack to be enabled in the kernel. We absolutely do. If you don't
use IPv6 stack, disable it on specific interfaces. However, there is a
practical problem with the way how glibc DNS resolver works: in default
configuration it always prefers IPv6 answers to IPv4 because this is
actually a policy of RFC3484. As result, if you have ::1 in /etc/hosts,
it will be returned first. If you don't have ::1 on any of your
interfaces ('lo' is a typical one), then apps cannot contact ::1
(localhost) even if those apps that use IPv6 bind to all interfaces.
FreeIPA uses modern APIs provided by glibc to listen on both IPv6 and
IPv4. It simply means that FreeIPA servers bind to IPv6 addresses (on
all interfaces or on a specific one, if needed) and treat IPv4 as mapped
ones because IPv6 and IPv4 share the same port space on the same
machine. This works transparently thanks to glibc and is a recommended
way to write networking applications. See man ipv6(7) for details.
Here is how it looks on a real system, for TCP listeners:
# netstat -nltp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 13361/named-pkcs11 tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 13760/smbd tcp 0 0 0.0.0.0:49152 0.0.0.0:* LISTEN 13765/smbd tcp 0 0 0.0.0.0:135 0.0.0.0:* LISTEN 13763/smbd tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 13760/smbd tcp 0 0 0.0.0.0:749 0.0.0.0:* LISTEN 13351/kadmind tcp 0 0 0.0.0.0:464 0.0.0.0:* LISTEN 13351/kadmind tcp 0 0 192.168.100.233:53 0.0.0.0:* LISTEN 13361/named-pkcs11 tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 13361/named-pkcs11 tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 2838/sshd tcp 0 0 0.0.0.0:88 0.0.0.0:* LISTEN 13345/krb5kdc tcp6 0 0 ::1:953 :::* LISTEN 13361/named-pkcs11 tcp6 0 0 :::8443 :::* LISTEN 13603/java tcp6 0 0 :::443 :::* LISTEN 13379/httpd tcp6 0 0 :::636 :::* LISTEN 13296/ns-slapd tcp6 0 0 :::445 :::* LISTEN 13760/smbd tcp6 0 0 :::49152 :::* LISTEN 13765/smbd tcp6 0 0 :::9090 :::* LISTEN 1/systemd tcp6 0 0 127.0.0.1:8005 :::* LISTEN 13603/java tcp6 0 0 :::389 :::* LISTEN 13296/ns-slapd tcp6 0 0 :::135 :::* LISTEN 13763/smbd tcp6 0 0 127.0.0.1:8009 :::* LISTEN 13603/java tcp6 0 0 :::139 :::* LISTEN 13760/smbd tcp6 0 0 :::749 :::* LISTEN 13351/kadmind tcp6 0 0 :::8080 :::* LISTEN 13603/java tcp6 0 0 :::80 :::* LISTEN 13379/httpd tcp6 0 0 :::464 :::* LISTEN 13351/kadmind tcp6 0 0 :::53 :::* LISTEN 13361/named-pkcs11 tcp6 0 0 :::22 :::* LISTEN 2838/sshd tcp6 0 0 :::88 :::* LISTEN 13345/krb5kdc
Notice that many ports are only available as tcp6 listeners? Like 636
(LDAPS), 389 (LDAP), 80 (HTTP), 443 (HTTPS) and so on? This is an effect
of using v6 API that supports v4-mapped-on-v6 addresses. It makes the
code less complex and handles with the same code both IPv6 and IPv4.