Hello, On 05/08/12 21:12, Eduard Bloch wrote: > So, IMHO the root cause is http.debian.net redirecting you to a faulty > mirror.
That definitely wasn't the cause; http.debian.net would return a redirect to free.hands.com or mirror.bytemark.co.uk which were both operating fine, and they are part of the cdn.debian.net pool which works for me through apt-cacher-ng without issues. apt-cacher-ng wasn't making the second HTTP request to the Location URI in the response. Instead it sat for ~2 minutes before passing the 302 redirect through to the client. (Maybe stuck waiting for Keep-Alive to time out?) >> Also with RedirMax 0, the 302 redirect is forwarded immediately through >> to the client, so nothing is cached, making apt-cacher-ng pointless in >> that situation. > > Only if you use the URL modification method! > > If you set apt-cacher-ng as "global" proxy in apt.conf settings, it will > also be used for the redirected locations. Oh, I didn't realise this. I had already given up on it and decided to set up a Squid cache to work in exactly that way. Perhaps some of this could be of interest for Debian LAN so I will explain what I did: I set up a separate, dedicated Squid3 instance for APT clients and tuned the settings appropriately for the task. From my 'main' Squid cache I believe I can redirect to it with: > cache_peer aptcache parent 3128 0 name=debrep no-query originserver proxy-only > cache_peer_domain debrep .mirror.debian.net > cache_peer_domain debrep cdn.debian.net > cache_peer_domain debrep snapshot.debian.org Squid may also be able to intercept and redirect requests meant for http.debian.net (e.g. handle with a replacement webservice on localhost that simply generates a 302 redirect to cdn.debian.net or a complete, site-local Debian mirror). I configured clients to use <country>.<arch>.mirror.debian.net which returns a full DNS RRset, so Squid with retry_on_error can retry failed requests from another server if one is down. And I set generous values for cache_dir size and maximum_object_size. So IMHO apt-cacher-ng would have been more useful to me as something standalone that merely manages Squid's cache by sending it pre-fetch and PURGE requests. I like the idea behind http.debian.net, but by redirecting to an arbitrary URI it breaks regular HTTP caching; only something like apt-cacher-ng can do that, which is why it is important they are able to work together. Regards, -- Steven Chamberlain ste...@pyro.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
