Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#17158 closed enhancement (implemented)

Run an opt-in process for fallback directories

Reported by: teor Owned by: teor
Priority: Medium Milestone: Tor: 0.2.8.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: 028-triaged, must-fix-before-028-rc, TorCoreTeam201605, TorCoreTeam-postponed-201604, review-group-1
Cc: arma Actual Points: 3 weeks
Parent ID: Points: 0.4
Reviewer: isis Sponsor: SponsorU-can

Description

  • Draft an email requesting that relay operators opt-in their ID and IP as a fallback directory
  • Convince someone @ torproject.org to send the email to tor-relays
  • someone @ torproject.org collates responses and adds them to the whitelist
  • Once we have enough whitelist entries, we merge the whitelisted fallback directories into the code

Child Tickets

TicketTypeStatusOwnerSummary
#8374enhancementclosedteorShip list of fallback directory mirrors on long-term fixed IPv6 addresses
#15228enhancementclosedteorIdentify candidates for FallbackDir, and ship with a list of them
#15775enhancementclosedteorAdd IPv4 Fallback Directory List to tor, active by default
#17235enhancementclosedMerge prop 210 changes for #4483 and #15775
#17864enhancementclosedWait for busy authorities / fallback dir servers
#17905enhancementclosedConsider removing fallback directory weights
#18035defectclosedteorReview proposed fallback directory script fixes
#18689defectclosedFallback Directory Selection should exclude down relays earlier
#18749enhancementclosedConsider only including one fallback per operator

Change History (49)

comment:1 Changed 4 years ago by nickm

Keywords: 028-triaged added

comment:2 Changed 4 years ago by nickm

Keywords: SponsorU removed
Sponsor: SponsorU

Bulk-replace SponsorU keyword with SponsorU field.

comment:3 Changed 4 years ago by nickm

Points: medium/large

comment:4 Changed 4 years ago by teor

I think this is a good initial draft:

Dear Relay Operators,

We're adding a list of fallback directory mirrors to Tor in 0.2.8. Tor contacts fallback directory mirrors during bootstrap, and downloads the consensus and authority certificates from them. Once it has a verified consensus, it then uses the consensus to download relay descriptors.

Fallback directory mirrors allow Tor to bootstrap in networks that block the Tor directory authorities. This allows people to use Tor without manually configuring bridges or pluggable transports.

For more information about fallback directory mirrors, see:
https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors

We want to identify around 100 stable non-exit relays, as exits currently experience high load. (We will include exits, but we don't want to overload them, so the default fallback weight of exits is reduced to 20% of their consensus weight.)

In October 2015, we created a list of candidate fallback directories. If your relay is on this list of candidates, and will be keeping its address and port for at least 2 years, we would appreciate permission to put it in the fallback directory list.
https://trac.torproject.org/projects/tor/attachment/ticket/15775/fallback_dirs.inc
(We will also include the details of relays that may become stable enough by the 0.2.8 release date.)

For the initial fallback directory release, we will only put your relay on this list if you give us permission. Please reply on the list, or to this email address.

comment:5 Changed 4 years ago by teor

Status: newneeds_review

comment:6 Changed 4 years ago by teor

Please merge bootstrap-exponential-backoff-v2 from https://github.com/teor2345/torspec.git before we send this out. This updates proposal 210 for #4483 and #15775.

comment:7 Changed 4 years ago by teor

Actually, the proposal keeps changing slightly as I implement it.
Let's wait until the final version in #4483.

comment:8 Changed 4 years ago by teor

Keywords: TorCoreTeam201512 added
Severity: Normal

comment:9 Changed 4 years ago by teor

The spec changes were merged by nickm on 21 October 2015 in 3bac19d0b31b.

Now we need to run the process, once we decide to include #4483.

comment:10 Changed 4 years ago by dgoulet

Status: needs_reviewneeds_information

teor, did this email ever got on a tor-relays@ ?

If no, I can go ahead with it if you like? Seems like building that list is starting to be important?

comment:11 Changed 4 years ago by teor

Status: needs_informationneeds_review

I've updated the email (below), the wiki entry, and the fallback directory list (attached to #15775).
(Do you think we should attach the list to the email as well as linking to it in the email?)

A list of fallback directories would help with the following tickets:

  • fallback directories (#15775),
  • client boostrap reliability (#4483) and
  • clients on IPv6 (#17281).

If the responses are on the list, I can add them to the whitelist (or opt-outs to the blacklist).

If you do get direct responses, can you send me a list of relays that need to be added to the whitelist / blacklist (after removing anything written by the operators).

Here is an updated draft email for tor-relays@tpo:

Dear Relay Operators,

We want to run a trial of fallback directory mirrors in Tor. Tor clients contact fallback directory mirrors during initial bootstrap, before they contact the directory authorities.

Fallback directory mirrors allow Tor to bootstrap in networks that block the Tor directory authorities. This allows people to use Tor without manually configuring bridges or pluggable transports.

For more information about fallback directory mirrors, see:
https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors

We want to find around 100 stable non-exit relays, as exits currently experience high load. (We don't want to overload exits, so we automatically reduce the likelihood that exits are used as fallback directories.)

In December 2015, we created a list of candidate fallback directories. If your relay is on this list of candidates, and will be keeping its address and port for at least 2 years, we would like to put it in the fallback directory list. (We will also include the details of long-term relays that may become stable enough to be a fallback at some point in the future.)

https://trac.torproject.org/projects/tor/attachment/ticket/15775/fallback_dirs.inc

For the initial fallback directory release, we will only put your relay on this list if you give us permission. Please reply on the list. (Your relay's details will be added to the publicly available tor source code.)

comment:12 Changed 4 years ago by nickm

quick suggestion -- we should mention what fallbacks need to have, so that operators can evaluate whether they're likely to continue having them in the future. (Stable IP address, good bandwidth, decent fractional uptime... anything else?)

comment:13 Changed 4 years ago by teor

Here is a revision of the email that makes the criteria for fallback directories more explicit. I have also updated the wiki page with more detailed information. (I tried to make the email shorter as well, so more people would read it.)

Subject: Opt-In Trial: Fallback Directory Mirrors

Dear Relay Operators,

TL;DR: Stable non-exit relays can help tor clients use the Tor network. Please opt-in!

We want to run a trial of fallback directory mirrors (fallbacks) in Tor. Tor clients contact fallbacks to download the consensus during initial bootstrap, before they contact the directory authorities.

Fallbacks allow Tor to bootstrap in networks that block the Tor directory authorities. This allows people to use Tor without manually configuring bridges or pluggable transports.

For more information about fallbacks, see:
https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors

For this trial, we want to find around 100 stable non-exit relays, as exits currently experience high load.

These relays need to be stable for the next 2 years, with:

  • good uptime,
  • the same IP address(es) and port,
  • the same relay identity key,
  • good bandwidth and network connectivity.

In December 2015, we created a list of ~400 candidate fallbacks.
https://trac.torproject.org/projects/tor/attachment/ticket/15775/fallback_dirs.inc

If your relay is on this list, and will be on the same IP address(es) and port for at least 2 years, please consider opting-in for this trial. (Relays that aren't on the list are welcome to opt-in. They will be considered in future releases, or if the selection criteria change.)

For the initial fallback release, we will only add your relay if you give us permission. Please reply on the list. (Opt-ins, opt-outs, and chosen fallbacks will be managed using lists in the publicly available tor git repository.)

comment:14 Changed 4 years ago by nickm

This is fine by me, except to replace "These relays need to be stable for the next 2 years" with "We want relays that expect to be stable for the next 2 years". If that's good with you, let's ask Roger to send it to the usual places. People take Roger seriously. :)

comment:15 Changed 4 years ago by teor

Cc: arma added

Ok, here it is with that edit, and minor clarifications to the last two sentences.

Roger, would you mind sending this out to tor-relays, and the usual places tor relay operators can be found?


Subject: Opt-In Trial: Fallback Directory Mirrors

Dear Relay Operators,

TL;DR: Stable non-exit relays can help tor clients use the Tor network. Please opt-in!

We want to run a trial of fallback directory mirrors (fallbacks) in Tor. Tor clients contact fallbacks to download the consensus during initial bootstrap, before they contact the directory authorities.

Fallbacks allow Tor to bootstrap in networks that block the Tor directory authorities. This allows people to use Tor without manually configuring bridges or pluggable transports.

For more information about fallbacks, see:
https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors

For this trial, we want to find around 100 stable non-exit relays, as exits currently experience high load.

We want relays that expect to be stable for the next 2 years, with:

  • good uptime,
  • the same IP address(es) and port,
  • the same relay identity key,
  • good bandwidth and network connectivity.

In December 2015, we created a list of ~400 candidate fallbacks.
https://trac.torproject.org/projects/tor/attachment/ticket/15775/fallback_dirs.inc

If your relay is on this list, and you expect it to be on the same IP address(es) and port for at least 2 years, please consider opting-in for this trial. (Relays that aren't on the list are welcome to opt-in. They will be considered in future releases, or if the selection criteria change.)

For the initial fallback release, we will only add your relay if you give us permission. Please reply on the tor-relays mailing list, if you are able. (Opt-ins, opt-outs, and fallbacks chosen for inclusion in tor, will be managed using lists in the publicly available tor git repository.)

comment:16 Changed 4 years ago by teor

Parent ID: #15775

comment:17 Changed 4 years ago by nickm

I timed-out on waiting for Roger, who is very busy, and sent it to tor-relays myself.

comment:18 in reply to:  17 Changed 4 years ago by teor

Replying to nickm:

I timed-out on waiting for Roger, who is very busy, and sent it to tor-relays myself.

I didn't get the email, and it's not in the archives.
(Neither is it in tor-dev or tor-talk.)

Did it get caught on a filter somewhere?

comment:19 Changed 4 years ago by nickm

Whoops; sent it from the wrong address. Just re-sent.

comment:20 Changed 4 years ago by nickm

Owner: set to teor
Status: needs_reviewassigned

Okay, the emails are coming in. I think this is no loner needs_review; putting it in reassigned. Teor, please unassign it if this isn't for you.

comment:21 Changed 4 years ago by teor

I will collate the emails and submit a fallback whitelist patch, probably in January.

Please feel free to forward any replies to your own email to my email, after stripping out everything except the relay details, of course!

comment:22 Changed 4 years ago by nickm

Keywords: TorCoreTeam201601 added; TorCoreTeam201512 removed

comment:23 Changed 4 years ago by teor

As of Tue 22 Dec 2015 11:42 UTC, we have had 29 relay operators opt-in their relays as fallback directories. (I think about 23 of those are on the list.)

comment:24 Changed 4 years ago by teor

Merged an initial set of fallback directories in #18086.

Keeping this task open as we are only have 21 of the desired 100 fallback directories for 0.2.8. I expect that resolving #18050 will increase these numbers 120 days after the 0.2.7.6 release. (As the 0.2.7.7 release will no longer cause relays to drop from the fallback list.)

comment:25 Changed 4 years ago by teor

Keywords: TorCoreTeam201602 added; TorCoreTeam201601 removed

I will look at this again in February:

  • add new relays to the whitelist;
  • re-consider the stability period (30-120 days);
  • generate a new fallback directory list for the next 0.2.8 alpha series release.

comment:26 Changed 4 years ago by teor

Keywords: TorCoreTeam201603 added; TorCoreTeam201602 removed
Status: assignedneeds_revision
Type: taskenhancement

Please see my branch fallbacks-201602:

  • added another whitelist submission, and
  • regenerated the list of fallback directories.

There are now 23 fallback directories rather than 22, even when keeping the stability period at 30 days. This minor change isn't really worth merging yet, so I've placed it in needs-revision.

If we only have ~20 fallback directories at release time, that might not be enough for security or load-balancing. We might want to consider increasing the default authority weight, which would make clients load-balance between the authorities and the fallback directories.

I'll look at it again in March:

  • add new relays to the whitelist;
  • re-consider the stability period (30-120 days);
  • consider increasing the weight of authorities to enable load-balancing between authorities and fallbacks;
  • generate a new fallback directory list for the next 0.2.8 alpha series release.

comment:27 Changed 4 years ago by teor

My branch fallbacks-201602-v2 fixes #18398.
https://github.com/teor2345/tor.git

It also reduces the stability period to 7 days, relying on the uptime cutoffs to enforce stability, due to #18050, which causes relays to upload descriptors with an 0 DirPort when restarted.

There are now 34 fallback directories.

comment:28 Changed 4 years ago by nickm

Merged that branch; do we close this one now?

comment:29 Changed 4 years ago by teor

Roger has recommended I contact some relay operators using their contact info, rather than depending on tor-relays.

This might help get the number of fallback directories up to 100 by 0.2.8-stable.

I also need to fix #18481, so we can tune the connection parameters in Tor Browser after release.

comment:30 Changed 3 years ago by isabela

Sponsor: SponsorUSponsorU-can

comment:31 Changed 3 years ago by teor

This doesn't need to be fixed for 0.2.8-rc.

We need a sufficient number of hard-coded fallback directory mirrors in any 0.2.8 point release that's in a stable Tor Browser release.

comment:32 Changed 3 years ago by teor

I also need to check the existing whitelist to see if any fallbacks have added an IPv6 address. Perhaps I could modify the script to print something if an IPv6 address is added and we don't have it whitelisted. I should also make sure it doesn't exclude them!

comment:33 Changed 3 years ago by teor

Keywords: must-fix-before-028-rc added

(Working on the list of relays now.)

comment:34 Changed 3 years ago by teor

Here is my template for the operator-specific emails:

Subject: Help Tor - Become a Fallback Directory Mirror

Dear Relay Operator,

Your relay(s) can help tor clients reach the tor network by becoming a fallback directory mirror.[0]
These mirrors are hard-coded into tor's source code, like the directory authorities.
We already have 30 fallback directory mirrors, but we'd like to have around 100.

Please reply to this email to opt-in the following relays as fallbacks in tor's 0.2.8 release:

<Insert Specific List of Relays Here>

You relay will need to have:

  • the same IP address(es) and ports for at least 2 years,
  • the same relay identity key for at least 2 years,
  • good uptime (at least 95%), and
  • good bandwidth and network connectivity (we estimate an extra 5TB per month[2]).

Please feel free to add the details of other relays that fit these criteria.
You can also opt-out if you know your relay will be changing address or identity key.

We already have 30 fallback directory mirrors, but we'd like to have around 100.
We're keeping the opt-ins and opt-outs submitted so far - no need to opt-in or opt-out again!
(I've tried to avoid emailing relay operators who've already opted in or opted out.)

If you're interested, here's some background to this request:

Nick Mathewson sent an email in December[1] asking relay operators to opt-in as a fallback directory mirror.
In January, I sent an update asking operators running under-utilised exits to also opt-in.[3]

The latest list[4] of candidates was generated earlier today from scripts/maint/updateFallbackDirs.py in my branch fallbacks-201604-v3 on [5]. (This branch has some bug fixes compared to what's in master.)

Tim

[0]: https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors
[1]: https://lists.torproject.org/pipermail/tor-relays/2015-December/008361.html
[2]: https://lists.torproject.org/pipermail/tor-relays/2015-December/008393.html
[3]: https://lists.torproject.org/pipermail/tor-relays/2016-January/008512.html
[4]: https://trac.torproject.org/projects/tor/attachment/ticket/15775/fallback_dirs.inc.20160406
[5]: https://github.com/teor2345/tor.git

comment:35 Changed 3 years ago by teor

Oh dear, there was a typo, that figure should be 50GB, not 5TB.

comment:36 Changed 3 years ago by teor

Actual Points: 2 weeks
Points: medium/largesmall-remaining

I created a list of ~200 fallback candidates with consensus weights 30,000 and above. I then emailed the relay operators using their Contact Info. (I didn't email operators of relays on the current whitelist and blacklist.)

If we need to, I can repeat this process with ~500 relays with consensus weights 3000 to 30,000. (3000 is 100 times the expected load of 30 kilobytes per second.) I'll exclude the relay operators I've contacted so far.

We can also repeat the entire opt-in mailout for 0.2.10 in 6 months. But, given the amount of effort it takes to run an opt-in process, I'd like to switch to opt-out instead.

I'll submit a branch before 0.2.8-rc, once relay operators have replied to my emails.

comment:37 Changed 3 years ago by nickm

Keywords: TorCoreTeam201604 added; TorCoreTeam201603 removed

comment:38 Changed 3 years ago by teor

Actual Points: 2 weeks3 weeks
Status: needs_revisionneeds_review

Please see my branch fallbacks-201604-v9, it changes:

  • the python script,
  • the whitelist and blacklist, and
  • the src/or/fallback_dirs.inc list of fallbacks.

(There are no C code changes.)

It's based on maint-0.2.8.

It also resolves #18689, #17905, and the 0.2.8 parts of #18749.

The list has 100 fallbacks, we could easily add another ~70 if we wanted to, and another ~100 if we allowed more than one fallback on the list from the same operator.
But let's hold them in reserve for future releases.

comment:39 Changed 3 years ago by teor

I've pushed a (large) number of fixups to the fallback whitelist to the branch as operator replies continue to trickle in.

One operator withdrew a fallback that was on the actual fallback list. I have pushed a fixup after rebuilding the fallback list. 11 fallbacks on the list changed (another turns up in the diff, but is just a reordering). It's good to see the list is stable, even though I changed 14 whitelist/blacklist entries.

It's worth noting that the smallest relay on this list could be able to handle the entire expected client load itself - it currently serves 2-3x the expected load from all clients. The largest relays could each handle the entire client load easily.

comment:40 Changed 3 years ago by isis

Reviewer: isis

comment:41 Changed 3 years ago by teor

(This has been merged to maint-0.2.8 and can be closed after review if there are no issues.)

comment:42 Changed 3 years ago by isis

Status: needs_reviewmerge_ready

(Putting into merge_ready state, even though it's already merged, in the event that maybe teor wants to fix cosmetic issues before closing.)

Some minor cosmetic issues:

  • The dateutil module is in the python-dateutil package, not builtin, so it should probably also be listed as a dependency.
  • After printing WARNING::Unable to import ipaddress, please install py2-ipaddress it just appears to hang forever. Maybe do sys.exit(1) if a required dependency is missing? Or maybe warn that it's actually okay except that the script won't do netblock analysis?
  • Do we want to raise these cutoffs now?
    # Reduced due to a bug in tor where a relay submits a 0 DirPort when restarted
    # This causes OnionOO to (correctly) reset its stability timer
    # This issue will be fixed in 0.2.7.7 and 0.2.8.2
    # Until then, the CUTOFFs below ensure a decent level of stability.
    ADDRESS_AND_PORT_STABLE_DAYS = 7
    
  • I get a bunch of these warnings: WARNING::Consensus download: 23.1s too slow from IPredator (197.231.221.211:9030), max download time 15.0s. for various relays which, like iPredator, I know are fast. (It's obvious this is due to my running the script through torsocks, but it wasn't clear to me that I shouldn't do that. It also seems odd to have the cutoff time hardcoded to 15s, since for all I (or the script) know, my roommate could be torrenting a bunch of anime and oopsies now it picks completely different fallbacks.)
  • In cleanse_unprintable():
      for c in raw_string:
        if (c in string.ascii_letters or c in string.digits
            or c in string.punctuation or c in string.whitespace):
    [...]
    
    You could also just use string.printable.
  • # sockets, which is why we long this line here s/long/log/

Replying to teor:

(This has been merged to maint-0.2.8 and can be closed after review if there are no issues.)

Overall the script LGTM. I'm willing to call this done.

comment:43 in reply to:  42 ; Changed 3 years ago by teor

Status: merge_readyneeds_review

Replying to isis:

(Putting into merge_ready state, even though it's already merged, in the event that maybe teor wants to fix cosmetic issues before closing.)

I'd like to fix these issues - see my branch fallback-script on https://github.com/teor2345/tor.git

Some minor cosmetic issues:

  • The dateutil module is in the python-dateutil package, not builtin, so it should probably also be listed as a dependency.

Added dateutil as a dependency in the comments.

46d8139 Improve comments in fallback update script

  • After printing WARNING::Unable to import ipaddress, please install py2-ipaddress it just appears to hang forever. Maybe do sys.exit(1) if a required dependency is missing? Or maybe warn that it's actually okay except that the script won't do netblock analysis?

Clarified that particular log message to say the dependency is optional.

Logged two additional messages about activities that may take some time:

  • before we download Onionoo data
  • before we download a consensus from each potential fallback

Also made the log levels more consistent: ideally the script should show a few messages at warning level about relays that almost made it to being a fallback, and then a reason for every relay at info level.

d41f92b Improve logging in fallback update script

  • Do we want to raise these cutoffs now?
    # Reduced due to a bug in tor where a relay submits a 0 DirPort when restarted
    # This causes OnionOO to (correctly) reset its stability timer
    # This issue will be fixed in 0.2.7.7 and 0.2.8.2
    # Until then, the CUTOFFs below ensure a decent level of stability.
    ADDRESS_AND_PORT_STABLE_DAYS = 7
    

Sadly, no, there's no 0.2.7.7 yet. And 0.2.6 - 0.2.4 relays are still affected by that bug.
I've put it on the list of things to review for the 0.2.9 fallback list in #18828.

  • I get a bunch of these warnings: WARNING::Consensus download: 23.1s too slow from IPredator (197.231.221.211:9030), max download time 15.0s. for various relays which, like iPredator, I know are fast. (It's obvious this is due to my running the script through torsocks, but it wasn't clear to me that I shouldn't do that. It also seems odd to have the cutoff time hardcoded to 15s, since for all I (or the script) know, my roommate could be torrenting a bunch of anime and oopsies now it picks completely different fallbacks.)

I had this issue as well when developing the script, my internet connection drops speed sometimes.

I wrote a comment about needing a good network connection at the top of the script, or disabling the consensus download checks.

46d8139 Improve comments in fallback update script

The script also retries failed downloads, to avoid excluding a fallback due to transient network issues.

I'm not sure what else could be done - do you think we should compare the entire set of times, and exclude those that are way too high?
But that still doesn't address transient network issues.

  • In cleanse_unprintable():
      for c in raw_string:
        if (c in string.ascii_letters or c in string.digits
            or c in string.punctuation or c in string.whitespace):
    [...]
    
    You could also just use string.printable.

Oops, I think I modified that line, and then didn't realise there was a simpler character class.

46d8139 Simplify string cleansing in fallback update script

  • # sockets, which is why we long this line here s/long/log/

46d8139 Improve comments in fallback update script

Replying to teor:

(This has been merged to maint-0.2.8 and can be closed after review if there are no issues.)

Overall the script LGTM. I'm willing to call this done.

Then let's merge and close if you're happy with the cosmetic changes.

comment:44 Changed 3 years ago by nickm

Keywords: TorCoreTeam201605 added

Calling all non-needs_information tickets for May.

comment:45 Changed 3 years ago by nickm

Keywords: TorCoreTeam-postponed-201604 added; TorCoreTeam201604 removed

April is over; calling these april tickets postponed into may.

comment:46 Changed 3 years ago by nickm

Keywords: review-group-1 added

comment:47 in reply to:  43 Changed 3 years ago by isis

Status: needs_reviewmerge_ready

Replying to teor:

Replying to isis:

I'd like to fix these issues - see my branch fallback-script on https://github.com/teor2345/tor.git


Okay, all the fixes work for me.

  • Do we want to raise these cutoffs now?
    # Reduced due to a bug in tor where a relay submits a 0 DirPort when restarted
    # This causes OnionOO to (correctly) reset its stability timer
    # This issue will be fixed in 0.2.7.7 and 0.2.8.2
    # Until then, the CUTOFFs below ensure a decent level of stability.
    ADDRESS_AND_PORT_STABLE_DAYS = 7
    

Sadly, no, there's no 0.2.7.7 yet. And 0.2.6 - 0.2.4 relays are still affected by that bug.
I've put it on the list of things to review for the 0.2.9 fallback list in #18828.


Ack, makes sense.

  • I get a bunch of these warnings: WARNING::Consensus download: 23.1s too slow from IPredator (197.231.221.211:9030), max download time 15.0s. for various relays which, like iPredator, I know are fast. (It's obvious this is due to my running the script through torsocks, but it wasn't clear to me that I shouldn't do that. It also seems odd to have the cutoff time hardcoded to 15s, since for all I (or the script) know, my roommate could be torrenting a bunch of anime and oopsies now it picks completely different fallbacks.)

I had this issue as well when developing the script, my internet connection drops speed sometimes.

I wrote a comment about needing a good network connection at the top of the script, or disabling the consensus download checks.

46d8139 Improve comments in fallback update script

The script also retries failed downloads, to avoid excluding a fallback due to transient network issues.

I'm not sure what else could be done - do you think we should compare the entire set of times, and exclude those that are way too high?

But that still doesn't address transient network issues.


Meh, I think it's fine to just include the comment at the top that says you shouldn't be running it on a flaky network.

Replying to teor:

(This has been merged to maint-0.2.8 and can be closed after review if there are no issues.)

Overall the script LGTM. I'm willing to call this done.

Then let's merge and close if you're happy with the cosmetic changes.


Changing to merge_ready. Thanks, teor!

comment:48 Changed 3 years ago by nickm

Resolution: implemented
Status: merge_readyclosed

merged to maint-0.2.8 and forward. Thanks, all!

comment:49 Changed 3 years ago by isabela

Points: small-remaining0.4
Note: See TracTickets for help on using tickets.