Tails

#6 Updated by intrigeri 2015-09-28 03:26:09

> * 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.

#17 Updated by Anonymous 2016-11-09 10:13:57

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 2016-11-09 10:39:44

> 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 Feature #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.

#23 Updated by intrigeri 2016-11-09 15:19:32

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