For a long while now we’ve been talking about methods of helping users set up
their systems, and install and configure software.
New users in particular find this difficult to deal with.
Look at the repeated posts in the Forum about how to set up a VPN.
Many of the guides that are produced involve users copying shell scripts
into dom0 or templates and running them, and it’s obvious that many
people still struggle.
Wouldn’t it be better if users could just install a package that did all
that set up for them?
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.)
I’ve set up a test repository, and started to upload some packages.
There’s also a tool and a fugly GUI - qubes-task-manager.
Currently there are packages for setting up:
split-gpg
split-ssh with multiple agents
a caching proxy
a MullvadVPN with wireguard
an openvpn gateway
a pihole standalone as a drop in replacement for sys-firewall
a disposable multimedia player.
a mutt qube.
Please send suggestions for other packages, and feedback.
Important stuff
These packages are installed in dom0 and run commands there. You’re
trusting me to do the Right Thing™. That said, anyone can download a
package manually, and examine the contents with rpm2cpio PKG |cpio -idmv
These packages generally create new templates cloned from debian-11-minimal.
There’s some information available about each package. Should be improved.
Did I say the GUI was fugly?
If this is better in “General Discussion” or with a different subject,
please change.
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
Actually, this looks like an excellent way to learn Salt…for example, I could grab the stuff for the caching qube (which I never could get to work; likely because I don’t know where it fits between sys-net and sys-firewall), run it, and have on the one hand 1) salt files and 2) what they produce. I can then reverse engineer and figure out what does what rather than trying to figure out the documentation, which seems to be written on the premise that the reader already knows the information and just needs a reference.
I tried following the guide and using qubes-dom0-update to install the package, the package is found and the PGP key is important, but it fails and says I need to use dnf directly. I tried running dnf install which doesn’t work.
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
signed: 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
Except that Marek started with a concern about the scalability of this
sort of approach - in terms of vetting and maintaining this sort of
repository.
That’s been highlighted in other threads where this approach has been
mooted.
@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
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:
copy ~/.gtkrc-2.0 and ~/.config/gtk-3.0/settings.ini from dom0 to /etc/skel of all templates
apply my DPI choice to /etc/X11/Xresources/x11-common Xft.dpi
copy the respective theme, icon set and font from dom0 into all tempaltes
shut down all qubes and templates
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.
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.
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.
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.
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.
