I’m used to Debian as well and since today I was tinkering with a Redhat distro in a KVM, I’ve noticed that this workaround doesn’t work: rpcbind
still listens on 0.0.0.0:*
and [::]:*
I’ve checked the /usr/lib/systemd/system/rpcbind.service
where I found
EnvironmentFile=/etc/sysconfig/rpcbind
ExecStart=/usr/bin/rpcbind $RPCBIND_OPTIONS -w -f
and in /etc/sysconfig/rpcbind I’m presented with
#
# Optional arguments passed to rpcbind. See rpcbind(8)
RPCBIND_ARGS=""
Now comes the fun! No matter if you place RPCBIND_ARGS="-h 127.0.0.1"
or OPTIONS="-h 127.0.0.1"
or RPCBIND_OPTIONS="-h 127.0.0.1"
, rpcbind will always listen on 0.0.0.0:*
and [::]:*
It’s a Poettering feature, you may ask? In the same /usr/lib/systemd/system/rpcbind.service
there’s also
# Make sure we use the IP addresses listed for
# rpcbind.socket, no matter how this unit is started.
And in fact we need to look at /usr/lib/systemd/system/rpcbind.socket
as well, where we find
ListenStream=0.0.0.0:111
ListenDatagram=0.0.0.0:111
ListenStream=[::]:111
ListenDatagram=[::]:111
So, no matter what we do to restrict addresses in rpcbind.service, rpcbind.socket has 0.0.0.0 and [::] “hardcoded”. Is this a feature? Yes, it is a feature (btw, the suggested workaround is incomplete: you need to edit rpcbind.socket, not rpcbind; also, the --full switch should be avoided and a drop-in configuration file should be preferred)
So, the Right Way® here should be:
-
systemctl edit rpcbind.socket
-
reset the default listening addresses and replace them (you need to reset them first or you’d simply be listing new addresses to add)
[Socket]
ListenStream=
ListenDatagram=
ListenStream=127.0.0.1:111
ListenDatagram=127.0.0.1:111
-
systemctl daemon-reload
and then systemctl restart rpcbind.socket
A drop-in systemd configuration file will “survive” subsequent updates, and will prevail on whatever the mantainer chooses to do.
I’ve never experienced such failures, probably Poettering would say that the mantainers are at fault here Tried gluster, not proxmox to be honest.
Sadly on subsequent upgrades the package can re-enable itself in some cases if it’s not masked. So IMHO you either firewall it (the advantage with Hetzner’s dedis is that you can apply a template to Rule Them All), or you go and make it listening on 127.0.0.1 only (as per Falzo’s suggestion, with some adjustments as needed…), or you run unmask
and mask --now
before and after the updates, if those are failing.