Trouble setting up apt-cacher-ng

User Support
#1

I am trying to set up apt-cacher-ng so I can create several templates that get the same updates, and I am having problems. The only tutorial I could find was this one, which I found to be a bit unclear, but that I managed to follow up to step 3, where it seems like it is asking me to do something for fedora (yum)? Anyway, I decided to skip that step, but the update proxy is not working.

I got this error in the debian-11 template:

user@debian-11:~$ sudo apt update
Err:1 https://deb.qubes-os.org/r4.1/vm bullseye InRelease
  Invalid response from proxy: HTTP/1.0 403 CONNECT denied (ask the admin to allow HTTPS tunnels)     [IP: 127.0.0.1 8082]
Err:2 https://deb.debian.org/debian bullseye InRelease
  Invalid response from proxy: HTTP/1.0 403 CONNECT denied (ask the admin to allow HTTPS tunnels)     [IP: 127.0.0.1 8082]
Err:3 https://deb.debian.org/debian-security bullseye-security InRelease
  Invalid response from proxy: HTTP/1.0 403 CONNECT denied (ask the admin to allow HTTPS tunnels)     [IP: 127.0.0.1 8082]
Reading package lists... Done
E: Failed to fetch https://deb.debian.org/debian/dists/bullseye/InRelease  Invalid response from proxy: HTTP/1.0 403 CONNECT denied (ask the admin to allow HTTPS tunnels)     [IP: 127.0.0.1 8082]
E: Failed to fetch https://deb.debian.org/debian-security/dists/bullseye-security/InRelease  Invalid response from proxy: HTTP/1.0 403 CONNECT denied (ask the admin to allow HTTPS tunnels)     [IP: 127.0.0.1 8082]
E: Failed to fetch https://deb.qubes-os.org/r4.1/vm/dists/bullseye/InRelease  Invalid response from proxy: HTTP/1.0 403 CONNECT denied (ask the admin to allow HTTPS tunnels)     [IP: 127.0.0.1 8082]
E: Some index files failed to download. They have been ignored, or old ones used instead.

systemctl status apt-cacher-ng reports the cacher as running, and I put the following in /etc/qubes/policy.d/30-user.policy in dom0:

qubes.UpdatesProxy * @type:TemplateVM @default allow target=apt-cacher-ng

apt-cacher-ng is the name of the cacher VM, and it is using sys-whonix as its NetVM.

What might be wrong with my setup? Also, in my opinion, Qubes OS needs much better apt-cacher-ng docs, perhaps it even deserves to be in the User docs?

#2

In your templates you need to edit the apt source files, so the urls instead of being https:// become http://HTTPS///.

You can do it quickly with these commands (run as root):

sed -i 's#https://#http://HTTPS///#g' /etc/apt/sources.list
sed -i 's#https://#http://HTTPS///#g' /etc/apt/sources.list.d/*.list
1 Like
#3

Thank you, this seems to make it work in the Debian templates! I tried a similar thing in the Fedora template though, and it is not working. This is what I ran:

sed -i 's#https://#http://HTTPS///#g' /etc/yum.repos.d/*.repo

And I got this error:

[root@fedora-34 ~]# dnf update
Fedora 34 - x86_64                              1.6 kB/s | 512  B     00:00    
Errors during downloading metadata for repository 'fedora':
  - Status code: 403 for http://HTTPS///mirrors.fedoraproject.org/metalink?repo=fedora-34&arch=x86_64 (IP: 127.0.0.1)
Error: Failed to download metadata for repo 'fedora': Cannot prepare internal mirrorlist: Status code: 403 for http://HTTPS///mirrors.fedoraproject.org/metalink?repo=fedora-34&arch=x86_64 (IP: 127.0.0.1)

I have fedora mirrors setup in apt-cacher-ng and, because it seemed the fedora-34 template uses it but it was not in the list, I added https://mirrors.fedoraproject.org/ to /etc/apt-cacher-ng/fedora-mirrors. I also added VfilePatternEx: .*metalink?repo=fedora* in /etc/apt-cacher-ng/acng.conf, because the guide recommended it and I saw a similar pattern in the requests Fedora made. After this I restarted the service and the error still persists.

What should I do to make Fedora work with apt-cacher-ng?

#4

My notes are just that - notes, not a tutorial.

I package a salt state for use of apt-cacher-ng at
https://github.com/unman/shaker which will create the caching qube and
also configure the templates. It also includes an updated mirror list,
and a good config file.
I would strongly suggest that you use that state.

There is always a problem in dealing with https requests: either the
proxy has to perform some MITM, pass through uncached, or use some half
way mechanism.
apt-cacher-ng does the latter - the client changes a request from
https:// to http://HTTPS/// - the request is plain http to the proxy
and the proxy then makes a https request to the repository.

This works fine for many distros.
It doesn’t work for Fedora if you use the metalink specification.
This is because the list of repos returned by the metalink will contain
https repositories, and we know those wont work.
One way to work around this is to change the request to
http://HTTPS///mirrors.fedoraproject.org/metalink?repo=fedora-34&arch=x86_64&protocol=http
which will only return http repositories. That circumvents the problem.
An alternative would be to not use metalinks, and to enable the baseurl
definition in the repository listing.

Getting Fedora working can be a pain. The salt states do all the work
for you: even if you dont use them you should be able to read and
understand the changes they make.

1 Like
#5

Thanks @unman for your response, and sorry for the late answer. I could not get the Fedora setup to work or find out how to use your salts, but I have gotten Debian working, which I believe will be the base of most of my templates, so I am deciding to mark this as solved, since the original question is and I am not as interested in working on this now. If I ever decide to come back to this and work on Fedora I may have another look at your salts, either to use or to learn from. Regardless, I thank you for your notes and salts which have been great help getting apt-cacher-ng running.