Custom update proxy named disposable restored from 4.1 backup no longer works in 4.2 without manually enabling the `qubes-updates-proxy` service

[andrewdavidwong]

How to file a helpful issue

Qubes OS release

4.2

Brief summary

In 4.1, I was able to create a sys-update named disposable that used sys-whonix as its netvm. Templates would then use sys-update as their update proxy qube instead of using sys-whonix directly. I tried restoring this same qube in 4.2 (and also adding the same RPC policy rule), but this same setup no longer works in 4.2 unless I do qvm-service --enable sys-update qubes-updates-proxy in dom0.

Steps to reproduce

Restored a sys-update named disposable (along with its disposable template) from my 4.1 backup that uses sys-whonix as its netvm. Also copied this custom user RPC policy from my 4.1 installation:

qubes.UpdatesProxy      *    @type:TemplateVM        @default              allow target=sys-update

Expected behavior

Same behavior as in 4.1 (templates can update and install packages).

Actual behavior

Templates behave as if they have no network access. Log from sys-update:

# journalctl -u qubes-updates-proxy.service -b
Mar 29 20:41:41 sys-update systemd[1]: qubes-updates-proxy.service - Qubes updates proxy (tinyproxy) was skipped because no trigger c>
lines 1-1/1 (END)

Do this in dom0:

qvm-service --enable sys-update qubes-updates-proxy

Now everything works as expected.

[unman]

Can you confirm that the service was enabled at the time you took the backup?

[Minimalist73]

Isn't it supposed to work like that? The qubes-updates-proxy service is only added to the qube if it's selected as an update qube (default or custom) in Qubes Global Config or if you manually add it. I don't remember being able to reach the tinyproxy service from another qube by only writing a policy, It was required to add the qubes-updates-proxy service each time.

[unman]

On Sat, Mar 30, 2024 at 07:09:51AM -0700, Minimalist wrote:

Isn't it supposed to work like that? The qubes-updates-proxy service is only added to the qube if it's selected as an update qube (default or custom) in Qubes Global Config or if you manually add it. I don't remember being able to reach the tinyproxy service from another qube by only writing a policy, It was required to add the qubes-updates-proxy service each time.

You're missing the point. If a service is enabled in a 4.1 qube then it would be expected that it would be enabled when a backup of that qube is restored in 4.2

I've tested this with a variety of services enabled/disabled, and the restored qube has the same properties as the one that was backed up. So on this testing - not with Whonix as netvm - I cant reproduce the report.

[Minimalist73]

You're missing the point. If a service is enabled in a 4.1 qube then it would be expected that it would be enabled when a backup of that qube is restored in 4.2

I see. It's about restoring and keeping the service when restoring. When I first read the issue, I thought it was about not being able to use the proxy without the service being activated in the qube settings. The title also goes that way, so I got confused.

[andrewdavidwong]

Can you confirm that the service was enabled at the time you took the backup?

No. All I know is that it was working as expected when I created the backup.

[andrewdavidwong]

Updated title and description for clarity and accuracy. Also clarified that sys-update is a named disposable, in case that makes a difference. Both sys-update and its disposable template were restored from the backup, so it probably should have worked.

[unman]

I tested with normal qube and the services were retained on restore. I'll test with a named disposable later, to confirm (or not) the report.