Are there some sensible recommendations that I might have missed, on how to watch out for Debian quietly installing network services when I didn't ask for them?

I'm using Debian-based distributions, where if you install a network service, it is immediately enabled and started. Specifically I'm using Debian 9 (stretch) at the moment.

This is so difficult to deal with that the openssh-server package added a special hook that stops the server from being run, but whoever did this did not seem to manage to convince the rest of Debian to tackle this issue comprehensively. E.g.

  1. This issue has been discussed at debian-users. Sadly the race condition is not solved. A Debian maintainer suggests configuring policy-rc.d to block the invoke-rc.d ssh start call in the package postinstall. There are clunky details, but it is achievable. Unfortunately this is not really true; it doesn't prevent a race condition. policy-rc.d is not relevant to the update-rc.d ssh enable command which the package also runs. This would be exposed by a power failure or system crash at the wrong time.

The example that sparked this question is icinga2 which recommends monitoring-plugins.

E.g. monitoring-plugins-standard is indirectly recommended by icinga-common-1.13.4-2. Alternatively, it may be installed deliberately e.g. for check_dig. In general, the description says "This package provides the suite of plugins that are most likely to be useful on a central monitoring host."

In turn, installing monitoring-plugins-standard also installs, and enables, rpcbind. This is even after I believe Debian made deliberate changes to remove the rpcbind network service from the default install, finally following Ubuntu's lead there.

Even if you see the list of packages installed as dependencies, I wouldn't say it's at all obvious that "rpcbind" is an additional network service.

I also wonder if this specific case should be considered a bug that could be fixed... is there anything in Debian Policy about this sort of non-obvious dependency on a network service package?

# apt install monitoring-plugins                                                                          
Reading package lists... Done                                                                            
Building dependency tree                                                                                                         
Reading state information... Done                                                                                 
The following additional packages will be installed:                                                                             
  libnet-snmp-perl libradcli4 libtirpc1 monitoring-plugins-standard rpcbind                     
Suggested packages:                                                                                                              
  libcrypt-des-perl nagios-plugins-contrib qstat                                                
The following NEW packages will be installed:                                                                                    
  libnet-snmp-perl libradcli4 libtirpc1 monitoring-plugins monitoring-plugins-standard rpcbind  
0 upgraded, 6 newly installed, 0 to remove and 0 not upgraded.                                                                   
Need to get 432 kB of archives.                                                                 
After this operation, 1,901 kB of additional disk space will be used.                                                            
Do you want to continue? [Y/n]
# systemctl status rpcbind
● rpcbind.service - RPC bind portmap service
   Loaded: loaded (/lib/systemd/system/rpcbind.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2018-05-04 20:44:39 BST; 49s ago
     Docs: man:rpcbind(8)
 Main PID: 20930 (rpcbind)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/rpcbind.service
           └─20930 /sbin/rpcbind -f -w

May 04 20:44:39 brick systemd[1]: Starting RPC bind portmap service...
May 04 20:44:39 brick systemd[1]: Started RPC bind portmap service.

Full disclosure: monitoring-plugins-standard says "Some scripts need more packages installed to work, which is implemented as recommends." And monitoring-plugins-basic says "This package provides a basic set of plugins with minimal external dependencies."

  • One thing I might look into is how this works inside containers. When you run debian in a container (e.g. docker), and install a service, it doesn't automatically start. Yes there's no systemd running, but this means it either isn't trying to call systemd during install, or it does an ignores the error. In any case, might be worth investigating. – Patrick May 5 '18 at 3:47
  • @Patrick ealready. The mechanism generally used in Docker is policy-rc.d as mentioned in the first link above (the link to openssh, "special hook to prevent it"). Once you have any init system, this mechanism is strictly wrong, due to the race condition I mention there. – sourcejedi May 5 '18 at 9:15
  • Do you mean "network service" rather than "network server"? They're rather different things. – roaima May 11 '18 at 22:34
  • Actually apt-cache show openssh-server: secure shell (SSH) server .... And I'm concerned with network servers specifically, I'm not worried about servers on local unix sockets. ...I think that's enough to specify my position. Not sure why I chose "servers" though. Edited to use "services" instead, certainly it is the more common usage. – sourcejedi May 11 '18 at 23:06

I setup and used to maintain a network of a couple hundred Debian servers (not big).

I used a jumpbox VM, useful as you can leave for the day leaving something running there, or setup up automated housekeeping tasks.

From there I ran automated scripting and Ansible for me, Rundeck for sysops.

rpcbind is especially pernicious, reappearing in system updates if memory does not fail me. Another one that rears is ugly head frequently in kernel updates is firmware-linux-free which is not needed in VmWare VMs. I also pinned to -1 a couple of packages related to systemd, however in a couple of major version upgrades, even pinning it to -1 did not keep it from trying to reappearing.

I would use Ansible policies to keep it in check, failing pinning the rpcbind package to -1.

However, I bet my money even pinning in each server the rpcbind package to -1 won't solve the problem. Debian is getting a bit more convoluted as time goes by. I could swear I tried it, not sure.

Having a jumpbox, accessible via VPN+ssh in my case, also was useful when I needed to do something urgently outside work, or a couple of times over my phone. Anecdotally, even once in a 1-day AWS conference, I done a small emergency intervention over my mobile phone, situation which would otherwise would require me to leave it.

If you are strongly against having a jump box, you can always run scripting+Ansible from your laptop/work computer. Ansible does not require agents in the client VMs.

Related question for others visiting: Linux equivalent to PowerShell's "one-to-many" remoting

  • So far holding/pinning is known to be unreliable and there is no update on a fix. Unless you never use aptitude for anything, I think? But certain aptitude features are still more convenient or just not implemented elsewhere (aptitude why). So I think you have to qualify that answer with "aptitude is buggy, never use it to install packages". How practical an answer with this qualification remains in general might be a matter of taste. serverfault.com/questions/17046/… – sourcejedi May 5 '18 at 9:21
  • i actually do use Ansible and I love it :). I noticed the problem with icinga2 while maintaining the icinga2 role for my dinky home server. I now have a role to mask and stop rpcbind, which avoids either polluting the icinga2 role or breaking the idempotency of the play as a whole. I'm happy to have this as a specifc safeguard. The question I'm asking is about how this can be prevented in future and in general, for any other network service that I didn't ask for. – sourcejedi May 5 '18 at 9:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.