Project

General

Profile

Feature #8643

Bug #7161: Support more than 24 HTTP mirrors

Clean up the remainers of the old mirror pool setup

Added by intrigeri almost 4 years ago. Updated almost 2 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Infrastructure
Target version:
Start date:
01/09/2015
Due date:
04/15/2016
% Done:

100%

QA Check:
Pass
Feature Branch:
451f:tails/doc/8643+mirrors
Type of work:
Contributors documentation
Blueprint:
Starter:
Affected tool:

Description

  • have all mirror operators disable the old VirtualHost
  • update contribute/how/mirror doc to not document the old setup anymore (but still, keep dl.a.b.o working since that's what the fallback DNS pool still uses)

Related issues

Blocked by Tails - Feature #8642: Enable the mirror pool dispatcher on all website pages that need it Resolved 01/09/2015 04/15/2016
Blocked by Tails - Feature #11109: Have DAVE build the ISO URL using our mirrors pool configuration Resolved 01/09/2015 04/15/2016

Associated revisions

Revision dd57313c
Added by intrigeri almost 2 years ago

Merge remote-tracking branch '451f/doc/8643+mirrors'

Closes: #8643

Revision 53539e6d (diff)
Added by intrigeri almost 2 years ago

Make example URLs not use the fallback DNS pool's name.

refs: #8643

History

#1 Updated by intrigeri almost 4 years ago

  • Blocked by Feature #8642: Enable the mirror pool dispatcher on all website pages that need it added

#3 Updated by intrigeri over 3 years ago

  • Target version changed from Sustainability_M1 to Tails_2.3

#4 Updated by intrigeri about 3 years ago

  • Due date set to 04/15/2016

#5 Updated by u about 3 years ago

  • Description updated (diff)

#6 Updated by intrigeri about 3 years ago

  • have boum.org disable the dynamic DNS update system => check if needed

That's obsolete with the JS-based design, but we'll still need to manually maintain the fallback, reliable pool for non-JS users, so we need new tickets for setting up that pool and getting ourselves the means to maintain it.

#7 Updated by intrigeri about 3 years ago

  • Blocked by Feature #10295: Build a list of fast and reliable HTTP mirrors added

#8 Updated by intrigeri over 2 years ago

  • Blocked by deleted (Feature #8642: Enable the mirror pool dispatcher on all website pages that need it)

#9 Updated by intrigeri over 2 years ago

  • Blocked by deleted (Feature #10295: Build a list of fast and reliable HTTP mirrors)

#11 Updated by intrigeri over 2 years ago

  • Target version changed from Tails_2.3 to Tails_2.4

I doubt we'll have finished all blockers during the 2.3 cycle.

#12 Updated by intrigeri over 2 years ago

  • Blocked by Feature #8642: Enable the mirror pool dispatcher on all website pages that need it added

#13 Updated by intrigeri over 2 years ago

  • Description updated (diff)

#14 Updated by anonym over 2 years ago

  • Target version changed from Tails_2.4 to Tails_2.5

#15 Updated by intrigeri about 2 years ago

  • Target version changed from Tails_2.5 to Tails_2.7

#16 Updated by intrigeri about 2 years ago

  • Blocked by Feature #11109: Have DAVE build the ISO URL using our mirrors pool configuration added

#17 Updated by u almost 2 years ago

This ticket has been created during our initial setup phase for the mirror pool. Since then, our design has evolved a little bit.

It's now the question if we want to have some or all people keep the old setup, because the old mirror pool setup is still our fallback, for people who do not use JS on the website for example. This would allow us to add people to the fallback mirror pool at will.
Currently, not all of our mirror operators have configured the fallback DNS - so we could rather think about an easy way to maintain a list of those who have and those who haven't. This could be an entry in the mirror pool json file, for example, or simply in the mirror pool repository.

Are there implications about HTTPS to take into account? I'm unsure.

If we actually decide that we would keep this setup, we should simply rephrase the documentation and not ask people to disable the old setup.

#18 Updated by intrigeri almost 2 years ago

This ticket has been created during our initial setup phase for the mirror pool. Since then, our design has evolved a little bit.

Right! I've updated the description since then, but clearly not enough. So part of the work here is to find out what needs to be updated, and how.

It's now the question if we want to have some or all people keep the old setup, because the old mirror pool setup is still our fallback, for people who do not use JS on the website for example. This would allow us to add people to the fallback mirror pool at will. Currently, not all of our mirror operators have configured the fallback DNS - so we could rather think about an easy way to maintain a list of those who have and those who haven't. This could be an entry in the mirror pool json file, for example, or simply in the mirror pool repository.

IMO we should:

  • keep the current doc that asks mirror operators to configure their web server to also answer request to dl.a.b.o: it's the status quo for most current mirrors, it basically comes for free for most new mirrors, and most importantly it makes it easier for us to add mirrors to our fallback DNS pool, as you said;
  • adjust the doc phrasing slightly to reflect better how the new setup works, as you proposed below;
  • not bother with tracking which mirror has dl.a.b.o configured or not: it's trivial to check whenever we are considering adding one given mirror to the fallback DNS pool, and the idea is that we'll very rarely modify that pool, so to me it seems less work to check this when needed, rather than trying to maintain this state info for all mirrors (even more so given that 80% of them have 0 chances to ever be added to the fallback DNS pool);
  • not send any email.

Are there implications about HTTPS to take into account? I'm unsure.

What to do about our fallback DNS pool will be relevant for #9796, but I don't think it has any implication right now :)

If we actually decide that we would keep this setup, we should simply rephrase the documentation and not ask people to disable the old setup.

Yes.

#19 Updated by u almost 2 years ago

  • Assignee changed from u to intrigeri
  • QA Check set to Ready for QA
  • Feature Branch set to 451f:tails/doc/8643+mirrors

#20 Updated by u almost 2 years ago

  • % Done changed from 0 to 20
  • Type of work changed from Communicate to Contributors documentation

#21 Updated by intrigeri almost 2 years ago

  • Status changed from Confirmed to Resolved
  • % Done changed from 20 to 100

#22 Updated by intrigeri almost 2 years ago

  • Assignee deleted (intrigeri)
  • QA Check changed from Ready for QA to Pass

#23 Updated by intrigeri almost 2 years ago

Perfect, thanks! I've just added a minor change on top and pushed.

Also available in: Atom PDF