On 20 September 2017 at 15:54, Alexander Bokovoy <abokovoy(a)redhat.com>
wrote:
Ok. By the look of this commit (to 4.5):
>
>
https://pagure.io/freeipa/c/bdf9a34dffdf4d7925208e5df9f69e3927b88858
>
> 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.
>
I'm a bit tired to repeat this multiple times but FreeIPA does require
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.
Alex,
Thanks for the comprehensive reply and explanation. I don't know that I've
seen it written quite that way - until now I was under the impression that
it was a nice to have and preferred, rather than a strict requirement.
I'll need to go through our stack to see why we couldn't have ipv6 turned
on and try to solve that issue.
cheers
L.