Solved for me.
Is this updated or not? I want to follow the manual method, but I see the iptables command at the end already and assume it wouldn’t work on Qubes 4.2.
I don’t know how to convert it to nftables myself.
It works for Qubes OS 4.2 as well.
Change
/sbin/iptables -I INPUT -p tcp --dport 8082 -j ACCEPT
to
/usr/sbin/nft add rule ip qubes custom-input tcp dport 8082 accept
3 Likes
Not sure, why: But I followed notes/apt-cacher-ng.md at master · unman/notes · GitHub as is - incl. /sbin/iptables -I INPUT -p tcp --dport 8082 -j ACCEPT in /rw/config/rc.local - and apt-cacher-ng works surprisingly (Qubes OS 4.2, minimal Debian template for cacher). The only thing I needed to add was AllowUserPorts: 80 443 in ∕etc/apt-cacher-ng/acng.conf. Reading your comment, I tried to manually execute above statement and noticed, an error is thrown for non-existent iptables command (as replaced by nft in Qubes OS 4.2).
Just wondering why this works without using the nft command…
Templates are updated using qrexec so in cacher qube it’s a localhost connection to 8082 and localhost input connections are allowed by default.
Yeah. So if I understood that, we don’t need an nft rule at all - because some-client connects to cacher (apt-cacher-ng AppVM of cacher-template) via qubes.UpdatesProxy qrexec policy and not via (virtual) network, right?
There is one thing confusing left for me. How to install software | Qubes OS states that clients need updates-proxy-setup qubes-service and servers qubes-updates-proxy. Usually clients are templates connecting to cacher, where this service is activated per default. But looking at /var/run/qubes-service of cacher I didn’t see qubes-updates-proxy file, so how can cacher act as Qubes Update proxy server?
Update:
I think I got it. /var/run/qubes-service is only a signal for corresponding system service within the qube to activate a tinyproxy instance on port 8082 as update proxy. This file doesn’t exist in cacher, but we already started apt-cacher-ng server on port 8082, so it can work the usual way. Thanks for clarification!
Only templates don’t need this rule. As described in @unman’s guide:
Other qubes
You can also use the proxy with other qubes, besides templates.
Because the proxy is listening on port 8082, and you have configured iptables to allow inbound traffic to that port, you can use the proxy from any downstream qube, simply by configuring use of the Proxy in that qube, following whatever is the normal method. (You will have to adjust repository definitions to handle HTTPS.)
This allows you to have the benefit of caching in normal qubes, and Standalones, without using qrexec.
Both templates and other qubes can be configured to be clients of the cacher qube. Their only difference is that non-template qubes need to activate updates-proxy-setup explicitly. So I think it’s rather about qrexec vs. network access.
Imo what quote states is that you can also use the cacher via network, not qrexec. If using via network you need in inbound accept rule.
You’ll also need to edit qrexec policy because by default it only allows TemplateVMs to use the UpdatesProxy.
1 Like
That’s right.
Some qubes and templates wont be able to use qrexec, so the
network route is the only one available.
1 Like