Upgrade our Chutney fork and make configuration more similar to the real Tor network
We haven't updated our Chutney fork since 2016. Current diffstat is: 139 files changed, 3401 insertions(+), 712 deletions(-).
Using configuration and code that was developed for a somewhat antique version of tor will likely cause trouble at some point.
I've noticed this because our suite sets deprecated options in torrc for Chutney usage:
Jun 10 19:38:59 amnesia tor: Jun 10 19:38:59.126 [warn] The configuration option 'TestingBridgeDownloadSchedule' is deprecated; use 'TestingBridgeDownloadInitialDelay' instead. Jun 10 19:38:59 amnesia tor: Jun 10 19:38:59.126 [warn] The configuration option 'TestingClientConsensusDownloadSchedule' is deprecated; use 'TestingClientConsensusDownloadInitialDelay' instead. Jun 10 19:38:59 amnesia tor: Jun 10 19:38:59.126 [warn] The configuration option 'TestingClientDownloadSchedule' is deprecated; use 'TestingClientDownloadInitialDelay' instead.
Upstream Chutney has removed all DownloadSchedule torrc options from these templates so in this case, it's no big deal.
#5 Updated by hefee about 1 month ago
Here is another patch for chutney to be more like the current Tor network, to let tests passes that do time screws.
#6 Updated by anonym about 1 month ago
- Subject changed from Upgrade our Chutney fork and make configuratoin more similar to the real Tor network to Upgrade our Chutney fork and make configuration more similar to the real Tor network
I'll use hefee's work on https://salsa.debian.org/hefee/chutney/merge_requests/1
#8 Updated by anonym about 1 month ago
- % Done changed from 0 to 10
- Feature Branch set to feature/16792-update-chutney+force-all-tests
The current branch updates chutney, and I've at least verified that tor bootstraps. I saw some initial failures with htpdate (restarting the services fixed it), not sure why is that or if it was a transient thing.
Any way, let's see what a full run looks like.
We used to get consensuses looking like this:
valid-after 2019-06-26 10:12:00 fresh-until 2019-06-26 10:15:00 valid-until 2019-06-26 10:18:00 voting-delay 4 4
i.e. really short intervals/delays. In the real Tor network it looks like this:
valid-after 2019-06-26 09:00:00 fresh-until 2019-06-26 10:00:00 valid-until 2019-06-26 12:00:00 voting-delay 300 300
I've adjusted the
*V3Auth*settings so they now have the same length intervals etc as the real Tor network:
valid-after 2019-06-26 11:31:00 fresh-until 2019-06-26 12:31:00 valid-until 2019-06-26 14:31:00 voting-delay 300 300
That should be all we need for #16471, but there are other discrepancies too (e.g. the real Tor network use
consensus-method 28but we get
consensus-method 25for some reason, but this is just an example -- I don't think we care about this one).