Add Faravahar directory authority
Sina has been running Faravahar in a stable way for a few months now.
We should put it into the main authority list at some point.
If I understand correctly, we still need to do the timed upgrade dance among current authority operators, to avoid partitioning things and failing to achieve any consensus?
Activity
changed milestone to %Tor: 0.2.3.x-final
Replying to arma:
If I understand correctly, we still need to do the timed upgrade dance among current authority operators, to avoid partitioning things and failing to achieve any consensus?
I think so, too. It's been a while that we did this dance.
SiNA, do you know how to generate a v3 identity and signing key? See this howto. Can you come up with the config line for Faravahar that will go into config.c? It should be something like this with FFFF... being the v3 identity key fingerprint (and without the line break):
Faravahar orport=443 no-v2 v3ident=FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 154.35.32.5:80 CF6D 0AAF B385 BE71 B8E1 11FC 5CFF 4B47 9237 33BCShould we try to include Faravahar in the upcoming 0.2.2.36? I guess if it will go into 0.2.2.37, that's going to take a while.
After experimenting with openssl 1.0.1c I decided to replace the Hardware to a much more powerful machine. This change should take about 7 more days as of today.
I am also experimenting with a reverse proxy over the DirPort. If this test is a success, I would like to host the directory port on a fancy DDoS mitigation device.
Faravahar and her cousin Matrix are back online, with a brand new and much larger server: 8 cores + 10 GB Ram. 2 x 1 Gbps Ethernet connected
Relay node : Matrix !154.35.32.6:80
RelayBandwidthRate 10000 KB # Throttle traffic to 100KB/s (800Kbps) RelayBandwidthBurst 20000 KB # But allow bursts up to 200KB/s (1600Kbps)
Authority node: Faravahar [154.35.32.5:80 154.35.32.5:80 &]154.35.32.5:443
RelayBandwidthRate 500 KB # Throttle traffic to 100KB/s (800Kbps) RelayBandwidthBurst 1000 KB # But allow bursts up to 200KB/s (1600Kbps)
processor : 7 vendor_id : GenuineIntel cpu family : 6 model : 26 model name : Intel(R) Xeon(R) CPU E5504 @ 2.00GHz stepping : 5 microcode : 0x11 cpu MHz : 1600.000 cache size : 4096 KB
Trac:
Username: mazda-
Faravahar's fingerprint, for add_default_trusted_dirservers() function in config.c:
Faravahar orport=443 no-v2 v3ident=F11467408C4B480453D4F71C7D206353DA47AE03 154.35.32.5:80 CF6D 0AAF B385 BE71 B8E1 11FC 5CFF 4B47 9237 33BCReplying to karsten:
Replying to arma:
If I understand correctly, we still need to do the timed upgrade dance among current authority operators, to avoid partitioning things and failing to achieve any consensus?
I think so, too. It's been a while that we did this dance.
SiNA, do you know how to generate a v3 identity and signing key? See this howto. Can you come up with the config line for Faravahar that will go into config.c? It should be something like this with FFFF... being the v3 identity key fingerprint (and without the line break):
{{{ Faravahar orport=443 no-v2 v3ident=FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 154.35.32.5:80 CF6D 0AAF B385 BE71 B8E1 11FC 5CFF 4B47 9237 33BC }}}
Should we try to include Faravahar in the upcoming 0.2.2.36? I guess if it will go into 0.2.2.37, that's going to take a while.
Trac:
Username: mazda
Milestone: Tor: 0.2.4.x-final to Tor: 0.2.3.x-final -
Done: 0001-Faravahar-added.patch.asc Download added
Replying to ioerror:
Sina, can you attach a patch for config.c and gpg sign it?
Trac:
Username: mazda
Status: new to needs_review
Cc: sina to sina, inf0@redteam.io -
Trac:
Username: mazda The last dirauth we added was maatuska. We set a time for the dirauths to set a new configuration (DirServer lines), and wanted all dirauths to upgrade at the same time. That didn't work out exactly as planned due to a bug that we discovered just on that day, but the transition did go through relatively smoothly. We should aim for all dirauth ops to be around when we do the transition. After that is done, we can add the new dirauth to the source and release a new version with it.
I hope I didn't misremember any details here...
Things will be more fun this time because some dir auths are upgrading to 0.2.4.x, which will have them using a new consensus method if enough do (which means the ones that don't will be cut out of the consensus). So this is both an opportunity to do two changes at once, and a risk because we have more ways to splinter.
I think we should do the addition in three phases. First, the traditionally-non-interactive authorities upgrade to 0.2.4.x and also add a pile of DirServers lines. Second, the group of most-responsive authorities coordinate to do a timed upgrade-and-add. At that point we'd be letting farahavar into the consensus. Last, whoever we missed upgrades-and-adds.
I think dannenberg and dizum should be in phase one. Then moria1, gabelmoo, tor26, maatuska are in phase two. That leaves turtles and urras for phase three. (Either of them are welcome to join us for phase two, if they're around.)
We can abort at phase two, and later back out the phase one changes, if something goes wrong.
-
If I have it right, here are the DirServer lines we want:
dirserver moria1 orport=9101 no-v2 v3ident=D586D18309DED4CD6D57C18FDB97EFA96D330566 128.31.0.39:9131 9695 DFC3 5FFE B861 329B 9F1A B04C 4639 7020 CE31 dirserver tor26 v1 orport=443 v3ident=14C131DFC5C6F93646BE72FA1401C02A8DF2E8B4 86.59.21.38:80 847B 1F85 0344 D787 6491 A548 92F9 0493 4E4E B85D dirserver dizum orport=443 v3ident=E8A9C45EDE6D711294FADF8E7951F4DE6CA56B58 194.109.206.212:80 7EA6 EAD6 FD83 083C 538F 4403 8BBF A077 587D D755 dirserver Tonga orport=443 bridge no-v2 82.94.251.203:80 4A0C CD2D DC79 9508 3D73 F5D6 6710 0C8A 5831 F16D dirserver turtles orport=9090 no-v2 v3ident=27B6B5996C426270A5C95488AA5BCEB6BCC86956 76.73.17.194:9030 F397 038A DC51 3361 35E7 B80B D99C A384 4360 292B dirserver gabelmoo orport=443 no-v2 v3ident=ED03BB616EB2F60BEC80151114BB25CEF515B226 212.112.245.170:80 F204 4413 DAC2 E02E 3D6B CF47 35A1 9BCA 1DE9 7281 dirserver dannenberg orport=443 no-v2 v3ident=585769C78764D58426B8B52B6651A5A71137189A 193.23.244.244:80 7BE6 83E6 5D48 1413 21C5 ED92 F075 C553 64AC 7123 dirserver urras orport=80 no-v2 v3ident=80550987E1D626E3EBA5E5E75A458DE0626D088C 208.83.223.34:443 0AD3 FA88 4D18 F89E EA2D 89C0 1937 9E0E 7FD9 4417 dirserver maatuska orport=80 no-v2 v3ident=49015F787433103580E3B66A1707A00E60F2D15B 171.25.193.9:443 BD6A 8292 55CB 08E6 6FBE 7D37 4836 3586 E46B 3810 dirserver Faravahar orport=443 no-v2 v3ident=EFCBE720AB3A82B99F9E953CD5BF50F7EEFC7B97 154.35.32.5:80 CF6D 0AAF B385 BE71 B8E1 11FC 5CFF 4B47 9237 33BC -
Tonight I told Andreas (dannenberg) that he should get started on phase one whenever he's ready. Once he does, we can get dizum to switch, and then proceed to phase two.
Trac:
Cc: sina, inf0@redteam.io to sina, inf0@redteam.io, al@ccc.de -
I suggest sometime on Saturday for the transition point?
Right now there are 5 authorities making up the consensus -- {tor26, moria1, gabelmoo, maatuska, dizum}. If we can get a core of {tor26, moria1, gabelmoo, maatuska} to join dannenberg, we'll still be at 5.
And at any time, turtles or urras are welcome to upgrade to a non-remotely-dosable version, and they might as well add Faravahar when they do.
Trac:
Cc: sina, inf0@redteam.io, al@ccc.de to sina, inf0@redteam.io, al@ccc.de, ln5, sebastian, weasel, mikeperry, ioerror The consensus-health scripts should start archiving faravahar's votes and consensus signatures now.
Trac:
Cc: sina, inf0@redteam.io, al@ccc.de, ln5, sebastian, weasel, mikeperry, ioerror to sina, inf0@redteam.io, al@ccc.de, ln5, sebastian, weasel, mikeperry, ioerror, karsten-
Replying to rransom:
The consensus-health scripts should start archiving faravahar's votes and consensus signatures now.
The consensus-health script now includes Faravahar, and metrics-db now downloads relay descriptors from Faravahar. Thanks for the heads-up!
moved to tpo/core/tor#5749 (closed)
