Bug 1377055

If IPv6 is disabled via sysctl instead of via kernel parameters then rpcbind entirely fails to start. This is because IPv6 is still active when systemd reads the configuration so the ListenStream value is not ignored.

The problem is very visible even for non-rpcbind related changes (E.g. RPM installations) to the system that trigger a reload systemd daemon.


$ date ; sudo rpm -e nrpe ; sudo yum install -e0 -d0 -y nrpe
Wed Dec 21 09:31:58 UTC 2016

$ tail -n5 /var/log/messages
Dec 21 09:32:01 li-lc-1443 systemd[1]: Binding to IPv6 address not available since kernel does not support IPv6.
Dec 21 09:32:01 li-lc-1443 systemd[1]: [/usr/lib/systemd/system/rpcbind.socket:6] Failed to parse address value, ignoring: [::]:111
Dec 21 09:32:01 li-lc-1443 yum[13790]: Installed: nrpe-2.15-7.el7.x86_64
Dec 21 09:32:01 li-lc-1443 systemd[1]: Started Flexible Branding Service.
Dec 21 09:32:01 li-lc-1443 systemd[1]: Starting Flexible Branding Service...

This is configuration problem, either disable ipv6 from kernel cmdline or rebuild initramdisk after you modify sysctl.conf.

With you reproducer, half of the boot is run with ipv6 enabled (until systemd-sysctl is run).

Please see: https://access.redhat.com/solutions/8709

As noted above, restarting the service will make the problem go away because, when the service is restarted, IPv6 will be disabled. However, if ipv6 is not disabled via initram or kernel params as documented by link in comment11, another solution exists:

create override file for the unit ("rpcbind.socket") which effectively removes the ipv6 listen directive. 

# sysctl -a |grep disable_ipv6
net.ipv6.conf.all.disable_ipv6 = 0
net.ipv6.conf.default.disable_ipv6 = 0
net.ipv6.conf.eth0.disable_ipv6 = 0
net.ipv6.conf.lo.disable_ipv6 = 0

# systemctl restart rpcbind.socket
# ss -t -l -n -p | grep 111
LISTEN     0      128          *:111                      *:*                   users:(("rpcbind",pid=27242,fd=5),("systemd",pid=1,fd=30))
LISTEN     0      128         :::111                     :::*                   users:(("rpcbind",pid=27242,fd=4),("systemd",pid=1,fd=29))

# n.b.  CREATE OVERRIDE FILE TO REMOVE IPV6 SOCK CONFIG
install -D -o root -m 0644 -g adm /dev/stdin /etc/systemd/system/rpcbind.socket.d/no-ipv6.conf << OVERRIDE
[Socket]
ListenStream=
ListenStream=0.0.0.0:111
ListenStream=/var/run/rpcbind.sock
OVERRIDE

# systemctl stop rpcbind.socket
# systemctl start rpcbind.socket
# # n.b. ^^ restart is not sufficient here
# ss -t -l -n -p | grep 111
LISTEN     0      128          *:111                      *:*                   users:(("systemd",pid=1,fd=27))

# sysctl -a |grep disable_ipv6
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.eth0.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
# systemctl stop rpcbind.socket
# systemctl start rpcbind.socket
# # n.b. ^^ just in case
# ss -t -l -n -p | grep 111# ss -t -l -n -p | grep 111
LISTEN     0      128          *:111                      *:*                   users:(("systemd",pid=1,fd=28))

# journalctl -p warning -S  -5m
-- No entries --

(hopefully)

(In reply to Otheus from comment #12)
> create override file for the unit ("rpcbind.socket") which effectively
> removes the ipv6 listen directive. 

That is what we've done (via Chef) but I consider it more of a workaround than a fix. I wasn't aware that the initramfs held the sysctl configuration though so I will consider that option.

I tried the workaround to create the sysctl entry and run dracut. But that did not work. I used the following sysctl.d file:

$ cat /etc/sysctl.d/97-ipv6.conf
# sysctl file to disable or enable ipv6
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

Does that workaround really need the sysctl.conf?  Because that is for me impossible as it will be forced to be empty by puppet.

@PeterVreman,

I don't have a direct answer to your question.

If puppet is managing sysctl.conf, why not configure puppet to set these values in the file? Or does the module /template you use for it place all settings in sysctl.d? 

By the way, since you manage it with puppet, consider adding a dependency which results in a 'dracut -f' run every time a sysctl file is modified.

Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.

There is nothing to fix, this is again a configuration problem. When you disable ipv6 in sysctl.conf, it does not mean that it is disabled from the moment when machine is started.

We should really educate our users here to set ipv6.disable=1 on kernel cmdline for this use-case.

Sorry, how can you propose a fix that triggers tons of SELinux errors?

After applying the recommendation of ipv6.disable=1 on the commandline i get selinux alerts like:

'''''''''''''
$ sudo sealert -l b3321326-0fe9-46f8-9b40-81cb4ff38279
SELinux is preventing /usr/sbin/chronyd from module_request access on the system Unknown.

*****  Plugin disable_ipv6 (53.1 confidence) suggests   **********************

If you want to disable IPV6 on this machine
Then you need to set /proc/sys/net/ipv6/conf/all/disable_ipv6 to 1 and do not blacklist the module'
Do
add
net.ipv6.conf.all.disable_ipv6 = 1
to /etc/sysctl.conf


*****  Plugin catchall_boolean (42.6 confidence) suggests   ******************

If you want to allow all domains to have the kernel load modules
Then you must tell SELinux about this by enabling the 'domain_kernel_load_modules' boolean.
You can read 'None' man page for more details.
Do
setsebool -P domain_kernel_load_modules 1

*****  Plugin catchall (5.76 confidence) suggests   **************************

If you believe that chronyd should be allowed module_request access on the Unknown system by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'chronyd' --raw | audit2allow -M my-chronyd
# semodule -i my-chronyd.pp


Additional Information:
Source Context                system_u:system_r:chronyd_t:s0
Target Context                system_u:system_r:kernel_t:s0
Target Objects                Unknown [ system ]
Source                        chronyd
Source Path                   /usr/sbin/chronyd
Port                          <Unknown>
Host                          li-lc-1793
Source RPM Packages           chrony-2.1.1-4.el7_3.x86_64
Target RPM Packages
Policy RPM                    selinux-policy-3.13.1-102.el7_3.15.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     li-lc-1793
Platform                      Linux li-lc-1793 3.10.0-514.10.2.el7.x86_64 #1 SMP
                              Mon Feb 20 02:37:52 EST 2017 x86_64 x86_64
Alert Count                   1
First Seen                    2017-03-06 15:09:42 UTC
Last Seen                     2017-03-06 15:09:42 UTC
Local ID                      b3321326-0fe9-46f8-9b40-81cb4ff38279

Raw Audit Messages
type=AVC msg=audit(1488812982.652:18): avc:  denied  { module_request } for  pid=1131 comm="chronyd" kmod="net-pf-10" scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=system


type=SYSCALL msg=audit(1488812982.652:18): arch=x86_64 syscall=socket success=no exit=EAFNOSUPPORT a0=a a1=2 a2=0 a3=3 items=0 ppid=1 pid=1131 auid=4294967295 uid=996 gid=993 euid=996 suid=996 fsuid=996 egid=993 sgid=993 fsgid=993 tty=(none) ses=4294967295 comm=chronyd exe=/usr/sbin/chronyd subj=system_u:system_r:chronyd_t:s0 key=(null)
'''''''''''''

I thought the RedHat was also educating the users to enable SElinux.
How can i prevent the SELinux errors resulting from recommended "ipv6.disable=1" ?

fix merged to upstream staging branch ->
https://github.com/lnykryn/systemd-rhel/commit/c6774e13acf7b3d8783bc5ab31b2ea72b2fc9aaf
-> post

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:2297