Can someone explain or point me towards the documentation on what each qube-specific “service” does when applied in to vm through the settings tab in the vm settings? For example, the networ-manager service is fairly self-explanatory but what about the others that are qubes specific like “minimal-netvm” or “minimal-usb”? How does applying these settings affect the vm’s or dom0’s behavior? I also see that I’m not able to assign anything at all to disp-vms. The only disp-vm that have these types of services are the one that come standard with the installation if you elect to make those vm’s disposable. And yet, some of the standard qubes you’d expect to have some of these services applied to them don’t, like sys-firewall. Shouldn’t sys-firewall have the “qubes-firewall” service applied to it automatically at installation, or does sys-firewall not need to have that applied in order for it work properly? Would applying “qubes-update-check,” for example, to a sys-whonix prevent other qubes from checking for updates. I generally just want to understand the logic on how to use these services correctly.
you have preceded me! ahah
I think it’s fair to feel some uncertainty here. sys-firewall does in fact run the qubes-firewall service, but it won’t be listed as enabled if you run qvm-service sys-firewall. (maybe it does sometimes? not sure) Same for some other services.
Also, the qvm-service manpage could use a tiny refresh to update nomenclature- its use of netvm refers to NIC qubes like sys-net, not to any qube used as a netvm (referred to as ProxyVM in the manpage).
A good-ish way to see what services a qube is probably running is to look at the filenames present in /run/qubes-service. E.g. in a default sys-firewall:
user@dom0 ~]$ qvm-run -p sys-firewall 'ls /run/qubes-service'
meminfo-writer
qubes-firewall
qubes-network
software-rendering
But that doesn’t tell the whole story. To be certain, you’d want to check the output of systemctl status on the qube, and look for services with “qubes” in the name; that covers most cases, at least.
On sys-whonix this service would only control whether the sys-whonix qube initiates its own checks for updates to whonix-gateway-18, or not. (Actually though I’m not sure how that particular service functions w/r/t to the Whonix templates.) It wouldn’t control how/whether other qubes check for updates to their templates.
Ah, I see! This definitely provides some perspective. Thank you.