Am 02.11.2013 11:51 schrieb "Matthew Seaman" <matt...@freebsd.org>: > > On 02/11/2013 10:15, Matthias Andree wrote: > > I understand from Eric's pist that the issue is that through his > > limiting proxies, the SRV are not available at all so he does not even > > get to the point where he could get the pkgN.nyi.freebsd.org > > <http://pkgN.nyi.freebsd.org> name back. > > That doesn't make sense. All the DNS SRV lookups on pkg.freebsd.org are > done internally to pkg(8), which then issues an HTTP GET to the specific > mirror selected by its internal algorithms. The web cache won't see > literal 'pkg.freebsd.org' anywhere in the HTTP traffic -- as far as it > is concerned, it's a simple HTTP request to a specific mirror > 'pkg1.nyi.freebsd.org', and can be cached using the usual processes. > > What makes it cache unfriendly is that as far as the web cache is > concerned each of the different mirrors appears to be completely > independent of the others. So at the moment the chance of getting a > cache hit is reduced by a factor of three because of the traffic > distribution across the three mirrors.
Just to add another viewpoint. The redports backendmachines are put into an IPv6 private address space without default router and without a dns server. The only internet connection that they have is via an squid proxy. This setup works fine now that libfetch supports http proxies also for https urls. This all works based on the assumption that no direct dns lookups are required on the machines itself but all dns stuff is done on the proxy. Your description makes me believe that this won't work for pkgng. So it's not that people in the real world break their network setups but we also use that in our own FreeBSD infrastructure. _______________________________________________ email@example.com mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"