Check both of the policy files - you should see sensible values for
Whonix and templates in /etc/qubes/policy/30-user.policy
1 Like
Thanks for your feedback.
It would be nice if you show us a salt how to on:
- software example with an external apt
If you show us a salt approach on how to download a gpg key (curl / wget), add the apt repo and install the software I (we) could simple reuse your syntax for other programs which requires an external apt repo.
Good candidates are Signal (wget), Session (curl), Librewolf (curl), sublime-text (wget), Syncthing (curl) …
- an AppImage example
make AppImage folder in home/user/home/
download AppImage and set permission
add app menu (!) to make it accessible directly from the Qube launcher
Testing candidates are Tutanota, Session …
This would be a big help for me to see how it works and compare the salt approach vs. bash.
I very rarely do this - partly because the users who I’ve worked with so
far use apt-cacher-ng to restrict access from the templates. (It’s
simply done in the acng.conf file to restrict the proxy to specified
update sources.)
My normal pattern is to provide the key and process it in place.
I’ll let you have an example of both approaches tomorrow.
Thanks - I’ve already done signal and syncthing: I’ll look those out,
and have a look at the others.
I don’t use AppImages, but I’ll have a look
Thanks for these suggestions.
1 Like
looks like I found the error of my first cacher install. After that I renamed cacher to sys-cacher and the entry in /etc/qubes/policy.d/30-user.policy still pointed to >>> cacher (as sys-cacher instead)
That’s not an unreasonable thing to try to do.
When I tried creating the cacher “manually” (I never could get it to work), I named it sys-cacher. And I think this one should be named that way as well.
The problem is, I don’t know if I’d have to go into every single template and (re)set something if I rename “cacher” to “sys-cacher” or not. I think I could find all of the “global” settings now (but I’ve been wrong about that in the past).
On that, with bookworm (thanks @unman) I agree it seems that the better approach is to collaborate on extrepo and extrepo-data (landing in extrepo-data-offline package) to fill that goal. Out of the box, extrepo with extrepo-data-offline installed permits to install Signal repo data, but doesn’t contain element nor Session, while containing Syncthing (others I do not know)
The missing magic from dom0 or with cacher (accepting to modify the templates even more) would be to drop additional helper scripts in the templates it modifies so that a reapply-configure could modify the repositories definitions to be apt-cacher-ng compliant.
But yeah, extrepo seems to be the way to resolve https://forum.qubes-os.org/t/curl-proxy-wget-proxy-scripts-in-templates-so-users-can-add-gpg-distro-keys-linked-to-added-external-repositories if cacher could be helped a little bit into having those repositories and keys installed locally, and cacher_compliant_repo_changer applied, so users can just sudo apt install signal-desktop and others.
1 Like
@whoami that looks very cool!
The things @unman and you are working on are great as “proof of concepts” and I would personally use both of them because I’d be able to audit your bash script as well as unman’s salt formula AND because I am not a high-risk user (if someone hacks my setup my life is not in danger). One could go so far and say that I don’t need Qubes OS but that I use it in order to learn about security concepts and protect myself from my own stupidity.
I would not recommend any member of the primary target audience of Qubes OS to use anything in dom0 that isn’t signed by the official Qubes OS project. It is clearly a goal for the project to have a trusted solution that enables custom configurations for non-technical users. This is why I find those “proofs of concepts” so important and useful. NOT as a CURRENT solution for actual non-technical users.
I wouldn’t publish my bash scripts because I don’t want to…
- train others to copy&paste / run stuff in dom0 they don’t understand
- accept responsibility to maintain and fix those scripts for all times
- potentially be the reason an at risk user gets into trouble
I have solved the problem, I had to copy your key like described here into dom0. Downloading the pgp qube worked but my next problem is that I don’t fully understand how I can put my login data in the template? When I try to use the terminal I was asked after a password to get root acces, but there wasn’t any passwords given in your documentation.
After the installation of the 3isec-qubes-task-manager went very well on my Lenovo laptop, I now noticed, that it runs into errors on my Nitro-PC.
-rw-rw-r-- 1 TheGardner TheGardner 20845 Aug 30 19:40 3isec-qubes-task-manager-0.1-1.x86_64.rpm
[TheGardner@dom0 Downloads]$ sudo dnf install ./3isec-qubes-task-manager-0.1-1.x86_64.rpm
Qubes OS Repository for Dom0 0.0 B/s | 0 B 00:00
Errors during downloading metadata for repository 'qubes-dom0-cached':
- Curl error (37): Couldn't read a file:// file for file:///var/lib/qubes/updates/repodata/repomd.xml [Couldn't open file /var/lib/qubes/updates/repodata/repomd.xml]
Error: Failed to download metadata for repo 'qubes-dom0-cached': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried
[TheGardner@dom0 Downloads]$ ls -la /var/lib/qubes/updates/repodata/
total 8
drwxrwxr-x 2 root qubes 4096 Aug 30 20:09 .
drwxrwx--- 4 root qubes 4096 Aug 16 22:42 ..
[TheGardner@dom0 Downloads]$
can’t get the rpm.file installed and indeed the /var/lib/qubes/updates/repodata folder is empty. So what exactly is wrong here? When will the repomd.xml be updated/downloaded? Assume it always happens, when a installation is in progress.
- desk is proper connected to the net…
- other updates working like a charm…
- did all previous steps as written by unman (on his 3isec webpage)
- rpm.file has it’s full size and fingerprint was ok
For the most part these are based on minimal templates.
Minimal templates do not have passwordless-root installed.
If you want root access, then you have to do this from dom0. Like this:
qvm-run -u root QUBE xterm
You can read about this in the docs
I never presume to speak for the Qubes team.When I comment in the Forum or in the mailing lists I speak for myself.
1 Like
If you rename the cacher, or clone it, (so that you have one that
operates over Tor and one over clearnet, e.g.), then all you have to do
is change the entries in /etc/qubes/policy/30-user.policy
Templates using the update proxy have no idea what’s on the other end
of the qrexec call.
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
This is a problem with your system unconnected with qubes-task.
I’ve seen reference to it before, but don’t recall a solution. (Perhaps
it was related to running out of disk space in dom0?)
You could try dnf clean all and then qubes-dom0-update?
When I comment in the Forum or in the mailing lists I speak for myself.
1 Like
Ah, that makes sense. (I didn’t know how you had implemented it.)
I tried and found a openvpn configuration file for manual setup from my vpn provider.
I downloaded everything and moved it to the sys-vpn template. I opened a root terminal like in the docs but I don’t understand to set up everything?
I only want to put my login data inside the template to at least use it 
Edit: I mean how can I come from installing the templates with your salt terminal to connecting to my vpn?
If you look in the Description, or in the Readme in /srv/salt/openvpn,
you will see instructions on how to proceed.
Neither make any reference to opening a root terminal.
Dont do anything in the template.
Copy your openvpn file(s) to sys-vpn.
Run the install script, either from the Qubes Menu (you may need to
refresh the application list) , or by opening a terminal in sys-net and
running the setup script in /home/user
1 Like
Ok. I moved the openvpn file in tar.gz format via
„Move to vm“ application in my sys-vpn template.
Then I refreshed my applications list and opened „ setup_vpn“ after I had restarted the template, but nothing changed. There is no connection, but I even never had to pick a town of the vpn. So I mean when I had the file in place in qubes and set it up, should I get any response? The connection is still not running …
Ok. I moved the openvpn file in tar.gz format via
???Move to vm??? application in my sys-vpn template.
Then I refreshed my applications list and opened ??? setup_vpn??? after I had restarted the template, but nothing changed. There is no connection, but I even never had to pick a town of the vpn. So I mean when I had the file in place in qubes and set it up, should I get any response? The connection is still not running ???
This is like pulling teeth.
Have you moved the file to sys-vpn? If so, it’s a qube, not a template.
What happened when you ran setup_vpn?
Exactly what happened?
Seriously, tell me exactly what happened?
Look in /rw/config/vpn.
Are there openvpn files there?
Have you read this?
1 Like
Excuse me, sorry to butt in but - by this:
did you perhaps mean: you relocated the file you downloaded (moving it again from VM to VM) which was in tar.gz format (if you are new to Linux - and this is not a Qubes issue by the way - a .gz or a .tar.gz file is similar to a zip which you may already know amounts to a compressed file) to someplace but have not yet extracted/decompressed the contents? I’m thinking that perhaps that will need to be done before either Network Manager or OpenVPN (depending upon how you are proceeding) will be prepared to cope with any datafiles contained within (if as I suspect it’s still compressed) for setting up the VPN connection.
I looked in the /rw/config/vpn direction and found only a file named qubes-vpn-handler.sh, my unzipped open vpn file ( I use perfect privacy btw. ) is in sys-net in the direction /home/user/qubesincoming/
At this point I started the Programm setup_vpn.
But after starting it, nothing changes. I waited several minutes to make sure nothing popped out after some time. So I get no response, I don’t get any error messages or something. I try to restart the qube but i get everytime the same result.