On 2021-08-20 12:04:02 -0700 (-0700), Russ Allbery wrote: > Simon Richter <sjr@debian.org> writes: > > > I support that idea in principle, but one of our user stories is > > "I have a datacenter with a few thousand containers in it, so I > > want to redirect accesses to the local mirror to reduce external > > network traffic." > > Just checking that I understand. You have several thousand > containers that you're running in your data center but cannot > modify and whose network access specifically to Debian apt mirrors > you want to intercept and redirect, and you're relying on them > using http instead of https in order to be able to do this? [...] Probably the more general case here is that you have a lot of systems (I agree "containers" is a bit preposterous when we're talking about package installs/updates) for which you want to provide some sort of cache/proxy/mirror and for whatever reason be it convenience or resource constraints want to serve those over HTTP. But the answer here is that changing the default sources.list entries written by debian-installer or baked into pre-built "cloud images" pretty much always comes into play anyway. You're going to be modifying the systems' sources.list entries already via configuration management or some agent like cloud-init to be able to use that cache/proxy/mirror, so listing the correct transport scheme in your modified entries isn't additional effort. Yes transparent proxies or overridden DNS lookups could be used to direct deb.debian.org and security.debian.org to your alternative location, but in my experience (working at colocation/hosting companies as well as cloud service providers) this is rarely done and generally considered unhygienic. Transparent "web accelerators" used to be popular in such environments, but the modern trend to switch most communications to HTTPS has rendered them essentially useless since years. -- Jeremy Stanley
Attachment:
signature.asc
Description: PGP signature