How could I reasonably avoid installing network services I didn't ask for?

Question

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."

Answer 1

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