Its been solved in the past ... designed for just this purpose:
moriah ~ # esearch http-replicator
[ Results for search key : http-replicator ]
[ Applications found : 1 ]
* net-proxy/http-replicator
Latest version available: 3.0-r2
Latest version installed: 3.0-r2
Size of downloaded files: 38 kB
Homepage: http://sourceforge.net/projects/http-replicator
Description: Proxy cache for Gentoo packages
License: GPL-2
moriah ~ #
I chain them together (two levels, avoiding expensive download costs) so
the remote site doesnt have it in its cache, upstream is the master
cache, which if it doesnt have it will fetch from the repo. You can
specify what port it runs on, and then use the http_proxy entry in
make.conf to point the clients to it thus avoiding port 80 and any
existing webserver. Handles concurrent fetches transparently. Overall, I
have found it preferable to NFS which has been a bit flaky at times in
the past.
Recommended!
BillK
On Sat, 2011-11-12 at 22:01 +0000, Neil Bothwick wrote:
> On Sat, 12 Nov 2011 19:40:08 +0700, Pandu Poluan wrote:
>
> > During my drive home, something hit my brain: why not have the 'master'
> > server share the distfiles dir via NFS?
>
> No reason at all, I've been doing it for years without a single
> problem.
>
> > So, the question now becomes: what's the drawback/benefit of
> > NFS-sharing vs HTTP-sharing? The scenario is back-end LAN at the
> > office, thus, a trusted network by definition.
>
> The benefit is that everything is centralised. With an HTTP proxy, you
> still have to download from the server to each client. The only drawback
> that I experience is that if several packages use the same, large source
> file, as so many of the KDE packages do, you are repeatedly pulling the
> same file over the network, which is a little slower.
>
>
