Hide Forgot
Description of problem: For customers *NOT* running IPv6 address in their environment, after updating the package rpcbind to version rpcbind-0.2.0-35.el7 (fixing bug 1293430), the warning will be emitted. However, this doesn't affect the rpcbind function. Also restarting rpcbind.socket will clear the warning and we won't see it again. -------------------------------------------- Version-Release number of selected component rpcbind-0.2.0-35.el7 ---------------- How reproducible: 100% easy ---------------- Steps to Reproduce: 1. Disable ipv6 address e.g. $ echo "net.ipv6.conf.all.disable_ipv6 = 1" >/etc/sysctl.conf && reboot 2. $ rpm -Uvh rpcbind-0.2.0-35.el7 (or beyond version) 3. $ systemctl status rpcbind.socket ---------------- Actual results: [root@hp-dl360g9-07 ~]# rpm -q rpcbind rpcbind-0.2.0-32.el7.x86_64 [root@hp-dl360g9-07 ~]# ss -t -l -n -p | grep 111 [root@hp-dl360g9-07 ~]# systemctl status rpcbind.socket ● rpcbind.socket - RPCbind Server Activation Socket Loaded: loaded (/usr/lib/systemd/system/rpcbind.socket; enabled; vendor preset: enabled) Active: active (listening) since Sat 2016-09-17 21:58:46 EDT; 2h 1min ago Listen: /var/run/rpcbind.sock (Stream) Sep 17 21:58:46 localhost.localdomain systemd[1]: Listening on RPCbind Server Activation Socket. Sep 17 21:58:46 localhost.localdomain systemd[1]: Starting RPCbind Server Activation Socket. [root@hp-dl360g9-07 ~]# [root@hp-dl360g9-07 ~]# yum update rpcbind -y ... [root@hp-dl360g9-07 ~]# rpm -q rpcbind rpcbind-0.2.0-38.el7.x86_64 [root@hp-dl360g9-07 ~]# ss -t -l -n -p | grep 111 LISTEN 0 128 *:111 *:* users:(("rpcbind",pid=2816,fd=4),("systemd",pid=1,fd=57)) LISTEN 0 128 :::111 :::* users:(("rpcbind",pid=2816,fd=11)) [root@hp-dl360g9-07 ~]# systemctl status rpcbind.socket -l ● rpcbind.socket - RPCbind Server Activation Socket Loaded: loaded (/usr/lib/systemd/system/rpcbind.socket; enabled; vendor preset: enabled) Active: active (running) since Sun 2016-09-18 00:00:18 EDT; 37s ago Listen: /var/run/rpcbind.sock (Stream) 0.0.0.0:111 (Stream) Sep 18 00:00:18 hp-dl360g9-07.rhts.eng.pek2.redhat.com systemd[1]: Listening on RPCbind Server Activation Socket. Sep 18 00:00:18 hp-dl360g9-07.rhts.eng.pek2.redhat.com systemd[1]: Starting RPCbind Server Activation Socket. Sep 18 00:00:18 hp-dl360g9-07.rhts.eng.pek2.redhat.com systemd[1]: [/usr/lib/systemd/system/rpcbind.socket:6] Failed to parse address value, ignoring: [::]:111 Sep 18 00:00:18 hp-dl360g9-07.rhts.eng.pek2.redhat.com systemd[1]: [/usr/lib/systemd/system/rpcbind.socket:6] Failed to parse address value, ignoring: [::]:111 Sep 18 00:00:19 hp-dl360g9-07.rhts.eng.pek2.redhat.com systemd[1]: [/usr/lib/systemd/system/rpcbind.socket:6] Failed to parse address value, ignoring: [::]:111 [root@hp-dl360g9-07 ~]# ---------------- Expected results: No warning emitted ---------------- Additional info: The rpcbind-0.2.0-35.el7 has added following into systemd script: ListenStream=[::]:111 <<<<<<<<<<<< This gets failed if *NO* ipv6 address exists ListenStream=0.0.0.0:111 BindIPv6Only=ipv6-only
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