Cacher and unmanaged templates or hvm ones

I’ve tried following the various post yet present on forum, but final result of my experiments is that unmanaged templates (for cacher) or hvms are somewhat still unable to do “regular updates”, after installed cacher.

I think for simplicity we can follow just one of them (I think to be able to replicate it for the other), but I’m available to do a full test on everything, if it’s needed for troubleshooting purpose.

As yet reported, let’s take a oel 8 template as example:
I’ve tried adding and or commenting proxy in yum.conf (for localhost:8082), but it still cannot reach external internet.

My system configuration:

dom0~$ qubes-prefs updatevm

(custom) content of my 30-user.policy:

qubes.UpdatesProxy * oel-8-template @defafult allow target=sys-whonix

(before last line (with target=cacher))

but I’ve yet tried to put it to somewhat else (sys-net of sys-firewall), always without succeding.
Do You have any other experiences usefull to solve this problem?

Thanks a lot,

Sorry you are having trouble.

If you installed cacher using the package from qubes-task then two changes are

  1. The repository definitions are changed from https:// to
  2. An entry is made in /etc/qubes/policy.d/30-user.policy setting the
    default update for all templates (except Whonix) to cacher.

You must revert these changes.
The line you have inserted in 30-user.policy looks good.
Make sure that you revert the change made in 1 above. (You can either do
this manually in each qube, or do it with salt -
sudo qubectl --skip-dom0 --targets=QUBE NAMES state.apply cacher.restore_templates

(Also check the repository definitions in the Whonix templates - these
should not have been altered - if they have it’s a bug.)

Let us know how you get on.

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

Hi and thanks for Your support!

My troubles born just here…
I’ve read the shaker/cacher.spec at main · unman/shaker · GitHub
so I’ve exactly followed your suggestion:

  1. sudo qubectl --skip-dom0 --targets=oel-8-template state.apply cacher.restore_templates
  2. modified 30-user.policy for allowing oel-8-template to sys-whonix update

I’ve looked into (whonix) /etc/apt/apt.conf.d but I don’t see any strange addressing url…

But I’m sure in the template network is unreachble… also if I forcibly set net qube to anything different from (default) none.

At this point anyone can think that it’s a problem of this template… well if I clone a new one from the same original one from which I’ve created this one… it works perfectly (of course after slight enhancement of the user’ qubes policy); so my question is: why this template is gone wild, but if I regerate it now (after cacher.restore_templates), its brothers are working perfectly ?

For this reason, I’ve originally posted in @Insurgo other post about this matter… from my point of view it isn’t related to my specifical template, but from cacher internal design (or salt policy, I don’t know…).
Anyway, please let me know what do You think about it…
Thanks a lot.

18 posts were split to a new topic: Cacher (Apt-cacher-ng): issues with fedora updates