How to update unman's apt-cacher-ng package

User Support
1

I have installed apt-cacher-ng via @unman’s shaker notes. He mentioned he will update it soon.

How can I update my cacher qube with such an updated configuration?

1 Like
2

Let’s see what unman will answer for this. I was thinking about that also in the past and thought, it would come through a dom0 update and then I “probably” have to uninstall the cacher-ng package and install it again via unmans manager-gui…

could be wrong… Let’s see, what replies come in here…

1 Like
3

There will be no need to uninstall the package.

The idea is that any updated package will update existing installs - so
for cacher the plan is to ship an updated acng.conf and fedora mirror
list, and these will be salted in to the template-cacher.
The thing I am unclear on is what to do about other templates -
ideally I would want to change the settings in every fedora template,
but there is no way of specifically targeting them, so every template
will have to be opened. This is really suboptimal.

I am trying to think of ways around this - any ideas are welcome.

I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.
4

Post cannot be empty

5

What settings? To change repo files?

What do you mean by “opened”?

6

Here’s what I ended up doing…since I don’t understand the issue here, what I’m about to say may or may not be relevant. Maybe it will trigger a useful thought in someone.

On updating, my initial “ancestral” mimimal template checks to see if sys-cacher exists or not (there’s an important caveat here I’m going to go into later; for now just assume that this is possible from inside the template where the salt scripts run for a given target.) If it finds it, it changes the relevant repository definitions appropriately, if not, it changes them back to their default settings. That’s the very first thing my “configure” salt file for that VM does. After that, all of the installs/updates will do the right thing.

Since every one of my configure files includes the configure file for its parent, that means I can update deb11a-wifi-ffx (just for instance) and the first thing IT will do is check for the existence of sys-cacher and adjust its repo files accordingly.

This way, I could remove sys-cacher (and remove the policy that causes dom0 to try to use cacher) at any time, and the qubes that formerly used the cacher…won’t, the next time they try to do something. Or vice versa. No need to rewrite every single template’s repo files, all at once.

I am sure something similar could be done if you’re using bash scripts.

My adaptation of unman’s salt recipe only creates the sys-cacher template and appVM; it doesn’t go starting up everything to modify the repo files. But that only works because every dang near every qube on my system is under the control of my salt scripts (the exception being installed templates like debian-11-minimal or fedora-36-xfce) and I have the includes set up the way I do. (Thus, what unman did is correct for the general case since few are this “salty”; I am not criticizing his solution.)

But now the caveat. If you are running in the dom0 environment, it’s pretty trivial to check for the existence of a VM. If, on the other hand, you are running in some template’s environment…well, I have no idea how to do it. So I actually create a salt grain with the information in it–any salt script can see THAT. If I were to remove/disable the cacher, I’d have to alter the salt grain (and again to re-enable it).