3isec-qubes-cacher-1.10-1 breaks Debian/Fedora TemplateVM updates

[unman]

I should have been clearer. I did run those tests from the cacher AppVM. I ran the same tests from other AppVMs as a way to verify other other AppVMs could connect, whereas the cacher AppVM could not. This was poor phrasing on my part.

All of which suggests that your template is lacking
qubes-core-agent-networking, or is irredeemably broken in some other way.

I’m going to repeat from last week:

1. Remove any reference to qubes.UpdatesProxy from /etc/qubes/policy.d/30-user.policy
2. Change the entry in /etc/qubes/policy.d/50-config-updates.policy from cacher to sys-net or sys-firewall - (or do this in GlobalSettings)
3. sudo dnf remove 3isec-qubes-cacher
4. qvm-remove cacher template-cacher

Check that the update proxy is set to sys-net (or sys-firewall, as you will)
Check that you do not have a cacher qube or template-cacher.
Check that you are able to update a template.
Check that the template for your management_dispvm is a fedora template (preferably fedora 40)

sudo qubes-dom0-update 3isec-qubes-cacher

Things to check:

1. The install completes without error.
2. cacher has network access.
3. The apt-cacher-ng service is running in cacher on port 8082
4. /etc/qubes/policy.d/50-config-updates.policy contains reference to cacher - you can see this in QubesGlobalConfig
5. The repository definitions in a sample template do not contain https:// entries

I never presume to speak for the Qubes team. When I comment in the Forum I speak for myself.

[SensibleBurrito]

I noticed that I can keep running the ‘sudo dnf remove 3isec-qubes-cacher’ in Dom0–the uninstall doesn’t seem to complete. Any tips on how to get it completely uninstalled?

[unman]

I noticed that I can keep running the ???sudo dnf remove 3isec-qubes-cacher??? in Dom0???the uninstall doesn???t seem to complete. Any tips on how to get it completely uninstalled?

That really isnt helpful - you’ve given no detail which would suggest
what problem you think you see. Nor have you indicated which of the
steps you have taken, and which checks you have made, with what results.

I have already told you how to uninstall the package, and how to roll
back any changes.
sudo dnf remove 3isec-qubes-cacher will try to remove the package, and
revert system changes.

Let’s think about what the package does:

1. It drops salt files in to /srv/salt/cacher
2. It clones a template, template-cacher, and creates a qube, cacher. (create.sls)
3. apt-cacher-ng and qubes-core-agent-networking are installed in the template (install.sls)
4. The cacher qube is configured (configure.sls)
5. The global preference is set to use cacher as update proxy by editing /etc/qubes/policy.d/50-config-updates.policy
6. The repository definitions are edited to replace references to https:// with http://HTTPS/// (change_templates.sls)
7. A salt pillar is created to hold the value for a caching proxy.

sudo dnf remove 3isec-qubes-cacher should roll back 7,6,5 and 1.
You can manually do, and check, this by the steps I have given you.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

[SensibleBurrito]

I assumed that I would only be able to run
sudo dnf remove 3isec-qubes-cacher once. I assumed after it was uninstalled, this command would not run, throw an error, or report that there was nothing to uninstall. I only mentioned this because it seemed like there was some remnant of this package somewhere because this command continues to run.

I installed the fedora-40 template. If uninstalling the package is just those 7 steps I’ll retry.

[SensibleBurrito]

For whatever reason, the template-cacher TemplateVM the 3isec-qubes-cacher package created from my debian-12-minimal TemplateVM did not have whatever configuration changes the upgrade-template-standalone.sh implements.

I’m pretty sure when I upgraded from Qubes 4.1.2 to 4.2, Stage 4 (Upgrade templates and standalone VMs to R4.2 repository) did complete without errors, so I’m not sure how or why this is an issue now

• I discovered this by
  • Reverting the settings in Dom0’s /etc/qubes/policy.d/50-config-updates.policy so that all @type:TemplateVM will update through my sys-net Qube instead of through cacher
  • Reverting the cacher https:// prefix in template-cacher’s apt lists
    sed -i 's^http://HTTPS///^https://^' /etc/apt/sources.list
sed -i 's^http://HTTPS///^https://^' /etc/apt/sources.list.d/*.list
  • Attempting to run apt update and apt upgrade, which surfaced

    Some packages could not be installed. This may mean that you have
    requested an impossible situation or if you are using the unstable
    distribution that some required packages have not yet been created
    or been moved out of Incoming.
    The following information may help to resolve the situation:
    The following packages have unmet dependencies:
    xen-utils-guest : Conflicts: xen-hypervisor-common but 4.17.3+10-g091466ba55-1~deb12u1 is to be installed
    E: Broken packages

    • Googling the error surfaced this: Update trouble debian 11 → debian 12 in Qubes-OS 4.2, which mentioned Restoring old R4.0 template to R4.2, which pointed to downloading and running upgrade-template-standalone.sh from within the problematic TemplateVM
      • Made it executable and ran it from template-cacher

        • It seemed to do things and completed without any errors

        • I was then able to re-revert the settings in Dom0’s /etc/qubes/policy.d/50-config-updates.policy so that all @type:TemplateVM would resume updating through cacher and re-revert the cacher prefix in template-cacher’s apt lists
          sed -i 's^http://HTTPS///^https://^' /etc/apt/sources.list
sed -i 's^http://HTTPS///^https://^' /etc/apt/sources.list.d/*.list

        • I was then able to update template-cacher and other debian templates through cacher without any issues

[unman]

I was then able to update template-cacher and other debian templates through cacher without any issues

Nice.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.