wget or curl both do the same, both are no problem.
Just open the template terminal and follow the install routine. Make sure you have wget or curl installed (apt install -y curl wget).
http://127.0.0.1:8082/ is doing the magic.
curl should also work:
curl --proxy http://127.0.0.1:8082/ -s https://deb.librewolf.net/keyring.gpg | apt-key add -
As I recall there was some issue with exposing dom0 to the internet with that stuff.
You don’t install LIbreWolf to the dom0.
You don’t, but in order to install it ANYWHERE, don’t you have to expose dom0 for that stuff?
@Sven
I was reading your blog post about automating the debian templates.
I have a question regarding this line:
“[We set] the maxmem property to zero, which signals we do not want memory balancing.”
Why is this? From reading the
$ qvm-prefs --help-properties debian-11
and
$ man qvm-prefs
I see that maxmem allows the template (and the app-qubes based on that template) to dynamically adjust the memory allocated to them (starts with 400 MB and goes up to 4 GB).
Why do you suggest switching off this behavior for a deb-11-minimal template?
Nope, but you should know what you are doing. Best is to first clone your template (or even better using a minimal template) and install with http://127.0.0.1:8082/
Oh, the irony. That thread you pointed to? That’s the one where I remembered it being a big heaping smelly issue…and the second to the last post (#95) was me posting my (partial) solution to the issue. asking if anyone could critique it from a security standpoint. (I have installed brave and veracrypt this way.) I had completely forgotten about it.
OK high up on the to-do list is trying out LibreWolf. Thanks!
Why do you suggest switching off this behavior for a deb-11-minimal template?
I don’t have a good/technical reason. My impression (which could be wrong) is this:
An exception to this may be qubes running web browsers. I’ll spare you my rant about web browsers and the amount of memory they consume. Google’s Chrome seems to work well with 1GB memory in my scenarios, but I am compartmentalizing heavily so you won’t see me use more than 2-3 tabs tops.
I’ve been playing with minimal templates a lot. (In fact, as of now the only thing not based on minimal on my system is sys-usb…because I have no idea what to do with that one.)
One thing that comes up, a lot when trying to regenerate the templates is the system refusing to do so because such-and-such template (call it deb11a-net, just for instance) is “in use” because it’s a template for some other qube, or (worse) it’s the minimal dvm for some other qube (and that’s usually a lot of them).
Certainly, in a script you can temporarily re-base the affected qubes, rebuild the one you’re interested in, then switch them back…but in that case you have to hard write those qubes into the script, and if you add new qubes [and I gather you do, a lot, because you’ve compartmentalized with a very fine grain], you have to maintain the script.
I don’t imagine you actually do it that way. I can imagine you’ve written a script to do a qvm-ls, hunt for references to the template (or dvm template) you want to re-build, switch them temporarily to a dummy template, rebuild, then switch them back (by hunting for references to the dummy, which should be a qube you never actually use). I’ve been thinking about doing this, actually. For now I have things hard coded, most places, with commands referencing the dependent VMs by name. But I want to get to fully automated, like you are.
Certainly you have to do something about this or you’d never be able to walk away from your system while you were maintaining it!
Is one of these basically what you did, or do you have some other solution?
My scripts are arranged in an hierarchy. The top-most one is called build-all-templates and it currently looks like this:
#!/bin/bash
ORG_TEMPLATE_NAME=debian-11-minimal
NEW_TEMPLATE_PREFIX=debian-11
build-deb-min $ORG_TEMPLATE_NAME $NEW_TEMPLATE_PREFIX
build-deb-usb $NEW_TEMPLATE_PREFIX
build-deb-net $NEW_TEMPLATE_PREFIX
build-deb-cacher $NEW_TEMPLATE_PREFIX
build-deb-salt $NEW_TEMPLATE_PREFIX
build-deb-web $NEW_TEMPLATE_PREFIX
build-deb-brain $NEW_TEMPLATE_PREFIX
build-deb-jekyll $NEW_TEMPLATE_PREFIX
build-deb-heads $NEW_TEMPLATE_PREFIX
build-deb-lib $NEW_TEMPLATE_PREFIX
build-deb-mail $NEW_TEMPLATE_PREFIX
build-deb-office $NEW_TEMPLATE_PREFIX
build-deb-signal $NEW_TEMPLATE_PREFIX
build-deb-element $NEW_TEMPLATE_PREFIX
build-deb-teams $NEW_TEMPLATE_PREFIX
build-deb-vault $NEW_TEMPLATE_PREFIX
build-deb-rdp $NEW_TEMPLATE_PREFIX
As you can see this script has two variables at the start: ORG_TEMPLATE_NAME is the name of the Qubes OS provided template that build-deb-min will install, clone and subsequently remove again. NEW_TEMPLATE_PREFIX is how the name of all my templates start.
As outlined in my note these build-deb-xxx in turn clone from the -min template just created and then call add-feature-xxx scripts to install specific capabilities (net, audio, usb, qt, …) or programs (libreoffice, vlc, calibre, …). But that’s just a side note and not relevant to your question.
Of course I have encountered your issue. In a nutshell what I do is this:
build-all-templates
debian-11 then I change the prefix in the script to deb-11 or vice versa.qvm-ls --field=name, template > tmp to list all qubes with their templatestmp file I then remove all lines that are actual template qubes, named disposables, standalones and dom0 properqvm-prefs at the beginning of each linedebian-11 that is part of all template names with template deb-11
qvm-shutdown --all --wait at the beginning and qvm-start sys-usb at the endchmod +x tmp and run itBecause all qubes are shutdown while you do the change you won’t run into ‘in use’ errors. Don’t worry about your disposables either, since they are based on other qubes that in turn are based on templates (which will be changed in the script). For extra points you add qubes-prefs default_template deb-11-min at the end of tmp and qvm-remove -f debian-11-xxx calls for all the templates that are now unused / unneeded.
I actually described this before and another forum member posted an improved generic version you might want to check out.
Finally I feel obliged to point out once more that the thing I am doing and describing here is a poor mans solution to a problem that is far more elegantly solved using salt. However the strong response it is getting seems to indicate that it may be a bit more accessible.
Yep, that’s another way of doing it, and quite feasible for me, actually.
My big script defines two prefixes now: deb11m and deb11a. m stands for minimal, and a for app. Now the 11a templates ultimately spring from the minimal template but they all start with so much stuff it didn’t seem right to me to continue to call it 11m. (Basically 11a is the bare minimum I’d want to deal with as a user.) Also, they alphabetize cleanly into two groups: templates for system level VMs, and templates for “user level” VMs–handy in menus and the manager (which I do use a lot since it shows me multiple VMs at once and it’s easy to do a side-by-side comparison (even if it’s actually over-and-under).
I could always just change these two to something different (then next time change them back) and I’d be close to what you’re saying at least in concept.
I thought I had read this entire thread, but I must have got overloaded because I didn’t remember the prior description you referenced. Sorry about that!
I agree about salt. It looks like it could be wonderful, but I simply can’t understand the documentation because it talks about entities (columns, etc.) without relating them to what it is I am actually trying to configure (and if it’s not something made for Qubes that is quite understandable, but doesn’t make it easier). What corresponds to a VM Template I am trying to create? I dunno.
Lots of food for thought here; thanks!
I finally got to this
Unfortunately, no matter how many hoops I jump through the damn thing is unfindeable.
When I try to issue wget, it first tells me I already have the key ring then it says it can’f find ‘deb.librewolf.net’
I wish people would just use a damn regular install sequence instead of overcomplicating it with this crap.
I thought it is not worth to open a new topic on this and since it is part of my auto deb-mini tpl script I place it here.
I tried to make a generic function for gpg key download and apt update. Beside the well known Signal case, I picked Sublime and Librewolf. Now, I wonder about their installation instructions.
(Installation on Debian based systems – LibreWolf)
wants to save the gpg key to
/usr/share/keyrings/
and for the apt it is suggesting a .sources file
/etc/apt/sources.list.d/librewolf.sources
with a Signed-By: /usr/share/keyrings/librewolf.gpg link.
(Linux Package Manager Repositories)
gpg key instructions points to
/etc/apt/trusted.gpg.d/
and the apt wants a .list
/etc/apt/sources.list.d/sublime-text.list
My question what are the differences? Why, historical reasons, more generic, more robust…? Any pro and cons?
Any pro cons related to Qubes OS, or minimal templates?
Thanks
ok, found it:
https://manpages.debian.org/bullseye/apt/sources.list.5.en.html
side note: apt-key(8) will last be available in Debian 11 and Ubuntu 22.04.
Thank you for doing this @Sven. Already recreated most of my qubes using this method. Very easy to modify and create templates as needed. Hopefully this method works into the foreseeable future.
Hi mini-template users,
what do you think about a simple table which helps everyone to find the proper packages?
Something like:
Program or Feature: Signal
Required package:
Qubes OS release: 4.1
Debian release: 11
Comments: …
I think that’s a good idea. How would one go around documenting the required packages on a debian/fedora system? Does apt/dnf offer such a table view?
You mean somethimg like this?
Yeah, this was my inspiration. But now, I am looking for a place to store this is a more structured way. Maybe a kind of table. I would skip the customized base line template since this will be very individual but the other elementary qubes (network, usb…) and the “application” qubes could be documented in a predefined table or matrix.
If I find some supporter I would like to ask the community to add and maintain / verify the packages over time.
i.e. if you know how to make minimal template for Signal you should be able to clone it for Session, Threema, Element… with that we extend the list easily and new mini tpl users get a good structure to start with.