I have bought into the multiple templates scenario, and hence a local updates cache would be useful - so, I’d appreciate knowing the options, recommendations, setups, etc. Specific issues I can think of so far are:
Thanks.
First of all, an update cache could potentially leak the installed software and its versions between qubes.
Other than that, neat idea but when using a normal setup with templates and AppVM’s, isn’t the template patched once and the AppVM’s just use it’s patched base and don’t need updates, thus reducing the need for a cache? (Haven’t looked into it too much)
Well a cache will tell you what packages have been cached, but not which
template is using them or what qube is using them, so it doesn’t leak
information between qubes in any meaningful way.
There are various options - a squid proxy, or apt-cacher-ng.
Look at notes/apt-cacher-ng at master · unman/notes · GitHub for an
explanation of how to set up a simple caching proxy in place of
tinyproxy.
It handles Fedora reasonably, and Debian and Arch very well. Once it is
in place, you set it as default proxy via:
/etc/qubes-rpc/policy/qubes.UpdatesProxy
and pretty much forget it.
Works with http and https (although that needs rewriting in the client
as you will see) - put behind a Tor proxy and works with Tor and .onion
sites.
I have salt config for this if you want.
Thanks @unman . Yes, please - would appreciate the salt config.
Will this also handle other repos (e.g., winehq, tlp, whatever)?
Thanks.
There are notes and a salt config here:
and a more extensive note:
apt-cacher-ng will work with most repos accessible by http or https: you
will need to write some regex to capture the layout and calls, and
undoubtedly there is some fine tuning on almost everything.
Thanks unman!
A couple of questions re. notes/apt-cacher-ng (I’ll get to salt later… 
):
Thanks.
I mask every service in a Debian template, and then unmask and enable
where I want it. Habit.
You can use apt-cacher-ng to cache the calls from a system that
provides the dom0 update service , which can be the same machine - but
the service is distinct.
Just some questions about your apt-cache-ng settings:
At least how many space do you recommend for the apt-cache-ng proxy-VM if someone try to follow your apt-cache-ng docu?
If i’d like to based the apt-cacher qube on minimal debian, what are the essential packages to install to the AppVM besides what you mention in the docu? I think like these packages: qubes-core-agent-networking and likes.
Should i provide network to the created apt-cache qube?
What should be the default network qube for the apt-cacher qube? sys-firewall, or sys-net?
Can i lower the max. memory to 2000MB? Or does it need the default 4000MB?
Thanks any help!
Depends on your use.
On this machine I currently have about 20G cached - mainly Debian and
Ubuntu, with about 2G Arch and Fedora. (But I’m caching across different
releases.)
If you bind-dir on to private storage, as I suggest, then setting 30G
private storage should be more than enough.
Thanks!
Can you address maybe the other questions too?
You haven’t asked me, but here are my data points for you to consider:
Thanks!
The more suggestions the better!
Just a quick question: when installing apt-cacher-ng should i allow the http tunnel, or not?
This discussion is very useful for me, thanks for sharing! 
Following the instructions here I’ve been able to get apt-cacher-ng working for Debian and Ubuntu templates. I am a bit stuck when it comes to Fedora templates though.
From Qubes Updater:
Updating fedora-33
Error on updating fedora-33: Command '['sudo', 'qubesctl', '--skip-dom0', '--targets=fedora-33', '--show-output', 'state.sls', 'update.qubes-vm']' returned non-zero exit status 20
fedora-33:
----------
ID: /usr/lib/rpm/macros.d/macros.qubes
Function: file.managed
Result: True
Comment: File /usr/lib/rpm/macros.d/macros.qubes is in the correct state
Started: 13:42:09.798235
Duration: 47.543 ms
Changes:
----------
ID: dnf-makecache
Function: cmd.script
Result: False
Comment: Could not create DNF metadata cache
Started: 13:42:09.847284
Duration: 1928.487 ms
Changes:
----------
ID: update
Function: pkg.uptodate
Result: False
Comment: One or more requisite failed: update.qubes-vm.dnf-makecache
Started: 13:42:12.891596
Duration: 0.013 ms
Changes:
----------
ID: notify-updates
Function: cmd.run
Name: /usr/lib/qubes/upgrades-status-notify
Result: False
Comment: Command "/usr/lib/qubes/upgrades-status-notify" run
Started: 13:42:12.891697
Duration: 2327.912 ms
Changes:
----------
pid:
1697
retcode:
1
stderr:
Error: Failed to download metadata for repo 'updates': Cannot prepare internal mirrorlist: Curl error (56): Failure when receiving data from the peer for https://mirrors.fedoraproject.org/metalink?repo=updates-released-f33&arch=x86_64 [Received HTTP code 403 from proxy after CONNECT]
stdout:
Summary for fedora-33
------------
Succeeded: 1 (changed=1)
Failed: 3
------------
Total states run: 4
Total run time: 4.304 s
Any hints of what I could look at to address Fedora issues? As @unman’s directions say, with Debian it just works.
Look at that error message - you get a 403 from the proxy for a https
request.
To use apt-cacher-ng I recommend rewriting the request using the
http://HTTPS/// format, so that the proxy uses https, but traffic to
the proxy runs over http.
If you don’t do this then you either need to MITM the https request, or
let it pass without caching.
Fedora makes it really difficult to work if you are using metalinks,
because even if you change the setting there, the linked repo will be
given as a https link.
One solution is to disable metalinks and enable baseurls in the repo
files in /etc/yum.repos.d - one implication of this is that you would
always be hitting the same mirrors, which you may not want to do.
The AppVM I’m using to run apt-cacher-ng is based on Debian 10 Minimal, and I’m assuming I only need to make changes in there, not in the individual Fedora templates. Is that correct?
I see all of the Fedora mirrors in /usr/lib/apt-cacher-ng/fedora_mirrors and they’re all prefaced with http://. Would I be changing all of them to http://HTTPS/// format?
The section of your notes that threw me off a bit was where it referenced /etc/yum/yum.repos.d, which doesn’t exist in a Debian VM, so I wasn’t clear where these changes should be made.
You need to make these changes in the templates:
You can use sed:
sed -i s%https://%http://HTTPS///% ...
If you are nervous about that, use sed -i_bk, which will edit the
files in place and create backups with the suffix “_bk”
The mirror lists use http, but don’t need any prefix. Just the domain
will work.
The reason is simple - apt-cacher-ng cant cache https requests, so URLs
are assumed to be http://
In the notes, I should probably add a line to say “do the same in Debian
templates making appropriate changes”
Thanks. It’s making a bit more sense now.
I made a clone of the Fedora template to test. This didn’t work from the template:
sudo sed -i s%https://%http://HTTPS///% /etc/yum.repos.d/*.repo
From Qubes Updater:
Updating fedora-33-clone-1
Error on updating fedora-33-clone-1: Command '['sudo', 'qubesctl', '--skip-dom0', '--targets=fedora-33-clone-1', '--show-output', 'state.sls', 'update.qubes-vm']' returned non-zero exit status 20
fedora-33-clone-1:
----------
ID: /usr/lib/rpm/macros.d/macros.qubes
Function: file.managed
Result: True
Comment: File /usr/lib/rpm/macros.d/macros.qubes is in the correct state
Started: 14:00:13.790370
Duration: 21.671 ms
Changes:
----------
ID: dnf-makecache
Function: cmd.script
Result: False
Comment: Could not create DNF metadata cache
Started: 14:00:13.812631
Duration: 5706.066 ms
Changes:
----------
ID: update
Function: pkg.uptodate
Result: False
Comment: One or more requisite failed: update.qubes-vm.dnf-makecache
Started: 14:00:20.659216
Duration: 0.013 ms
Changes:
----------
ID: notify-updates
Function: cmd.run
Name: /usr/lib/qubes/upgrades-status-notify
Result: False
Comment: Command "/usr/lib/qubes/upgrades-status-notify" run
Started: 14:00:20.659536
Duration: 2866.185 ms
Changes:
----------
pid:
2531
retcode:
1
stderr:
Error: Failed to download metadata for repo 'updates': Cannot prepare internal mirrorlist: Status code: 403 for http://HTTPS///mirrors.fedoraproject.org/metalink?repo=updates-released-f33&arch=x86_64 (IP: 127.0.0.1)
stdout:
Summary for fedora-33-clone-1
------------
Succeeded: 1 (changed=1)
Failed: 3
------------
Total states run: 4
Total run time: 8.594 s
I think I now see what you mean about the metalink issue.
I tried a static baseurl in the /etc/yum.repos.d/fedora.repo file but I get this:
Updating fedora-33-clone-1
Error on updating fedora-33-clone-1: Command '['sudo', 'qubesctl', '--skip-dom0', '--targets=fedora-33-clone-1', '--show-output', 'state.sls', 'update.qubes-vm']' returned non-zero exit status 20
fedora-33-clone-1:
----------
ID: /usr/lib/rpm/macros.d/macros.qubes
Function: file.managed
Result: True
Comment: File /usr/lib/rpm/macros.d/macros.qubes is in the correct state
Started: 17:07:33.244339
Duration: 22.49 ms
Changes:
----------
ID: dnf-makecache
Function: cmd.script
Result: False
Comment: Could not create DNF metadata cache
Started: 17:07:33.267468
Duration: 27159.038 ms
Changes:
----------
ID: update
Function: pkg.uptodate
Result: False
Comment: One or more requisite failed: update.qubes-vm.dnf-makecache
Started: 17:08:01.597524
Duration: 0.013 ms
Changes:
----------
ID: notify-updates
Function: cmd.run
Name: /usr/lib/qubes/upgrades-status-notify
Result: False
Comment: Command "/usr/lib/qubes/upgrades-status-notify" run
Started: 17:08:01.597633
Duration: 21421.41 ms
Changes:
----------
pid:
8567
retcode:
1
stderr:
Error: Failed to download metadata for repo 'updates': Yum repo downloading error: Downloading error(s): repodata/6e332b1dd1a0dbc5b104f4d5592664260bb662a0f72e0ead4b6a3028f9907ef2-primary.xml.zck - Cannot download, all mirrors were already tried without success; repodata/995cd27d4b9f6aa70fab55fd3240fe623a78d4b4cd741dac4e82ff2623933798-filelists.xml.zck - Cannot download, all mirrors were already tried without success; repodata/1ea503513896df1da51754bfc88936b9e54eb2cd893f488d5e9ba4e1ae583bf9-updateinfo.xml.zck - Cannot download, all mirrors were already tried without success
stdout:
Summary for fedora-33-clone-1
------------
Succeeded: 1 (changed=1)
Failed: 3
------------
Total states run: 4
Total run time: 48.603 s
So I guess I need to keep trying alternate mirror sites in the baseurl to see if one works…