Problem summary:
Setting dom0’s /etc/qubes-rpc/policy/qubes.UpdatesProxy
AND /etc/qubes/policy.d/30-user.policy
TemplateVM target to any NetVM other than a sys-wifi, sys-wired, sys-net, or sys-whonix results in one of two errors: “Reading from proxy failed - read (11: Resource temporarily unavailable) [IP: 127.0.0.1 8082]” OR “Reading from proxy failed - select (115: Operation now in progress) [IP: 127.0.0.1 8082]” (when the qubes-updates-proxy service has been added to the VPN or Firewall NetVM via dom0)
Objective summary:
I’d like to understand how the Update proxy mechanism works, because I thought I understood it, but I clearly don’t
Troubleshooting summary:
-
Cloned
/etc/qubes/policy.d/90-default.policy
as/etc/qubes/policy.d/30-user.policy
according to best practices and verified permissions were identical (664) -
sys-wifi and sys-wired were created as AppVMs (not cloned from sys-net) as HVM VMs that provide networking; sys-firewall is the stock firewall VM; sys-vpn leverages fedora’s native VPN facilities and did not require any additional packages; ALL NetVMs successfully provide expected connectivity to downstream Qubes
-
When dom0’s
/etc/qubes-rpc/policy/qubes.UpdatesProxy
AND/etc/qubes/policy.d/30-user.policy
TemplateVM target is set to sys-wifi, sys-wired, sys-net, or sys-whonix TemplateVMs can immediatelycurl --proxy 127.0.0.1:8082/ <HTTPS target>
,apt upgrade
, anddnf upgrade
successfully without restarting any Qube -
When both of those files’ target is set to sys-firewall or sys-vpn, Template VMs are immediately unable to
curl
,apt
, anddnf
Reading from proxy failed - read (11: Resource temporarily unavailable) [IP: 127.0.0.1 8082]
-
ALL NetVMs are based on the same fedora-38-minimal template with the following packages installed: qubes-core-agent-networking, qubes-core-agent-network-manager, qubes-core-agent-dom0-updates, gnome-keyring, iproute, iputils, NetworkManager-wifi, network-manager-applet
-
NONE of the NetVMs appear to be running the qubes-updates-proxy (or anything like this) when querying services from dom0 via
qvm-service <NETVM>
-
Only the non-VPN/firewall NetVMs appear to be running the qubes-updates-proxy when queried from within the NetVM itself via
systemctl | grep update
orsystemctl status qubes-updates-proxy
-
When I enable qubes-updates-proxy on the VPN or firewall NetVM from dom0 via
qvm-service <VPN NETVM> qubes-updates-proxy on
(AND update thequbes.UpdatesProxy
AND30-user.policy
files on dom0) subsequent TemplateVM updates take longer to fail, but eventually fail (“Reading from proxy failed - select (115: Operation now in progress) [IP: 127.0.0.1 8082]”) as does curl, even with the--insecure
flag (“curl: (56) Received HTTP code 500 from proxy after CONNECT”) -
Enabling qubes-updates-proxy via the Qube Manager GUI has the same effect
I don’t think this is a bug, I just think I’m missing something. I’ve scoured the forums and am out of ideas. I hope this is something simple.