Drop or replace turtles
It just crossed my mind that we don't have anything tracking this. Lets fix that.
Mike lacks either the time or interest in maintaining turtles. He'd like to hand it off to somebody, but the status quo is not ok. We have a directory authority that's so unmaintained I've given up even reporting problems with it any longer.
We need to do one of the following...
a. Find a new maintainer for turtles. b. Replace turtles with another authority. c. Just drop it from the authority list.
Option 'c' is obviously the easiest, but I suspect we'd rather 'a' or 'b' to maintain the odd authority count.
This issue isn't of terribly great urgency, but it has persisted for the better part of a year so we should finally track and fix it.
Cheers! -Damian
Activity
changed milestone to %Tor: 0.2.6.x-final
Oh, on a side note turtles is presently using Tor 0.2.5.1-alpha-dev...
https://atlas.torproject.org/#details/F397038ADC51336135E7B80BD99CA3844360292B
That's evidently too old to participate in making the consensus.
I think we should ask for specific properties in a dir auth system and specific properties in a dir auth operator. Mike is someone that we trust very strongly and we must not disregard this aspect of his dir auth.
We should ask for specific properties from each operator - for example we - the community - want:
- A person that is trusted by the tor community
- A person who wants to run a dir auth
- A server on a fast connection with a very friendly ISP
- 99.999% up time
- Always running git tip or a recommended version
- We want a response to emails to dir-auth@ within 14 calendar days
- We want emergency contact information for each operator
- To know about planned downtime in advance
- To keep important data up to date (such as measurements, etc)
- ???
There is probably more - how would we rate the current set and not just Turtles? What other properties do we want or need?
Given the above list, urras is OK on all points except point 9. Is that true for all people who run dir-auths?
I think that if we remove turtles, we should add another dir-auth. If we don't do that, I think it is fine to leave his non-functioning dir-auth in the mix for everything except bootstrapping.
Replying to ioerror:
We should ask for specific properties from each operator - for example we - the community - want:
For the original (I think mostly still valid) list, there is: https://gitweb.torproject.org/torspec.git/blob/HEAD:/attic/authority-policy.txt
I think that if we remove turtles, we should add another dir-auth. If we don't do that, I think it is fine to leave his non-functioning dir-auth in the mix for everything except bootstrapping.
Sounds plausible to me. Having 8 vs having 9 with one always down is basically the same, from a consensus perspective. But you're right that it's not the same from a client bootstrapping perspective. It sure would be nice to get the FallbackDir feature going by default.
At one point we discussed the overall imbalance of DirAuths in North America and Europe. This disproportionate number in a particular network geography results in heavier weighting for exits that are measured by those DirAuths as having good network connectivity. Those DirAuths will favor exits that are closer to them as having "better" bandwidth, than those far away. As an example, I had an exit in Cambodia that was on a 100mbit/sec connection, but because the DirAuths were so far away their measurements resulted in that exit being weighted much lower and thus the amount of traffic it served was significantly less than it could do (something like 2-5mbit/sec). This seems less than ideal, especially if we want to increase the usability of tor in areas of the world other than N. America/Europe.
I think having specific DirAuth criteria are important, but developing an overall strategy for strategic placement seems important as well. As the authority-policy that arma details, "It's good when authorities are not all in the same country." - I'd argue that this should be expanded beyond nation/state boundaries and consider network geography as a criteria as well.
On another note, I think that Riseup could offer to host a DirAuth, either in Hong Kong, possibly in Cambodia, or in Seattle.
-
Replying to micah:
At one point we discussed the overall imbalance of DirAuths in North America and Europe. This disproportionate number in a particular network geography results in heavier weighting for exits that are measured by those DirAuths as having good network connectivity. Those DirAuths will favor exits that are closer to them as having "better" bandwidth, than those far away.
I agree with the sentiment here -- but I'll also note that Micah is referring to bandwidth authorities, which can be run next to directory authorities but don't have to be. That is, the bwauths are just scripts that can be run from anywhere, and they output a bwscan.V3BandwidthsFile file that a directory authority can use to influence its votes. So location diversity for the dir auths, and location diversity for the bwauths, are both fine goals but they can be achieved separately.
On another note, I think that Riseup could offer to host a DirAuth, either in Hong Kong, possibly in Cambodia, or in Seattle.
Intriguing! This idea would work best if it's run by a specific person (or small group of persons) that we know, that have come to a few dev meetings and met all the Tor people, etc.
-
Replying to arma:
Replying to micah:
I agree with the sentiment here -- but I'll also note that Micah is referring to bandwidth authorities, which can be run next to directory authorities but don't have to be. That is, the bwauths are just scripts that can be run from anywhere, and they output a bwscan.V3BandwidthsFile file that a directory authority can use to influence its votes. So location diversity for the dir auths, and location diversity for the bwauths, are both fine goals but they can be achieved separately.
Good point! I indeed was talking about bwauths, when this issue is about dir auths... apologies for the mixup.
On another note, I think that Riseup could offer to host a DirAuth, either in Hong Kong, possibly in Cambodia, or in Seattle.
Intriguing! This idea would work best if it's run by a specific person (or small group of persons) that we know, that have come to a few dev meetings and met all the Tor people, etc.
It would be primarily run by me, like all the other Tor-related things that Riseup does. Although I've never been to a dev meeting, I have met quite a few of the Tor people.
The whole bwauth and exit measuring thing is completely brittle, and I don't think the relay in Cambodia will necessarily score much better just because a bwauth is located in Cambodia. The bwauth voting code uses the low median for its result, so nothing much will change. The other point is that the huge majority of relays is located in NA/Europe, so whenever you make an actual circuit through a node which isn't you'll get a slower result. Also, are we actually asking exits to fetch the bwauth files directly? I thought we used all nodes as middle node to avoid trivial cheating by increasing priority for bwauth traffic, but I'm not certain on this point.
I'd like to second Micah's offer to run a DirAuth. He is well known and great all around. His services with RiseUp are well run - he is one of the best SysAdmins that I've ever met (after weasel).
Micah - I'd love it if you could run your DirAuth in Asia - either in Hong Kong or elsewhere. I'd even donate some money to help make sure that the host has equipment for various kinds of protection.
Roger - what are the next steps for Micah to run a DirAuth?
-
It seems, from the discussion above, that for a DirAuth it doesn't seem like putting it in Asia provides any additional benefit than anywhere else. If that is true, and a DirAuth is not that bandwidth intensive, I'd be more comfortable with running it in Seattle where we have more physical control, and would love to talk to ioerrror about additional protection equipment!
Can you provide me with details about the configuration, and bandwidth requirements that would be needed?
-
I've put the relay 'longclaw' online in Hong Kong, it can be found at:
https://atlas.torproject.org/#details/74A910646BCEEFBCD2E874FC1DC997430F968145
(a longclaw is a member of the Motacillidae family of small passerine birds with medium to long tails: https://en.wikipedia.org/wiki/Longclaw)
Replying to micah:
It seems, from the discussion above, that for a DirAuth it doesn't seem like putting it in Asia provides any additional benefit than anywhere else.
Please put it in Asia - this will allow clients to bootstrap entirely from a node outside of the EU and US networks. This is important! It would also be nice to see the BW measurement running near the DirAuth. We need some actual diversity!
If that is true, and a DirAuth is not that bandwidth intensive, I'd be more comfortable with running it in Seattle where we have more physical control, and would love to talk to ioerrror about additional protection equipment!
I'm a big fan of mercury switches, hidden cameras and some other stuff. :)
Can you provide me with details about the configuration, and bandwidth requirements that would be needed?
We have git repo with dirauth configs. First up - your relay should stay up for a while and be stable. After it has been running for a while, I'd propose you write a patch to config.c (see previous diffs) and then Roger or someone else will merge it if/when they feel you meet the criteria.
-
What version should I run?
I notice that 'moria' runs an alpha, and 'tor26' runs an RC:
https://atlas.torproject.org/#details/9695DFC35FFEB861329B9F1AB04C46397020CE31 https://atlas.torproject.org/#details/847B1F850344D7876491A54892F904934E4EB85D
Should I use the one provided by:
http://deb.torproject.org/torproject.org tor-experimental-0.2.5.x- main
?
-
Replying to ioerror:
Replying to micah:
It seems, from the discussion above, that for a DirAuth it doesn't seem like putting it in Asia provides any additional benefit than anywhere else.
Please put it in Asia - this will allow clients to bootstrap entirely from a node outside of the EU and US networks. This is important! It would also be nice to see the BW measurement running near the DirAuth. We need some actual diversity!
Ok, I'll focus on the DirAuth here, and take the BWAuth separately.
Can you provide me with details about the configuration, and bandwidth requirements that would be needed?
We have git repo with dirauth configs.
Can you provide me the URI for the git repo?
-
I've made the necessary changes to config.c to resolve this issue, they are available in branch bug/13296 from here:
https://git.torproject.org/user/hacim/tor.git
There are two commits in this branch:
- adds longclaw as a v3 directory authority
- removal of turtles as a v3 directory authority
note that these commits are signed, so you can verify that they are actually from me, and that I am the one who controls the authkey to generate the certificate. You can verify the signatures by doing git log --show-signature, or individually as:
git show --show-signature 9c60ad5ed44a3809b7ff34ec38a31b0f626249a2 git show --show-signature efca0668bec8d043408e23cf93274d9a9b93ca35
Once these are merged in, I'll work with Sebastian to coordinate with the dirauth ops.
Please do not remove Mike's DirAuth without him making the commit to remove it and without him talking here. It is absurd that he hasn't replied but it is also absurd that we'd remove it without him commenting here. It seems absurd to do this and replace it with a new relay at the same time.
Let us just add Micah's new DirAuth and not remove Turtles at this time.
I fully support transitioning my directory authority to Micah. I am willing to ensure it does not come back up after we add Micah's node, or keep it up for older clients, or however we want to do this.
I am not sure we buy a whole lot by ensuring the node is in Asia.. I'd be happier if we had better physical security for it, but I'm not sure I feel so strongly about this that it is worth arguing.
Replying to micah:
I've put the relay 'longclaw' online in Hong Kong, it can be found at:
Does the host have IPv6 connectivity? If so, please add another ORPort with the IPv6 address within square brackets (leaving the port number and the ':' outside of the brackets). Here's how maatuska configure IPv6:
ORPort [2001:67c:289c::9]:80
Trac:
Cc: Sebastian, mikeperry to Sebastian, mikeperry, tom@ritter.vgUpdated Stem, so by extension DocTor is now tracking longclaw rather than turtles.
-
The new consensus-health codebase is using tip-of-stem. I'm not sure when the consensus-health.torproject.org webpage will be cut over, but the new codebase is running and viewable at http://utternoncesense.com/ and includes longclaw. (It is omitted from the top 'Signatures' section because it lacks the Authority flag, and therefore it's signature is not included in the consensus.)
-
I think merging anytime is fine.
It won't hurt users much, because they'll swap out a dir auth that isn't up for a dir auth that isn't signing the current consensus.
And authority operators are hopefully now paying attention to when and whether they should upgrade, and having them just be able to move to git if that's easy for them will be a plus.
-
Replying to mikeperry:
I am willing to [...] keep it up for older clients, or however we want to do this.
Mike: I think the right answer here is to keep it up at the old address, with the old relay identity key, and not configured as a directory authority. That way it'll be a nice dir cache and provide answers to clients that happen to try to bootstrap from it.
-
Replying to nickm:
I've cherry-picked those three commits to maint-0.2.4. (They seem to have been against release-0.2.4, which is not what we do: see doc/HACKING.)
Ok, sorry about that. I made the originals on top of the original master, didn't realize about the other branch, thanks for pointing me to the doc/HACKING.
moved to tpo/core/tor#13296 (closed)
