[Haskell-cafe] Offer to mirror Hackage

[Duncan Coutts]

On 9 December 2010 21:04, Richard O'Keefe <ok at cs.otago.ac.nz> wrote:
>
> On 10/12/2010, at 12:18 AM, Markus Läll wrote:
>
>> My take on the issue is that we should make it possible to easily mirror hackage (what the OP asked for), so that people could use it when they wanted to, and have a list of the mirrors on the wiki. This way those who are interested can use them. Like when the mirror is faster/closer to them or to help out when hackage is temporarily down. Those who need the security can choose not to use mirrors, or make their own (private), or develop a secure scheme, when it doesn't exist yet.
>
> Have I misunderstood something?
> I thought "X is a mirror of Y" meant X would be a read-only replica of Y,
> with some sort of protocol between X and Y to keep X up to date.
> As long as the material from Y replicated at X is *supposed* to be
> publicly available, I don't see a security problem here.  Only Y accepts
> updates from outside, and it continues to do whatever authentication it
> would do without a mirror.  The mirror X would *not* accept updates.

That's certainly what we've been planning on, that anyone can run a
mirror, no permissions needed. The issue people have raised is what
about having public mirrors that are used automatically or
semi-automatically by clients.

The suggestion about DNS round robin is transparent to clients but
requires all the mirrors to be a master, or to have some forwarding
system. Any transparent system also needs trust.

My opinion is that at this stage it is not really worth doing anything
complicated. We do not yet have a bandwidth problem. Once there are
more (unpriviledged) public and private mirrors then temporary
downtime on the main server is less problematic. Eventually we'll get
a bandwidth problem but I think we've  got a fair bit of time to
prepare and in the mean time we can get simple unpriviledged mirroring
working. That is mostly an issue of specifications and tools. The spec
for package archives is not as clear or as good as we'd like. We've
been discussing it recently on the cabal-devel mailing list.

Duncan