Replace built-in Qube Manager update functionality with the Qubes Update tool

[andrewdavidwong]

The problem you're addressing (if any)

There are currently three methods for updating things in Qubes OS:

1. Direct commands (e.g., qubes-dom0-update, dnf update, apt update).
2. The Qubes Update tool / equivalent qubesctl commands.
3. Selecting a VM in the Qube Manager and pressing the "Update" button.

(1) and (2) have clear use cases and their own advantages. (3) is a weird in-between method that is inferior to (2). For example, historically, not all of the Salt fixes applied by (2) have been applied by (3), which is a security problem.

It is also suboptimal and confusing to users to have and maintain two different GUI update methods. It also would significantly complicate the Updating Qubes OS documentation (and this proposed announcement), which currently just pretend this third method does not exist, for the sake of user comprehension.

Describe the solution you'd like

Get rid of this weird, third update method. Replace it with the Qubes Update tool.

The simplest, easiest way to start would be to simply open the Qubes Update tool whenever the "Update" button in the Qube Manager is pressed.

There are ways to make this nicer. For example, whichever VM is selected when the button is pressed could already be "checked" for you in the Qubes Update tool.

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

All users who are confused about how to update Qubes OS, whether to use the Qube Manager update functionality, etc.

Describe alternatives you've considered

Leaving things as they are, updating the documentation to explain, "Well, you see, there's also this third method, which is not exactly the same as either of the other two methods and has no clear use case aside from the other two. You can use it if you want, and it will probably be okay, but that hasn't always been the case in the past..."

Users have to make this murky choice between very similar options and try to puzzle out what to do.

It's much easier to be able to say, "Here's how to update Qubes OS: Use the Qubes Update tool."

That's why I've chosen to keep the documentation (and this proposed announcement) simple and pretend that the weird third method doesn't exist, but that doesn't stop it from existing or stop users from discovering it, trying to use it, and becoming confused by it.

Additional context

• User discovering that using the weird, third method to try to update dom0 appears to do nothing: Launching "Update qube" dropdown on dom0 in Qubes Manager appears to do nothing #4652
• Users (including me) confused about weird, third method and discovering that using it to update dom0 actually does do something, just doesn't show or tell you anything: https://qubes-os.discourse.group/t/recommendation-against-qubes-dom0-update-use-qubes-updater-instead/4131/7?u=adw

Related, non-duplicate issues

I thought we already had an issue for this, but I can't find one.

As mentioned above: #4652

[GWeck]

For fedora and debian templates (and some others), clicking the update icon in Qubes manager starts a window which first retrieves which updates should be performed, displays the list and gives the user the choice of performing the update or deciding not to do so - which may be desirable in some cases, e.g. if the proposed update has to download a significant amount of data, which may be undesirable at the current moment.

For this reason, I use this method more often than the Qubes updater which just starts and later tells me what it has done.

If the updater would give me the choice to see beforehand what it intends to do and then allow me to decide for each VM if it should be updated, that would be a great help. On the other hand, this probably will be very difficult to implement, since the current solution shows information obtained within the templates whereas the updater runs outside.

[qubicrm]

could this be solved by notification?
I share @GWeck thoughts on the advantage to decide to update or not, based on the info I read at the terminal (methods 1 and 3) and I also use that methods often
I guess a notification that says "there is updates available, but be sure to use Qubes Update Tool / qubesctl this time" could solve the problem, yet keeping the various methods. ( BUT This does not solve the increasing complexity of documentation)

[unman]

On Tue, May 25, 2021 at 02:26:24AM -0700, Dr. Gerhard Weck wrote: For fedora and debian templates (and some others), clicking the update icon in Qubes manager starts a window which first retrieves which updates should be performed, displays the list and gives the user the choice of performing the update or deciding not to do so - which may be desirable in some cases, e.g. if the proposed update has to download a significant amount of data, which may be undesirable at the current moment. For this reason, I use this method more often than the Qubes updater which just starts and later tells me what it has done. If the updater would give me the choice to see beforehand what it intends to do and **then** allow me to decide for each VM if it should be updated, that would be a great help. On the other hand, this probably will be very difficult to implement, since the current solution shows information obtained **within** the templates whereas the updater runs **outside**.

This is the difference between an interactive and non-interactive update process. The Qubes updater is supposed to be *non-interactive*. It could, I suppose, be changed to be interactive, but for whose benefit? How many users are able to make the decision as to whether to apply (some) updates or not? Interestingly, Debian and Ubuntu have moved to an unattended upgrade model where updates will be applied automatically. This feature is disabled in Qubes.

[andrewdavidwong]

@GWeck:

[...] Qubes manager starts a window which [...] gives the user the choice of performing the update [...]
For this reason, I use this method more often than the Qubes updater which just starts and later tells me what it has done.
If the updater would give me the choice to see beforehand what it intends to do and then allow me to decide for each VM if it should be updated, that would be a great help. [...]

@unman:

This is the difference between an interactive and non-interactive
update process.
The Qubes updater is supposed to be non-interactive. It could, I
suppose, be changed to be interactive, but for whose benefit?

Improved support for interactive updates is a separate issue: #6624

I see @GWeck's use case as a reason to improve the Qubes Update tool (tell you what it's going to do before it starts doing anything) or do #6624 first, not a reason not to do this.

---

@qubicrm:

could this be solved by notification? [...]
I guess a notification that says "there is updates available, but be sure to use Qubes Update Tool [...]
[...] could solve the problem, yet keeping the various methods.

This is already how it works. By default, when available updates are detected, there is an icon in the Notification Area that opens the Qubes Update tool. See: https://www.qubes-os.org/doc/updating-qubes-os/

This issue is not about that. This issue is about the update functionality built into the Qube Manager. There would be no point in implementing another update notification mechanism into the Qube Manager to accommodate the extra update mechanism there. That's the exact opposite of the direction we should be going.

[qubicrm]

This is already how it works. By default, when available updates are detected, there is an icon in the Notification Area that opens the Qubes Update tool

yes, of course. What I mean is you never know when there advantage to use qubesctl / salt thing (in case there are updates that can not be delivered by sudo qubes-dom0-update). That could be addressed by notification (inform the user)
Sorry for the lack of clarity.

[andrewdavidwong]

What I mean is you never know when there advantage to use qubesctl / salt thing (in case there are updates that can not be delivered by sudo qubes-dom0-update). That could be addressed by notification (inform the user)

Still a bad idea. The user should never have to understand which types of updates are available and make a decision on that basis about which update tool to use. That's just asking for all sorts of trouble. Users will get confused, use the wrong tool, etc., not to mention that it creates extra work and requires extra thought from the user for no good reason. Thankfully, the user doesn't have to do this even now, as long as they follow the documentation and stick with the Qubes Update tool. The proper eventual solution is to make updates automatic (#4282).

[andrewdavidwong]

Would you all please take the off-topic discussion elsewhere? I shouldn't have to keep asking. This kind of flagrant disregard for our issue tracking guidelines by official team members sets a poor example for the rest of the community (not to mention that I'm getting tired of having to collapse all of these comments).

[andrewdavidwong]

Ok. I think I misunderstood the topic of this issue, initially, then. So: You're highlighting @andrewdavidwong that there are currently two entirely different vehicles for performing updates, not just two different places in the UI to invoke identical actions

Correct.

and this issue is to remove the path from Qube Manager, replacing it instead with a redundant UI invocation of the action in Updater?

Whatever is the best solution. I just don't want users to continue to be confused by the existence of these two different update methods. My hypothesis is that it makes the most sense to make it so that trying to update something from the Qube Manager just opens up the Qubes Update tool, but I leave it up to you to decide the best UX approach.

[ninavizz]

If there is a clearly beneficial reason why the existing path from QM should remain, I would love to know it.

Off the top of my head, I could see why highly technical users may wish to run updates from a Template's terminal—but if that is the case, they should be able to invoke the download and to do it all themselves, without the GUI prompt in QM.

All methods to run updates from the GUI, should point/route through the Updater widget.

I'll propose something, here, shortly, for this specific Issue... thank you for clarifying this issue's purpose @andrewdavidwong!

[DemiMarie]

From my perspective, having the Qubes Manager offer to perform updates makes sense, but it should do the same thing as the Qubes Update tool does. Having it open the Qubes Update tool would be one way to do this.

[andrewdavidwong]

Off the top of my head, I could see why highly technical users may wish to run updates from a Template's terminal—but if that is the case, they should be able to invoke the download and to do it all themselves, without the GUI prompt in QM.

Right. As mentioned in my initial report, there are three methods in total: two GUI, one CLI. (Technically, I suppose the Qube Manager method is a hybrid, since it starts a terminal and runs commands in it for you. The problem is that it doesn't use the same underlying qubesctl command that the Qubes Update tool uses.)

I'll propose something, here, shortly, for this specific Issue... thank you for clarifying this issue's purpose @andrewdavidwong!

No problem!

[ninavizz]

Honestly, @DemiMarie's suggestion is what makes the most sense to me—and yet it's very confusing that the visual language is so different. So, something about the icons, I'll be submitting here—but the core action upon clicking, is that it should invoke that update action w/in the Updater (so, not just taking the user there and requiring they click one more thing to begin the action).

[andrewdavidwong]

Reopening due to problem described in #8627. Here's a summary of the situation:

Expected result

Trying to update a qube from the Qube Manager opens the Qubes Update tool with that qube pre-selected. There is only one GUI update tool in the whole system, so the behavior is always consistent, regardless of whether an update GUI it is opened from the Notification Area (aka "System Tray"), Applications Menu (aka "Start Menu"), or the Qube Manager. For details, see #6635 (comment).

Actual result

Trying to update a qube from the Qube Manager still opens a GUI that behaves different from the normal Qubes Update tool. For example, with this Qube Manager update GUI, users can't select more than one qube to update, which the Qubes Update tool allows. In other words, the behavior is still different when trying to start an update from the Qube Manager compared to other locations. For details, see #8627.

[andrewdavidwong]

@GWeck: That's off-topic here.

[marmarek]

Updating multiple templates at once from qubes manager is also supported - simply select multiple of them before clicking the update button. It will update them in parallel.