Improved support for interactive updates

[DemiMarie]

The problem you're addressing (if any)

Qubes OS has two methods of updating qubes:

• Non-interactively via Salt, which is the preferred method.
• Interactively, via qubes.InstallUpdatesGUI.

However, non-interactive updates have limits. Arch does not support them at all, and on Debian non-interactive updates will not be able to prompt users for configuration choices via debconf. Furthermore, Salt is unfamiliar to existing users. Last, but not least, Salt has substantial overhead.

Describe the solution you'd like

We should support interactive updates as well as non-interactive ones. This can be done by applying changes via Salt if needed, and then calling qubes.InstallUpdatesGUI once the Salt call returns successfully.

Where is the value to a user, and who might that user be?

Users who prefer interactive updates will benefit directly.

Describe alternatives you've considered

Additional context

Relevant documentation you've consulted

Related, non-duplicate issues

[marmarek]

Generally I'd much more prefer making non-interactive more friendly and robust, with a goal of enabling automatic updates by default. If some parts of the systems are incompatible with non-interactive updates, that is a problem.

I don't exclude supporting interactive updates too (in the form of qubes.InstallUpdatesGUI service for example), but that should not be necessary for keeping the system up to date (especially with all security fixes applied - both supplied by upstream distribution and by us).

As for the Salt's overhead, yes this is a major problem. I see two options here:

• try to reduce the overhead of our salt integration (reduce DispVM size, optimize startup, optimize actual salt modules and/or our usage of them)
• implement our own non-interactive update mechanism (possibly not requiring DispVM in the middle) - including a method to plug security fixes for VM's own update mechanism, like we did via Salt in the past (it happened already for both Fedora and Debian)

To be honest, I'm more and more leaning towards the second option...

[DemiMarie]

Generally I'd much more prefer making non-interactive more friendly and robust, with a goal of enabling automatic updates by default. If some parts of the systems are incompatible with non-interactive updates, that is a problem.

Agreed.

I don't exclude supporting interactive updates too (in the form of qubes.InstallUpdatesGUI service for example), but that should not be necessary for keeping the system up to date (especially with all security fixes applied - both supplied by upstream distribution and by us).

Indeed.

As for the Salt's overhead, yes this is a major problem. I see two options here:

• try to reduce the overhead of our salt integration (reduce DispVM size, optimize startup, optimize actual salt modules and/or our usage of them)

Making DispVM startup faster is something we need to do anyway. That said, this will always be slower than direct invocation. Salt also provides no progress meter whatsoever, which is bad for UX.

• implement our own non-interactive update mechanism (possibly not requiring DispVM in the middle) - including a method to plug security fixes for VM's own update mechanism, like we did via Salt in the past (it happened already for both Fedora and Debian)

To be honest, I'm more and more leaning towards the second option...

Agreed.

[andrewdavidwong]

Interactively, via qubes.InstallUpdatesGUI.

Interesting. This is the first I've heard of it.

on Debian non-interactive updates will not be able to prompt users for configuration choices via debconf.

So what currently happens when updating Debian templates via Salt when there is such a choice?

Furthermore, Salt is unfamiliar to existing users.

This should not be a significant consideration, since the vast majority of users should be using the Qubes Update tool, which requires no cognizance of (much less familiarity with) Salt.

Generally I'd much more prefer making non-interactive more friendly and robust, with a goal of enabling automatic updates by default. If some parts of the systems are incompatible with non-interactive updates, that is a problem.

I don't exclude supporting interactive updates too (in the form of qubes.InstallUpdatesGUI service for example), but that should not be necessary for keeping the system up to date (especially with all security fixes applied - both supplied by upstream distribution and by us).

I strongly agree with this.

[ninavizz]

This has been an ongoing theme of requests in the AppMenu survey. I'd also love to tackle this challenge with incorporating what are today "non-interactive updates" into an updater experience.

SALT as a vehicle to install and configure things, as well as to run updates, feels necessary to somehow incorporate in a user-facing "All your updates!" experience; complete with notification setting options, etc.

The SecureDrop team also had to build their own updater to run the SecureDrop Workstation's salt (and other) stuff—and they may have thoughts on how this could be tackled to best support those needs, as well. Working on UX for both projects, in an ideal universe I'd love to be able to see SecureDrop users only needing to use the QubesOS OEM updater—pre-configured in the SecureDrop Workstation installation to do all of that, and eliminating the need for an extra updater.

@conorsch or @eloquence may have thoughts (and may or may not have the bandwidth to immediately share those, here).

[andrewdavidwong]

This has been an ongoing theme of requests in the AppMenu survey. I'd also love to tackle this challenge with incorporating what are today "non-interactive updates" into an updater experience.

I doubt that non-technical users really want interactive updates per se. More likely, what they want are things that sound related but are actually different or things they think they would get from interactive updates but that do not, in reality, require interactive updates. For example, users may want to know how long the update process will take before committing to anything or whether starting an update right now will slow down their computer, use up too much of their bandwidth, prevent them from starting more VMs, prevent them from shutting down, etc.

(Granted, there are some users who want to see every package name and version before manually pressing a button to approve updating, even though it doesn't change anything, they always approve it anyway, and the result is the same as if they didn't insert themselves into the process. In such cases, I suppose it's just to make themselves feel better.)

[deeplow]

Not sure if minimal templates should be covered here. But the salt update (Qubes Update) was failing on debian-10-minimal due to it moving from stable to oldstable upon the release of debian-11. See https://forum.qubes-os.org/t/6346/

[unman]

On Mon, Sep 13, 2021 at 05:38:20AM -0700, deeplow wrote: Not sure if minimal templates should be covered here. But the salt update (Qubes Update) was failing on debian-10-minimal due to it moving from stable to oldstable upon the release of debian-11. See https://forum.qubes-os.org/t/6346/

An updated apt was released back in April which resolved this issue. It will only affect users who have not updated for some reason - most likely those installing a template from the repositories which was built before April, or a new install of Qubes 4.0 which does not have that updated apt. The solution would be to build an updated template, and bump the release iso to include an updated debian-10 template.

[andrewdavidwong]

Generally I'd much more prefer making non-interactive more friendly and robust, with a goal of enabling automatic updates by default.

Related: #4282

[emanruse]

Along the lines of improving UX it would be good to provide actual details when the "Details" button is pressed, as well as having them in the output of the Salt formulae listed in the docs.

In this forum discussion we talked about the possibility of adding info about how much traffic will be used before it is actually used and ask for user's confirmation and one of the participants suggested that this issue is relevant to comment in. This improvement would be particularly useful for users with limited (e.g. mobile) traffic plans.

Of course, post-update details should include that info too. Ideally, progress report would be great too.