Installing Software in Qubes (all methods)

Ah. Nice! Always learning :slight_smile:

I think I’ll keep the explanation, sacrificing technical accuracy for clarity. But it’s good to know that! Thanks!

Updated the standalone section to say one can also install like a template or an app qube.

2 posts were split to a new topic: Installing a browser extension like uBlock Origin for firefox so it is available in all appqubes based on a specific template

We have an “External” section for community documentation links like this. Please feel free to submit a PR:

In this case, you may also want to link from:

10 posts were split to a new topic: Curl / Wget-proxy scripts in Templates so users can add GPG distro keys linked to added external repositories

Does installing Zoom, MS Teams and Webex fit into any of these methods? I guess my question is about all the .deb and .rpm packages out there, that cannot be installed permanently in an App Qube.

Usually, I download the installation .deb or .rpm package, move it to the Template, and run sudo apt install .package or sudo dpkg -i install .package or for Fedora sudo dnf install .package in the template.

This would of course require manual update of the package (download new version, move to template, and re-install).

Is there a better way to do this?

I use a StandaloneVM for Zoom, together with a custom update script.

More generally, I consider such software to be untrusted, so I don’t want to put it in any of my existing TemplateVMs, and having a TemplateVM with only one AppVM based on it is somewhat pointless.

What makes you say that? (not looking for an argument, just curious to understand your thinking)

I was thinking that was the whole point: light-one-app-appVM instead of booting up whole system for one app…
Curious too to hear, always looking forward to broaden perspectives.

@enmus @Sven @Demi

My global advice to customers on how to deal with untrusted, invasive proprietary software is always tosegregate them for install, and audit what results from install in a seperate template prior of merging those software into a template that is used for more trusted operations.

I like to seperate for example debian-10 from debian-10-proprietary, where proprietary would be an initial clone of debian-10 + proprietary related repositories.

I tend to agree with @Demi on randomly released .deb and .rpm that are not part of a repository and consequently doesn’t update itself: better to put that on a standalone qube, which is less then desirable approach, but at least undesirable outcome would only touch that qube, even more if only one qube relies on that template qube.

The general idea on this falls into the same category as deploying printer related software in a broadly used template: not a generally good idea because of the added attack surface. We all know that printers drivers are iffy, that additional services (systemd) are added at boot,etc. Whatever extends the attack surface needs to be carefully chosen and audited to be running by default on qubes on which that template depends, and should be a no go. It is better to fit a light-one-app-appVM where needed, depending on threat model and use cases, once again. I would personally not trust Zoom or any proprietary tools to stand side by side of carefully curated software installed on template shared with mission critical qubes i’m using.

I personally prefer to clone a known good template (debian-11) to a general persona-related template (debian-11-communication-proprietary), install software in the latter and then compare the filesystem to see exactly what happened there prior of taking a decision on if I keep that template distinct of others for one/two AppVMs. If no additional start-up services are installed, I might reconsider having it installed in a standalone qube, or sharing a template with other proprietary software. If that thing is not updated automatically, it definitely goes into a standalone, short-lived template-turned-into-standalone for hte time being I need that app where all my being is saying no, but others want me to use that app, so be it really ephemerally. Cloning on thin-lvm is no cost. Installing software there has space consumed for the diff of the installed software. As long as I do not intend to keep it there forever, its more like a install, use it delete it use-case.

Once again, I’m a big advocate of wyng-backups for that, which permits to just send the diff (–dedup is your friend) between debian-11 and debian-11-communication-proprietary to a local backup, including the qube that depends on it. If I do not use either the qube or the template, I make sure to have backuped the qubes.xml with accompanying wyng-backup/qubes-wyng-util at master · tasket/wyng-backup · GitHub tool, and if needed, I restore it a matter of minutes if I deleted it. No worries, small space consomption. Hallelujah.

1 Like

For me, if i will not using a dispvm based on this apps, then i will go to standalone. Just reducing the vm that I have.

2 posts were merged into an existing topic: Qubes Appreciation Mega-thread

My question

What makes you say that?

was in relation to @Demi’s

having a TemplateVM with only one AppVM based on it is somewhat pointless.

I tend to disagree. A standalone VM is kind of the least desirable solution and I always prefer the template based approach when at all possible / manageable. Also I don’t see why a 1 qube to 1 template relationship would be “somewhat pointless”.

Hence my question to understand, since @Demi has clearly a much deeper understanding then I do.

But increasing the total size of backups. You don’t need to backup templates as frequently, since they only contain updates. (Also not benefiting from the /home and /root separation.)

That’s not a problem for me. Well i think diff people have diff configuration, that’s why I only tell the preference.

I just don’t like seeing 30vm+ at qvm-ls / qubes-qube-manager.

On a completely different note, I might have cracked part of the difficulty of installing software in Qubes: (assuming it’s available on the repos, which is not the case of the previous discussion)

But let’s discuss this one on its github issue page.

1 Like

A post was merged into an existing topic: Curl / Wget-proxy scripts in Templates so users can add GPG distro keys linked to added external repositories

It’s largely a matter of personal preference. I have Signal and Keybase in their own templates, with each template having a single AppVM based on it. For Zoom, I use a StandaloneVM. Both are valid and supported choices, and both have similar security properties.

A TemplateVM becomes a big win if one has more than one AppVM based on it. If there is only one, the benefits are significantly reduced. The main exception is that if the TemplateVM’s configuration is easy to regenerate, one may be able to get away without backing it up, reducing backup size.

1 Like

@Demi … I would add the ease of upgrading safely by just changing the template.