Ping, I have still this issue on bookworm stable.
1 Like
I edited the title slightly
- fixed a typo in
apt-cacher-ngto make sure folks find the topic when searching for that - removed the
[solved]tags because the forum is configured to identify solved topics already (little checked box next to the title in lists, solution highlight and quick access link in the first post) edit to clarify: so it should already be clear that the topic is solved
For me it is still tagged as solved.
I also have this problem for deb12 however deb11 works fine.
The cacher is the one linux qube on my system that is still based on debian-11-minimal. I ran into some sort of problem (I don’t remember exactly what), but in essence trying to use the deb12m version broke me.
It’s on my list of things to try out again.
I’m not sure what problem you have - I’ve been running cacher on a
bookworm system for most of the year.
After a system dist-upgrade, the only change required was that
identified earlier in the thread - Set AllowUserPorts: 80 443 in
/etc/apt-cacher-ng/acng.conf
1 Like
I decided, on reading your response, to give it a go. And it worked! Thanks!
OK, having said that I’ll now give an example of why my relationship with salt is love-hate rather than pure love.
I did a file.replace to change #AllowUserPorts: 80 to AllowUserPorts: 80 443. Obviously I didn’t want to do this before having acng.conf in the (otherwise) correct state, so I did a requires: referencing the file.managed.
The problem is in this case the tag is require:. There’s no rhyme or reason to it; sometimes a state uses requires: and sometimes it’s require:. I didn’t remember this. The .sls file I referenced to find an example of file.replace didn’t happen to have one with a require clause in it, so I made the mistake of looking for a different sample require (actually in this case requires) clause in the file I was adding the state to.
The damn thing said “OK” when I ran it, but in fact JSON had thrown up. Basically if there’s a Jinja or salt syntax error, it will often report “OK” in spite of actually having done nothing. (It will invariably do so if Jinja failed to render.) This is a damned lie, but it’s salt. Usually when this happens, it’s fast and I know to check when it runs too fast; in this case it took about ten minutes so I didn’t think to check the log file. (To add to the irony, if you apply an .sls file that’s syntactically correct but did nothing (perhaps because an onlyif wasn’t true), it DOES throw an error, even if that’s the desired behavior. Which is just stupid.)
So after spending a bunch of time wondering why the fix didn’t work, I finally decided to check the log file. Which did, thank heavens for small favors, tell me exactly what the error was [a big surprise in and of itself; it usually just says failed to render]. And so I got to do the whole thing over again.
After some testing today I found that my problem is related to whonix since updating without whonix works fine. For whonix-16 however i get
Failed to fetch tor+http://2s4yqjx5ul6okpp3f2gaunr2syex5jgbfpfvhxxbbjwnrsvbk5v3qbid.onion/debian/dists/bookworm/InRelease 503 Host not found [IP: 127.0.0.1 8082]
A side note, since it might be helpfull to somebody else:
Just creating and configuring a deb12-cacher template and replace the deb11-cacher template broke the apt-cacher-ng service for me. Creating an new deb12-cacher-vm fixed that issue for me. However, deb12-cacher remains broken for a whonix netvm.
I’m more impressed at the fact that your (incorrect) use of requires
worked sometimes.
The key word is require - this will work in every state.
See the docs
Use the right requisite statement, and love will be restored.
3 Likes
Time for a mass global search and replace! Thanks!
Edit (probably within the time limit for mail):
Actually it’s entirely possible that “requires” did not work. If it happens to execute the states in the right order, it will be fine regardless of whether it recognized “requires” as being “require”.
On the other hand, it didn’t complain about an unknown tag, either, and probably ought to have!
1 Like
As it happens there was exactly ONE instance of “requires” in all of my sls files…and I just happened to pick that one as a model.
Anyway, now there are none.
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.