[arch-general] 'Local mirror' page was removed from wiki

C Anthony Risinger anthony at extof.me
Tue Sep 14 20:13:48 EDT 2010


On Tue, Sep 14, 2010 at 2:27 PM, Nathan Wayde <disposaboy at konnichi.com> wrote:
> here's what I'd(and I imagine most others who know about sharing the cache)
> use a local mirror for:
>
> to be able to sync all other systems from it. plain and simple. if my
> systems don't have internet connection or something like that then i simply
> get the packages from the master,
> cache sharing doesn't and cannot solve that problem at all, that's a fact.

shared cache won't solve that sure... but there are better solutions:

) if you can get it from master, then it sounds like you have a LAN
connection; tunnel a connection thru master...
) if you have a LAN, what can't some machines have access anyway?
) if you don't have a LAN, you are manually moving packages?  you
could do that without a local mirror
) if you have a LAN, but _cannot_ allow some access to the net, then
use a different method like a caching proxy

local mirror = quick/easy crutch to avoid better utilization of
local/peer resources

i use a homebrew proxy/cache solution for my home, works fine.  one
machine pretends to be a repo, others look to it for packages... easy.
 i'm not using this exact version now, but i implemented this (rather
crappily) while first learning python:

"pacproxy (or something that vaguely resembles an apt-proxy clone)"
https://bbs.archlinux.org/viewtopic.php?id=87115

> now to the bandwidth issue. it's obviously bogus, because:
>
> 1) they assume everyone/(lots of people) is going to create a local mirror.
> 2) they assume that they're all going to sync from the same server.
> 3) they assume this extra bandwidth waste actually causes a problem for all
> the mirrors - i.e that there's only 1 mirror.
>
> now, if my assumptions are wrong thus leading to false conclusions then
> please correct me, but so far all I've heard is whining about local mirror
> causing problems for the mirrors but nothing about what these problems
> actually are, in the meantime the original wiki was deemed bad with not much
> of a valid reason and nothing being done to further educate us the users.

i don't think it's even about whether or not it _is_ causing a
problem, and more a preemptive move to discourage naive
implementations.  sure, if you have a heterogeneous environment of 200
machines, then a local mirror probably isn't too bad an idea... but it
still isn't needed, as faster/better/cheaper methods are available.

in my opinion, if you're not publicly seeding your mirror, then you
don't need it; else you probably only want it due to an extreme case
of laziness.  sure maybe mirror XYZ can handle constant sync's from
everyone looking at it... but really, do them a favor, and don't; it
might piss them off :-).

> You can probably tell that I'm annoyed by this and the simple fact is that
> ARM sync script was based off the script on that wiki, it's not the same as
> I changed a lot of options to cater to my own needs but as have been said
> the script was bad, no-one is telling us what was bad about it and these
> alternative methods are wholly inadequate at best.

yeah i don't really know the politics here, or have even seen the
script.  in my own experience back in the day syncing ubuntu repos
(for easy install at remote locations from large USB key when client
requirements are unknown)... you likely flat out don't need it, and
there are _very_ few legitimate use cases for it (the parenthesized
use case above is about the best one i know).

all i'm suggesting is that just because you can and it's easy doesn't
mean you should.  but hey, i don't run a mirror, and extreme leeching
won't affect me, so ultimately i could care less; if i did though, i
would monitor for this kind of crap... i mean, doesn't the official
arch mirror impose similar restrictions?  just do you part to not be
excessive.

does one check out the entire library on the possibility of reading 10 books?

C Anthony


More information about the arch-general mailing list