Template Update Propagation to App Qubes

User Support General
1

I thought I understood how updating a template qube then propagates those updates to app qubes that use the template. My understanding had been that if I run apt-get update and apt-get upgrade on a template qube, those same updates would propagate to any app qube based on that template qube.

Today I tried that but the upgrades didn’t propagate, so I had to upgrade the app qubes directly. The scenario used three qubes -

debian template qube > app A template qube > app A app qube

I upgraded the debian template qube first, restarted it and then restarted app A template qube. The updates, specifically firefox, didn’t propagate to app A template qube.

Then I manually upgraded the app A template qube, restarted it and then restarted app A app qube. The updates didn’t propagate to the app A app qube. So I updated app A app qube manually, which I understand is less than idea.

If someone can please help me understand how the upgrades propogate in a scenario like this, I’d greatly appreciate it.

2

Something seems wrong in the setup, we need to find what now. The behavior you describe would be correct if app A template qube and app A app qube were both standalones.

In each qube settings (not for debian template), check they have a template in the “Template” field.

3

Do you mean that you have:

  • debian-12-xfce template qube
  • app-a-template template qube
  • app-a app qube

The app-a-template qube was created from debian-12-xfce template qube.
In this setup the debian-12-xfce and app-a-template are independent and changes in debian-12-xfce qube are not inherited by app-a-template qube.

4

app A template qube has TemplateVM listed in the Template field

app A app qube has app A template qube listed in the Template field

5

Your understanding is correct. Even so, shouldn’t at least app A app qube inherit updates from app-a-template qube?

6

It should.
Try this for a test:
Open a terminal in app-a-template qube and run this command to create a test file by running this command:

sudo touch /etc/testfile

Restart/shutdown app-a-template qube.
Restart app-a qube and check if the file exists by running this command in its terminal:

ls -l /etc/testfile
7

Coming back around to this now that I have some time to continue troubleshooting it. Yes, /etc/testfile appears in app-a qube after that file was created in app-a-template qube and after both qubes were restarted, app-a-template being restarted first.

8

I have seen behavior like this:

From a fresh install, then full update. For the first time I open App VM - Disposable (which in my case is from Fedora) I go to a site. I close Disposable. I find the Template has information from Disposable. I never mistakenly opened the Template. So I shut down computer. Power back up. Debris is still in Template Disposable DVM.

I think it may be part of some thing to do with Firefox Sync process.

As far as Brave. Over a year ago I was using Brave on Mint Linux, and after I used the Brave Browser, within 24 hours it would do a long update from the Brave Mothership. After some time, I hypothesized that Brave Browser was reporting back to the Brave Mothership what I was doing on internet.

There are several suggestions of excellent alternate Browsers. I use Mullvad Browser. but to prevent this Synching of information.

I clone a Template of a standard Qube, like Work Qube. I named it Work-Mullvad.

From that I created a Standalone App,

From that I created a brother App, named MV. From that I created several brother App Qubes which are MV, and the OS will provide a number. I use these apps in sequence. One web visit per app. If I have information I want to keep I save the infor in the app. Close the internet connection of the MV-clone. Copy the information to a Qube (which I keep offline. )

Delete the MV-clone I just used.

When I want to get back online. I use the next MV-clone in sequence. Might have to start internet connection again.

As you can see, I don’t do a lot online, or this would be too time consuming and obnoxious.

I have never experimented with it. but one could create a DVM fo Mullvad. But how to avoid the back flow of information into Template, I dunno if it would?

I have also not experimented with using Debian Qubes (???)

Also notice Frefox has a lot of trackers preinstalled. Which getting rid of would, I guess change the Fingerprint.

I seem to recall some more knowledgeable than myself. Saying, Qubes was about Security Anonymity using Qubes (to which I translate, means to achieve Anonymity, one must make effort. Choice of software, programs, Operational Security, Opsec. I also know nothing about how Whonix works - considering issue of back flow in information into Template.)

I wait to hear about your experience and work around for problem.

Best Wishes

9

A template must be shutdown before starting the inheriting qube for changes to be applied, this is so because changes are transactional.

If you start a template, make a change and keep it opened, then you start a qube using that template, the changes won’t be there. Once you stop the template, the changes are merged on the qube disk, so any qube using that template will inherit the changes.

This is a reliable mechanism that IMO can’t fail as the qube should not start at all in such case.

1 Like
10

Today, my experiments did not indicate that the App Disp-DVM was acting abnormally…

Notice that starting the App shows a qube that ends in four randomly chosen numbers, While Template DVM does not.