Qubes OS and metered connection?

User Support
1

Hello,

I’m often using a metered connection (aka limited in volume) and Qubes OS trying to look for updates in each qube is not bandwidth friendly. Every fedora qube running requires ~80 MB of downloaded data only to check if there is an update for the template.

Is it possible to easily disable this auto check?

As the default update proxy is sys-net it makes it easy to look for a metered connection (the information is available with nmcli), I could make a systemd service that regularly look at the current connection and disable the update proxy accordingly, is it something that would be interesting to upstream?

3 Likes
2

Have you tried setting the feature supported-service.qubes-update-check = ‘’ on the template?

3

I believe that we have to see the bigger picture. Instead of disabling the update proxy at individual qubes, we could cache those requests properly. This is what I am currently doing. My setup consists of an Nginx reverse/forward caching proxy. The update proxy URL is set to http://{archlinux|deb|yum|ftp}.qubes-os.home. Nginx seats between Internet and tinyproxy. And caches and forward requests to either https://{archlinux|deb|yum|ftp}.qubes-os.org or https://mirrors.kernel.org/{distro}. So all the forward requests are over secure HTTPS protocol (and .onion compatible). I wrote a front-end for it to individually invalidate/purge cache if I desire to do so. Here is a snapshot:

control
control1366×768 104 KB

And here is the snapshot of web front page

front
front1366×768 139 KB

1 Like
4

it would still look once in a while unfortunately, I do not want to waste any byte for checking updates. But having this out of the box in general would be awesome!

no, the plan was to disable it in sys-net (default update proxy for qubes, but not for dom0 :confused: )

no :thinking: I didn’t know it was a thing.

1 Like
5

Qubes don’t use the update proxy to check for updates, they are checking the updates from the inside using their network connection provided by their net qube.

2 Likes
6

I guess the only way would be to check the metered status in sys-net and then notify the dom0 about it using qrexec so that dom0 can disable or enable the qubes-update-check service for all qubes.

7

Another solution would be to patch the qubes-update-check service to use qrexec to ask sys-net if it is using a meter connection.

8

It is definitely doable. upgrades-installed-check could query an special metered-connection feature from dom0. And exit before doing its work if the connection is metered.

9

p.s.: How do you check if the connection is metered? Based on IP range, Connection name? Or is there some new IETF standard for it to let internet providers announce it? I am curious.

Oh. I see that nmcli has special property for it. Sorry for my negligence.

10

I’m using this (not on Qubes OS at the moment but code is the same)

# skip updates on metered connections
skip_metered() {
    active_connection_uuid="$(nmcli -t -m multiline -f UUID connection show --active | head -n1 | cut -c 6-)"
    is_metered=$(nmcli -t -m multiline -f connection.metered connection show "$active_connection_uuid" | cut -c 20-)
    if [ "$is_metered" = "yes" ]; then
        echo "connections is metered, skipping updates"
        exit 0
    fi
}
1 Like
11

Very nice. The only remaining problem is that it is not a good idea to set a global metered-connection feature for dom0. Since user might have multiple NetVMs with different upstream network interfaces and only one would be metered. Setting metered-connection feature per NetVM is doable. However a mechanism should be developed for the VMs that connect through that NetVM to inherit that feature. Finally they could query their own metered-connection

12

I think instead of patching upgrades-installed-check it’d be better to override qubes-update-check systemd service in the templates and add the metered condition check:

sudo mkdir /lib/systemd/system/qubes-update-check.service.d
cat << 'EOF' | sudo tee /lib/systemd/system/qubes-update-check.service.d/override.conf
[Unit]
ConditionPathExists=!/var/run/qubes/metered-connection
EOF
sudo systemctl daemon-reload

Then create/remove /var/run/qubes/metered-connection in the qube using some script that’d be run in the qube to get that info from dom0/sys-net.

2 Likes
13

I just found about DHCP Option 43 (Vendor specific options) with the value ANDROID_METERED. Which could announce a metered connection via DHCP. Sadly we do not have DHCP here. Otherwise all of this could have been done through the connection rather than Qubes features.

14

this is really complicated and requires a manual user step?

15

No, it’s not a complete solution, just remark on how it’d be better to disable the updates check if there is already information about metered connection being used in the qube.
The question on how it’d be better to get the metered connection status from sys-net to other qubes is still open.

16

Would it make sense to have a metered VPN? For now, I only see metered connections be a thing for physical network interfaces, I don’t think this should apply on netvm that already have a netvm, what do you think?

17

I could imagine some corporate LAN without internet access by default and access to the internet metered connection over VPN running on the server with e.g. GSM modem in this LAN.
But it’s a rare case.

18

Yes, you can easily disable it:

Qubes Global Config → Updates → Disable checking for updates for all existing qubes

This simple option has been in Qubes for many years. (Even before Qubes Global Config, it was available elsewhere.) I’m a bit puzzled as to why some of the previous replies in this thread make it seem much harder than it is.

1 Like
19

Very nice. What is the pref or feature which is set/unset in the background? So we could automate it via nmcli hooks and qrexec policies.

20

p.s. Found it. It is service.qubes-update-check feature. It is set per VM. Here is the Python class of Qubes Global Config code.