intrigeri wrote:
> Hi,
>
> sajolida@??? wrote (30 Jun 2014 15:52:11 GMT) :
>> I'm wondering if this added complexity is really worth it for a first
>> fix. Could we work on this core HTTP redirection mechanism first (to
>> solve the pool size problem) -- with maybe lizard running a duplicate of
>> this script -- and work on a more distributed super-mirror mechanism (to
>> solve a resiliency problem) later on?
>
> Until now, lizard is managed in a way that's suitable for hosting dev
> tools. I'm not sure what it would take to adapt it for hosting
> resources meant for end-user consumption (it terms of logging policy
> availability, and protecting important bits of our infrastructure
> against PHP).
Ok, I didn't know that.
> If lizard is a fallback only, what server did you have in mind to run
> the primary super-mirror? (If that's boum.org, we should ask them if
> they're ready to take the load and responsibility.
Doing some very simplistic calculation:
- a typical Tails mirror pushed 3 TiB of monthly data on average
- that's about 100 ISO images per day
- that's about 2600 image across our current 26 mirrors
- that would be about 100 redirections per hour with a single master
server, or 1 per minute with two master servers
I'm not considering IUKs here but that would still be a pretty low load
in comparison with the official website.
But sure, we need to talk to boum about that.
> And when boum.org
> is down, there's no way to reconfigure DNS to have the fallback server
> take over, so probably we would need to have it in the
> round-robin permanently.)
No, I meant duplicate in the sense that there would be two mirrors in
the DNS pool: lizard and boum.
>> That would put more work on our side to setup lizard as a fallback, but
>> that would save us, for the time being, the work of coordinating,
>> verifying, and maintaining this set of outsources super-mirrors.
>
> Indeed.
>
> If the current situation is problematic enough (which is unclear to
> me, actually) then why not spend time on a "temporary" hack. Else, I
> say we can instead put time into designing a proper long-term
> solution.
I was not considering this as a hack but as a first step: we deploy a
minimal super-server infrastructure ourselves on the two servers we are
already using and make that easier in terms of bootstrapping
communications, remote verification, outsourced maintenance, maybe
technical complexity, etc.
But yeah, maybe we should spend the time needed to design the long-term
solution first before seeing if it is worth doing this simplified first
step or not. And I also understand that deploying that on lizard will be
work you will be likely doing, while communicating with outsourced
mirrors is work I will likely be doing (provided I have the technical
knowledge and confidence to do so).
--
sajolida
