Tool: Simple Set-up of New Qubes and Software

The package is indeed there - not sure why @Bop667 did not find.
You don’t say in what way the install did not work.

Once downloaded, and PGP key verified, confirm package is properly
rpm -qi PKG will show the signing key.
Copy to dom0 as docs:
qvm-run --pass-io <src-vm> 'cat /path/to/file_in_src_domain' > /path/to/file_name_in_dom0

Confirm again in dom0 with rpm -K /path/to/file_name_in_dom0

To locally install a package you specify the path:
either full - sudo dnf install /path/to/file_name - or , if in the same directory, sudo dnf install ./PKG


This looks like great progress on a longstanding issue:

Thanks, unman!


Except that Marek started with a concern about the scalability of this
sort of approach - in terms of vetting and maintaining this sort of
That’s been highlighted in other threads where this approach has been

I tried to use sudo qubes-dom0-update 3isec-qubes-task-manager, and got this error

But it worked with downloading the rpm and copying it to dom0

NordVPN, as they offer a free thirty days, and hopefully would allow the first updates to work, not hang, and so on.

Please include the documentation on how to control NordVPN inside the Qube as a doc file.

Thank you for your work.

@unman thank you for doing this, it’s a very nice step forward! You won’t see that but your original post has accumulated 13 likes so far, which doesn’t translate into the email interface but indicates lots of folks appreciate your work.

Since you are asking for ideas, here is one that is on my “someday maybe” list, but you might just be the right person to do this between breakfast and lunch :wink:

I believe I am not the only person who wants their dom0 theme, icon, font and DPI choice to apply to all qubes. I have some bash scripts that basically:

  1. copy ~/.gtkrc-2.0 and ~/.config/gtk-3.0/settings.ini from dom0 to /etc/skel of all templates
  2. apply my DPI choice to /etc/X11/Xresources/x11-common Xft.dpi
  3. copy the respective theme, icon set and font from dom0 into all tempaltes
  4. shut down all qubes and templates
  5. make each qube “refresh” the files in their ~/ with the ones from /etc/skel

… this takes a while and is not fully automated. I also haven’t figured out yet how to programmatically adjust qubes that run a settings daemon. I only have one of those and just run gnome-tweaks manually there.

Long story short: it would be splendid to have a salt formula that applies whatever theme, icon set, font maybe even DPI setting is active in dom0 and applies it to all (Linux-based) qubes. This way especially new users could simply make their choices in XFCE and then run the salt formula to apply everywhere (for that to work the ‘values’ would have to be retrieved from the XFCE settings daemon).

Anyway, just an idea. Having this would allow to switch e.g. from a light to a dark theme and back more automatically. It would still take several minutes depending on the number of qubes, but it would be far superior to the current state of things.

1 Like

True, but there’s one crucial difference between this and and all the other options that have been discussed:

What you’ve done actually exists. :wink:

Most progress happens incrementally. The first few versions are pretty rough, and early adopters struggle. But without those early versions and struggles, we would never get to the clean and polished mature versions. So, don’t sell yourself short. The perfect is not the enemy of the good, but rather its descendant.

I fully agree with @adw and would like to add my own observation from my professional live. I am one of three original authors of a software library that gets used in cars. Each new functionality was first discussed in a group of stakeholders (car makers, their suppliers …). Often those discussions would drag on for a long time because it was difficult to find a consensus on the “right” approach forward.

The way this was often resolved was by us (the authors) picking one approach and actually implementing it. The difference now was that there was something that could be observed, criticized and improved upon. I don’t claim that this always resulted in the best possible outcome, but it got things moving and progress was made.

So something imperfect that exists and can therefor be evaluated and improved upon is (at least in my eyes) always better then a potential perfect solutions. Case in point: I’d love to have something like Qubes OS running on 100% free and open hardware while still being able to run all the software I need for my job. That doesn’t exist. What does exist is Qubes OS on x86. Not perfect, but far better then anything else I’ve seen or nothing at all.


My thoughts exactly, @Sven. We should never underestimate the power of second-order (and, in general, n-th order) effects. I can imagine another community developer coming to rely on a rough-and-ready beta version of some tool, eventually getting fed up with its limitations, and one day saying, “Enough is enough! I’m going to build a better version of this thing.” But without the rough early version, they might have never even started using Qubes in the first place because the barrier to entry was too high. Often, putting something out that there people can play with inspires them to make contributions of their own.

I can think of many cases where I’ve identified bugs, limitations, and missing features in things that I would never have been able to create myself in the first place. It’s practically a daily occurrence. But if that thing didn’t already exist, I probably wouldn’t even know what I was missing to begin with.

I can understand @unman’s concern about this approach having scalability problems in the long run. However, such trials can still be quite valuable. We often find ourselves in a situation where options A, B, and C are all available to us, but since we don’t know which will turn out to be fruitful (and lack the time and resources to try them all), we’re paralyzed by indecision. If someone actually takes the step of trying out option A, even if we know beforehand that it’s a long-term dead end, then we get to see how users interact with it, which might allow us to glean more information about the problem space. Armed with that new knowledge, we might then be able to see that option B has a much higher chance of ultimately bearing fruit than option C down the line, giving us a reason to finally make a significant investment in one option over the other.


split reversed – sorry for noise

Well, again, someone tied their package to gpg…and again I cannot fricking install it.

Even though I copied your key information to the specified directory, I get this when I try to install qubes task manager:

warning: 3isec-qubes-taks-manager-0.1-1.x86_64.rpm: Header V4 RSA/SHA512 Signature, key ID 4731b36c: NOKEY (I hand typed that, since it’s in a dom0 window; pardon any obvious typos).

I can run the gui but it refuses to install anything because–missing gpg stuff.

I guess I need to follow the policy of ignoring anything having to do with gpg.

(I hasten to add (but don’t dare do it via edit) The other instance was Librewolf, having nothing to do with you, unman.)

OK, this is WEIRD.

The missing gpg file is supposed to be on sys.firewall, apparently, in /var/lib/qubes/dom0-updates/etc/pki/rpm-gpg and its RPM-GPG-KEY-unman.

So I put the file there…it is in company with a large number of RPM-GPT-KEY files.

As soon as I start trying to install the cacher, that directory empties out. Completely. And it won’t come back until I close the window that opens up to do the install, cd …, then cd back into rpm-gpg–and when it comes back the unman file is missing. So sys-firewall is systematically wiping out the entire directory the file is supposed to be in when it tries to do the install.

I also tried putting the file on the dvm template sys-firewall is based on…makes no difference (that directory, on that system, I had to create).

Me being confused about the context of @SteveC's posts

Hi @SteveC I took the liberty to move your recent posts into their own thread in ‘User Support’. It is apparrent to me that you struggle adding PGP keys for third party repositories in an RPM based system (Fedora likely). Being mostly a Debian user myself, I have little experience to share. However a web search shows this: rpm --import <YOUR_PUBKEY_PATH_HERE> … maybe give it a try?

If not there should be plenty of folks around here able to help you out.

1 Like

Actually, I’m using Debian.

But this thing needs to be installed in dom0–the steps given explain that–and of course that’s Fedora.

It appears that some step was missed in the original explanation, about having to install the key in sys-firewall (which for me is a debian-minimal based qube) as well as in dom0. Unfortunately, without that explanation, I’m pretty well hosed; it’s behaving erratically as I described above.

Note about the new thread Sven created and then merged back into this one.

(For anyone coming into this new thread, it resulted from my attempts to install the new salt-based qube generator, here: [note: I can’t find the original post now, but it was the one unman wrote detailing his first cut at automatically installing and configuring certain VMs.)

Hi @SteveC, sorry for not getting the whole context. This happens a lot lately. I too use a debian-based sys-firewall (sys-pi-hole actually, but that should be irrelevant in this context – important is that qubes-core-agent-dom0-updates is installed).

Here is what I did:

  1. created [dom0] /etc/yum.repos.d/3isec-dom0.repo with the contents listed on the website.
  2. imported and moved unman’s signing key to /etc/pki/rpm-gpg/RPM-GPG-KEY-unman (I had his key already in my keyring and previously verified, so I just exported that key and moved it into dom0 – you should make sure that the key you use has the fingerprint 4B1F 400D F256 51B5 3C41 41B3 8B3F 30F9 C8C0 C2EF)
  3. [dom0] sudo qubes-dom0-update
  4. [dom0] qubes-task list
  5. [dom0] qubes-task info mutt
  6. [dom0] qubes-task install mutt

… this is where I see the same ‘NOKEY’ error you do in the terminal window of my sys-pi-hole:

Unable to detect release version (use '--releasever' to specify release version)
3isec Qubes Dom0 Repository (updates)                                              3.3 kB/s | 2.4 kB     00:00
Fedora 32 - x86_64 - Updates                                                       2.4 kB/s | 4.4 kB     00:01
Fedora 32 - x86_64                                                                  10 kB/s | 5.0 kB     00:00
Qubes Dom0 Repository (updates)                                                    3.2 kB/s | 2.7 kB     00:00
Dependencies resolved.
  Package                       Architecture        Version                   Repository                       Size
  3isec-qubes-mutt              x86_64              1.0-1.fc32                3isec-dom0-current               11 k

Transaction Summary
Install  1 Package

Total size: 11 k
Installed size: 8.3 k
DNF will only download packages for the transaction.
Downloading Packages:
[SKIPPED] 3isec-qubes-mutt-1.0-1.fc32.x86_64.rpm: Already downloaded
warning: /var/lib/qubes/dom0-updates/var/cache/dnf/3isec-dom0-current-42d3c1bc016485fd/packages/3isec-qubes-mutt-1.0-1.fc32.x86_64.rpm: Header V4 RSA/SHA512 Signature, key ID 4731b36c: NOKEY
3isec Qubes Dom0 Repository (updates)                                              3.7 MB/s | 3.8 kB     00:00
Importing GPG key 0xC8C0C2EF:
  Userid     : "unman (Qubes OS signing key) <>"
  Fingerprint: 4B1F 400D F256 51B5 3C41 41B3 8B3F 30F9 C8C0 C2EF
  From       : /var/lib/qubes/dom0-updates/etc/pki/rpm-gpg/RPM-GPG-KEY-unman
Key imported successfully
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
'/usr/lib/qubes/qrexec-client-vm dom0 qubes.ReceiveUpdates /usr/lib/qubes/qfile-agent /var/lib/qubes/dom0-updates/packages/*.rpm' failed with exit code 1!
Fetching updates failed with code 1; press Enter to exit

@unman the way I understand this error message is that the package 3isec-qubes-mutt-1.0-1.fc32.x86_64.rpm is signed with key 4731b36c which is different from your signing key ending in c8c0c2ef. Correct?

Note about the undone split

I see now that @SteveC’s post and this follow-up do belong into the original thread so I will undo the split.

Thanks for re-merging; I felt a lot of context got lost in the split.

Actually what I need are instructions for installing unman’s key in sys-firewall. The other part seems to work, but sys-firewall goes psychotic and loses its key directory when dom0 uses it to try to install one of the packages (which in my case is the cacher; I have no idea what “mutt” is even for).

@SteveC first I thought the key is different:

  • key ID 4731b36c: NOKEY
  • Importing GPG key 0xC8C0C2EF:

The key get’s imported from /var/lib/qubes/dom0-updates/etc/pki/rpm-gpg/RPM-GPG-KEY-unmanKey imported successfully. The same issue is also observed by @renehoj here.

But then I searched for key 0x4731b36c using and it returns key 0xC8C0C2EF! Then I checked with my local GPG instance:

user@vault:~$ gpg --edit-key 0x4731b36c
gpg (GnuPG) 2.2.27; Copyright (C) 2021 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

pub  rsa4096/8B3F30F9C8C0C2EF
      created: 2016-06-25  expires: never       usage: SC
      trust: marginal      validity: unknown
sub  rsa4096/6233CD8FA59A87A8
      created: 2016-06-25  expires: never       usage: E
sub  rsa4096/FDD1B8244731B36C
      created: 2016-06-27  expired: 2022-06-30  usage: S
[ unknown] (1). unman (Qubes OS signing key) <

…turns out FDD1B8244731B36C is the signing key that corresponds to unman’s public key 8B3F30F9C8C0C2EF and IT IS EXPIRED! So this is my new theory: the check fails because the key is expired.

Also: a quick laugh at stuff one finds searching the web for NOKEY. …they are delicious by the way!

Calling @Demi since she has commented on this issue and is therefore likely knowledgeable on how to resolve this.

@unman time to un-expire your key :slight_smile:.

All good…but when I try to install the cacher via the fugly gui (unman’s description), a sys-firewall window pops up to display the process and it fails to install because it cannot find his key file on sys-firewall

It’s not complaining the key is expired. It’s complaining that there IS NO KEY FILE.

My attempts to install the file failed, as described in Post #19; the file disappears just as sys-firewall tries to reference it.


This is the third time I’ve asked this, and I’m starting to feel like people are ignoring the important part of my issue. The expired key throws warning messages, THIS causes total failure of the install.