On my laptop, which has been upgraded to 4.2., whonix-gateway-17 (which is the template for sys-whonix) needed updating.
My attempts to get it to update failed. I’ve solved this problem, but I think the story might be instructive to many (and a reminder to many others). (This is unrelated, I think, to the earlier issues I had with whonix on my laptop before I upgraded to 4.2.
Totally different error messages.)
One thing that seems to be new to 4.2 is that the Qubes Global Config, Updates Page has (if you scroll down a bit) a setting for Update Proxy. There’s a default update proxy and a Whonix update proxy. When I went looking for this wanting to make sure whonix was trying to do the right thing, there was a warning that I had a policy.d file that might be overriding this. And indeed, I did. The GUI for settings functions by maintaining the file /etc/qubes/policy.d/50-config-updates.policy. As near as I can tell from looking at my other system (not yet upgraded) this file did not exist in 4.1.
When I set up the cacher many months ago on 4.1 I wrote a line to 30-user.policy to read qubes.UpdatesProxy * @type:TemplateVM @default allow target=sys_cacher. This causes any TemplateVM to try to use the cacher for its updates. [and some of you can see where this is going already.] I kept that moving to 4.2 and as it happens, that was the “override” that Qubes Global Config was highlighting. But since I had only overridden that one line I couldn’t see the issue.
50-config-updates.policy has two lines in it, though, and the first line addresses whonix. It causes whonix (and whonix only) templates to use sys-whonix for their updates. I forgot some key facts and figured this was OK.
It wasn’t. The problem (ant the thing I had forgotten about) is that when the system reads policy files trying to figure out whether an operation is allowed or not (and also which action to take) it reads all of the files in /etc/qubes/policy.d in numerical order and stops when it finds its first match. And in this case, the first match for Whonix stuff is the line I had added to 30-user.policy (since it addresses all templates). It never saw the whonix specific line in 50-config-updates.policy at all. (And note that I said the whonix line is first in that file, for that very reason.)
The answer, obviously, was to remove the line from 30-user.policy completely, and to (from now on) rely on 50-config-updates.policy. And furthermore, to do my configurations so as to modify this file…for example when I want to deactivate the cacher temporarily, I need to set the line in 50-config-updates to point to sys-net-wifi, not sys-cacher. (I would do this via bash script or salt, not through the GUI.)
Now for the next question, one I haven’t figured out yet: If I want to deactivate the cacher, and I want to update the line in 30-config-updates.policy to not reference the cacher…what do I replace it with? I mentioned using sys-net-wifi (not sys-net), and that’s because I have two sys-net qubes, one for my wifi network, and one for my ethernet network. I could just hard code it to switch to sys-net-wifi, but there are occasional circumstances where that’s not right (for example when rebuilding my sys-net-wifi VM I am actually using a temporary version of that qube named sys-net-wifi-temp). How do I know what my current net qube is? At first I thought I could just read my default net qube (on the gui on the first tab, but also qubes-prefs default_netvm) for that info…but actually I can’t. This is actually used for setting the network VM on a newly-created qube. And on my old system, it’s actually set to none because I would rather have to set the netvm on a qube explicitly than have it accidentally be set to an actual network (the overwhelming majority of my disposables do not touch a network). I forgot to make the same setting on the new install.
Another thing: I can’t find it now, but I am wondering if @unman’s cacher salt formula references 30-user.policy in it…if so it probably shouldn’t.