Is there any chance to remove (at least) the 3isec-qubes-sys-cacher package again? Would like to do this, cause somethings went wrong with the cacher install and now all my updates for the templates fails (always getting those "failed to fetch http://HTTPS… messages // sys-firewall is systems update VM).
Or with other words, which files do I have to edit to set the old updates settings back, so I get the updates working again and can try to install the cacher package again.
There’s a README in /srv/salt/cacher.
sudo dnf remove 3isec-qubes-cacher should do the right thing.
I have the same error code and in my dom0 terminal I get this response
Do you had solved the problem?
The remove worked - but the updates not in the first. After I deleted a (the) $type… line in /etc/qubes-rpc/policy/qubes.UpdatesProxy file all updates are working again as previous.
Try to install the cacher-ng a second time. Let’s see, if I get it running this time.
I’m not sure I follow @unman.
Anything taken from dom0 output could be used to script within salt, from my understanding. “properties of the qube”, even if not provided by salt itself, can be provided from dom0 where the salt script can take it as input?
Currently, I am working on something similar but it is based on simple bash scripting only.
First, some checks for the official and the baseline template.
Afterwards a list of all available templates; quick selection via index…
At the end a last “yes” confirmation to launch installation routine.
I also highly appreciate @unman 's work but I also wonder a bit about your statement since you always argued that you do not want to make / support such ready to use automated installation routines / tools. I remember your “… give someone a fish vs. learn how to fish” statement. I have followed your advice and did the hard way - learning fishing - coding based on your tips automate debian-minimal based template creation. Do not get me wrong, I have learned a lot and this was not a waste of time but I guess I still need 1/2 - 1 year to reach my goals.
Up to know, I am not able to do salt coding but now I am questioning myself if I should continue my work or “just” supporting unman project since this is what I ultimately try to achieve.
With my self-developed script and Mini-templates Required Packages (Wiki) I am trying to do somehow similar but I am definitive not the best person do drive such an project. Therefore, my questions to @unman What are your plans here? How far do you want to go? How many applications / programs do you plan to add? Can we setup a community driven maintenance and extension of your work or will it be a prototype to inspire others?
The target has to be able to deal with the salt calls.
Can you update Windows qubes with the GUI updater?
Can you update templates or standalones with other distro/OS from
updater?
I cant see that image.
What is your problem?
The package doesn’t touch /etc/qubes-rpc/policy/qubes.UpdatesProxy, and
in fact overrides it.
It sounded as if the templates had repo definitions updated but the
policy file wasn’t written/updated. Yours is the first report I’ve had of
this happening, and I’m not clear why it might happen.
What you have learned will not be wasted at all. You will have gained
knowledge in Qubes and in scripting generally: keep fishing.
You can think of these as kata.
That’s up to you. I think that something like this has more scope to be
adopted and easily audited than a set of bash scripts. ( I say this
because the salt used here is deliberately simple - almost any one could
look at these formulas and understand what’s going on, regardless of
their salt knowledge.)
This is a prototype - some packages work well, some have shown up things
that I had not encountered before - cacher dealing with Windows and
Whonix, for example. Some of these I’ve fixed, some I cant (at the
moment).
My plans are to keep working on things to ease the pain for new users.
If this project were to be adopted, that would be great. If not, I’ll keep
pushing it forward anyway, absent any alternative.
I’ll add as many packages as are proposed: I haven’t had many
suggestions yet. I have many more formulas that I’ve used in the past,
but haven’t yet packaged.
The packages here are on GitHub at https://github.com/unman/cacher, and the
Task Manager is at GitHub - unman/qubes-task
All contributions, comments, criticisms and improvements are welcome.
thats, why I don’t want to blame the task manager GUI for this. Will have an eye on the qubes.UpdatesProxy, after I ran the cacher installer (via the qubes-task-manager [GUI]) a second time.
Check both of the policy files - you should see sensible values for
Whonix and templates in /etc/qubes/policy/30-user.policy
Thanks for your feedback.
It would be nice if you show us a salt how to on:
Good candidates are Signal (wget), Session (curl), Librewolf (curl), sublime-text (wget), Syncthing (curl) …
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.
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.
@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…
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.