On Mon, Jul 21, 2025 at 02:28:40PM +0200, Alexandre Rossi wrote: > Hi, > > > > > Ouch. The issue is that resolving names might also slow things down, and > > > > I wanted to avoid that. I think I got a simple enough parser for > > > > /etc/that that should work, so we can resolve `apt-proxy` statically > > > > without going outside for DNS. > > > > > > > > Can you test the attached patch? > > > > > > Yes, this would indeed work after adding the entry to /etc/hosts. > > > ``` > > > echo $(kdig +short -t A apt-proxy.$(dnsdomainname) @_gateway) apt-proxy > > > |sudo tee -a /etc/hosts > > > ``` > > > Sadly this doesn't really fix the issue as the same is happening in a > > > network > > > with an SRV entry where it's not all fun and games /รถ\. > > > > SRV records are only checked *after* looking for localhost, (now > > apt-proxy from /etc/hosts), gateway, and apt-proxy from DNS. Wasn't it > > also a problem before? > > I have the same slowness (30s+ for apt update to start downloading something) > and narrowed it down to auto-apt-proxy. I have a SRV record announcing my > proxy. > This proxy is not running on the gateway host nor on localhost. I have > firewall > rules DROPping traffic on that apt-proxy host, except for port 3128, and this > is what makes it very slow. > > If I remove the DNS record for `apt-proxy` host, the slowness is gone (or at > least acceptable). Should I suggest an improvement on the document regarding > this?
Yes, please. > Maybe also my choice of port 3128 could be better aligned with > auto-apt-proxy search order. TBH I don't want to commit to any specific search order. auto-apt-proxy tries to detect a proxy by sending HTTP requests to possible locations where a proxy might be. If that location DROPs packages (instead of e.g. REJECTing them), then the whole process lows down. If the targets just REJECT connections immediately insted of letting the client timeout, then whatever search order can be processed really quickly.
signature.asc
Description: PGP signature
