Tool: Simple Set-up of New Qubes and Software

[Sven]

@redmind

I remind you that even for installing a minimal-appvm the end-user need to “write things in Dom0” which for some is as scary as any other thing not involving a re-assuring GUI (fugly or not).

Bad example. Minimal templates are not for experienced users.

[SteveC]

I’m guessing you meant inexperienced users.

This inexperienced user certainly became more experienced trying them out! (All because I didn’t like what I deemed to be contextual bloatware (belongs in template A but not in template B, yet is in both).)

[SteveC]

I don’t feel so bad now.

I’m a complete rookie when it comes to matters GPG.

[redmind]

@SteveC

(All because I didn’t like what I deemed to be contextual bloatware (belongs in template A but not in template B, yet is in both)

exactly what brought me to set up minimal templates as well. especially since I prefer having a specific and separate template for (almost) each app-vm.

[unman]

@SteveC

Does it makes sense to configure Microshaft windows templates to use the cacher? Especially when they are for offline windows?

No. The cacher presents as a proxy on port 8082. Your apt or dnf clients in your linux templates are preconfigured (by the Qubes OS project) to use those proxies. That’s why they work even if there is no netvm assigned to the template (which is the default). Windows is oblivious to this.

Actually, because the proxy is listening on 8082 and it’s configured to
allow inbound traffic to that port, you can use the proxy with any
qube, including standalones and qubes that dont have working qrexec.
You just need to have the proxy somewhere upstream, and configure using
the normal mechanism for specifying a proxy.

You could do this with Windows if you had a number of such templates. I
have no idea what the structure of a windows update request might be, or
if it would work.

[unman]

I asked, because I figured it was probably a bug. Now I’m sure it is; the installer shouldn’t try to do that.

I’m not a windows user.
The notes clearly say that changes will be made for every template that
exists on installation.
So yes, every template is opened, and is reconfigured if it is Arch,
Debian or Fedora. Other templates should just close down without changes
being made.

[unman]

Thanks unman for this great contrib. Although I already manually created such qubes but based on Whonix (since somehow my videos are playing better there than in other flavor-based qubes), I tried your package and it turned out that media qube is based on debian 11, not debian-11-minimal, although I have both templates already installed prior to this. Is that intentional?

Yes it is. Based on feedback I’ve received, it seemed that users wanted
those media qubes to have extra packages, as well as networking
available. It doesnt take much for a debian-minimal to morph in to a
stock debian. So I opted to base on the stock.
I don’t run that myself,(my media qube is minimal), and I’m open to
persuasion for this package.

[Tzunami]

I’m one of those people who is struggling. I couldn’t get the GPU vm installed. I was soooo close too, everything else worked. I loved it, but had to put Qubes on hold, till my next break. In production right now, and only my new pc is Qubes compatible, it’s the reason I chose it. I script like yours would definitely help, especially along installing the gpu vm.

[Bop667]

@unman

I’ve been packaging salt formula for some time to do just that. (You can
install these packages and get the end result without knowing anything
at all about Salt.)

How I can install this with salt ?

[unman]

How I can install this with salt ?

Do you want a salt formula to set-up the 3isec repository and install
the tool?
I can do that.

[Bop667]

Yes, I would appreciate that.

[TheGardner]

Got it working yesterday and added the split-gpg, multimedia and cacher templates and VMs. What is unclear for me - how can I start updates manually now (after all is changed to update via sys-cacher) - do I just have to wait, until the Qubes Updater shows available updates now?

[enmus]

@TheGardner

how can I start updates manually now (after all is changed to update via sys-cacher)

Does launching Qubes update tool and manual selecting updates invoke cacher? If everything is properly set, I’d be surprised “no” would be the answer.

[unman]

Does launching Qubes update tool and manual selecting updates invoke cacher? If everything is properly set, I’d be surprised “no” would be the answer.

Yes. If it is not running it should be started as part of the update
process.
The user experience for running updates should be unchanged, and cacher
should be transparent to user.

Some issues -

1. if you want to run updates over Tor you must have your Tor
   proxy upstream of cacher - either directly as it’s netvm, or as some
   netvm upstream. This isn’t set automatically if you select “update over
   Tor” and wont be unless the package becomes official.

2. @Insurgo has pointed out that the package doesn’t play nicely with
   Whonix. In particular it will rewrite repository definitions in Whonix
   templates, and set a policy that overwrites the Whonix defaults. I’ve
   fixed the latter and am thinking about the former issue. If you have
   Whonix templates you should restore the repository definitions either by
   running sed -i s^http://HTTPS///^https://^ REPO_FILE, or by running
   qubesctl --skip-dom0 --targets=WHONIX_TEMPLATE state.apply cacher.restore_templates

Replace REPO_FILE with the path to the repository definition.
Replace WHONIX_TEMPLATE with the name(s) of your Whonix templates.

3. On install, the package attempts to open all installed templates to
   make necessary changes. This includes Windows qubes and standalones:
   it’s unlikely that you will have configured these to be capable of
   salting, so this is a waste of time. I don’t have a way round this.
   You will have to just shutdown such qubes.
   If you have standalone created from existing templates, these will be
   capable of being salted, and can be controlled and updated using the GUI
   tool.

unman

I never presume to speak for the Qubes team.


When I comment in the Forum or in the mailing lists I speak for myself.

[augsch]

I am to comment that, if you are accustomed to installing pkgs in dispvm to try them out, or to satisfy some compiling requirements, before actually modifying your templates, you will have to reverse the cacher’s impact on your dispvm’s root template ( like fedora-36). Or you won’t be able to fetch repo info in that dispvm.

[TheGardner]

@unman

if you want to run updates over Tor you must have your Tor
proxy upstream of cacher - either directly as it’s netvm, or as some
netvm upstream.

that’s the answer especially for my problem. Thanks a bunch and fixed now.

[unman]

I am to comment that, if you are accustomed to installing pkgs in dispvm to try them out, or to satisfy some compiling requirements, before actually modifying your templates, you will have to reverse the cacher’s impact on your dispvm’s root template ( like fedora-36). Or you won’t be able to fetch repo info in that dispvm.

Yes, all template based qubes inherit the settings in the template. This
includes the repository definitions.
You can reverse the changes - sed -i s^http://HTTPS///^https://^ REPO_FILE
I don’t - I have cacher in the network path -
qubes → cacher → sys-pihole → sys-net
and I set the proxy in the qubes.(You can do this from
/rw/config/rc.local if you use qubesdb-read /type to detect if it’s an
AppVM, and then set proxy to the IP address on your system.)

apt-cacher-ng has many nice features.
One that I use is to restrict the use of the proxy from templates - I
never agreed with the decision to remove restrictions from tinyproxy.
You probably know that you can use the listening proxy from templates to
do all sorts of things besides updates - download keys, access arbitrary
sites, etc.
If you edit /etc/apt-cacher-ng/acng.conf and set ForceManaged 1, then
the proxy will only allow access to the remapping backends you have
defined.
This is intermediate level Qubes: it increases the security of templates
a little, but requires more user intervention in some cases. It could
be that you never need to reset this, depending on your usage.

I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.

[Insurgo]

If you guys have implementation recommendation into making cacher play nicely with whonix templates, so that whonix templates can also reuse debian-11 downloaded packages from cacher instead of redownloading them for each Whonix templates individually, please comment at https://github.com/unman/shaker/issues/12

[enmus]

what would happen with

sys-net->sys-firewall->cacher1->sys-whonix->cacher2

setup, while setting for all non-whonix qubes to update from cacher2, and all whonix-based qubes from sys-whonix?

[SteveC]

“Other templates should just close down without changes being made.”

Maybe my system is just slow but it seemed the windows templates didn’t just close down without changes being made; it was taking a while to do SOMETHING.

Two of the templates did not shut down at all. Hours later they were spinning, still, and I just did a kill on them.

It’s my fault for never backing them up and removing them. I got to be the guinea pig (occasional) windows user [as little as possible, but I cannot, for example, get my printer to work on a Linux qube, nor will my Canon camera software].

But I do in earnest suggest something be put in to just skip windows templates; they don’t seem to tolerate this well.