[tor-relays] new ansible-tor features: automatic instance configuration + automatic MyFamily generation (PATCH)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi David,
thanks for creating ansible-tor. I added two features that are crucial
to me and maybe useful for others as well. If you like it, feel free
to merge - this is my first ansible experience and it is lightly tested.
Example:
lets say you have added a new server to your inventory. The server has
3 public IP addresses (1.1.1.1, 2.2.2.2, 3.3.3.3). After running
ansible-tor with the new changes you will have the following 6 tor
instances/ORPorts running (without manually specifying IP addresses
first):
1.1.1.1:80
1.1.1.1:443
2.2.2.2:80
2.2.2.2:443
3.3.3.3:80
3.3.3.3:443
including MyFamily configuration across all servers/instances.
regards,
Nusenu
changes
===
- - auto instance deployment without manual IP/ORPort configuration (new)
starts 2 tor instances per available IP address by default
makes manually specifying IP addresses and ORPorts via
proc_instances obsolete
ORPorts default to 80 and 443 (DirPort not added yet)
replace single.yml + instances.yml - instance.yml only
(handles both cases dynamically)
- - MyFamily autogeneration (new)
Keeping all relay fingerprints in sync is probably one
of the most annoying tasks for a relay operator
managing multiple relays, now ansible takes care of this
(all relays need to be in the 'relays' group)
- - directory structure (changed)
defaults:
configs - /etc/tor/ip_orport.torrc
log dir - /var/log/tor/ip_orport.log
datadir - /var/lib/tor/ip_orport/
pid dir - /var/run/tor/ip_orport.pid
(previously everything was located in /etc)
- - added torrc sanity check (tor --verify-config ) (new)
- - torrc files are owned by root (previously owned by $tor_user)
- - the pid file check has been removed since the file is not required
to exist
(it will be created when tor starts)
open
- -
- - it does not take care of instance removals yet
(in case IPs are no longer available or amount of ORPorts have been
reduced)
- - allow opt-out - only 1 tor instance per host
(even if there are more IPs available)
- - DirPort support
- - detect RFC1918 IPs (opt-in)
-BEGIN PGP SIGNATURE-
iQIcBAEBCgAGBQJU4i+CAAoJEFv7XvVCELh0y+kP/i4Mn/XClgXYloGdgWU9UPR+
Y8yZv97FvJOMPI40tccPKcNPcLQFRvGFYkR96sAOGoMfbJT/tQeH2dOxwAEF31mv
afFkLsVPAOpNzlyO2qP1mkLtB/aYXtZ6jb2+JtpAhVBLKOVFBN2nNRiwdgFYZFGy
f0ZIp7xyR9XcAhXo4nc0hlETREAnbMOgFGM6vqqIpJfimF3liE6va5HNw2CD+7Zd
MmeIOuVNvQh09SiYf48AJpBeBRoybOvmFIPphtXEYlC/y6cd/IyUIYdOBuaLa5td
vQnrQOC7TUgp74uarl0yaatOYOEagl0lrNeN6+Vgy5e0e12TgVccWW5ZosM1PBXG
VH2FTfjHXUO+VN0p4xn6AS0dhWTRKb7isj3jpznTMsiq0AcvXM6DZjkzkcCPChVz
jptdUbNvgpdP7j5X11iZniGpxVe7aFo2wCzgZORY1xMysiigJsL4M/nonr4YO4G9
w7kyNcco9gStklJSvOJXbfX4HrOCuWdq8hp4xubyON+5jpEUgMmG1o/v5NJANV4C
CLzlz4kf9l9o351Z7DJQzilxzDEwe6oZwSWnsq+yB65Mgj5sUJnchi40iPLOHSUr
DaVSSUxoZ8VVNYqqvGYb2fysYa7DsCgofsF/eXP4QyJp1WFNwc0ft6qIhyAGIDwx
RfwQHrA+Lg95mdXDyr0B
=QHkD
-END PGP SIGNATURE-
diff --git a/defaults/main.yml b/defaults/main.yml
index ca5ad28..5f1f92c 100644
--- a/defaults/main.yml
+++ b/defaults/main.yml
@@ -1,14 +1,32 @@
---
-tor_instance_parent_dir: /etc/tor/instances
tor_user: debian-tor
-tor_DataDirectory: /var/lib/tor
-tor_PidFile: /var/run/tor/tor.pid
+tor_ConfDir: /etc/tor
+
+# Attention: we will run chown tor_user on these folders
+tor_PidDir: /var/run/tor
+tor_LogDir: /var/log/tor
+tor_DataDir: /var/lib/tor
+
+tor_LogLevel: notice
tor_RunAsDaemon: 1
-tor_Log: notice file /var/log/tor/log
tor_hidden_services_parent_dir: /var/lib/tor/services
tor_wait_for_hidden_services: no
+# The tor_ORPort array defines how many instances are created per
+# available IP address. It does not make sense to specify
+# more than two ports. If you want only one instance per IP use
+# tor_ORPorts: 443
+tor_ORPorts: [ 80, 443 ]
+
+#XXX: not implemented yet
+# the number of ORPorts and DirPorts must match
+#tor_DirPorts: [ '8080', '' ]
+
+tor_SocksPort: 0
+
+tor_ExitPolicy: reject *:*
+
tor_obfs4proxy_enabled: False
tor_obfs4proxy_release: sid
debian_repo: http://ftp.us.debian.org/debian/
diff --git a/tasks/configure_tor_instance.yml b/tasks/configure_tor_instance.yml
index 5a12672..b2fbc0e 100644
--- a/tasks/configure_tor_instance.yml
+++ b/tasks/configure_tor_instance.yml
@@ -1,47 +1,89 @@
---
-- name: ensure tor instance parent dir exists
+- name: ensure tor DataDir(s) exist
file:
-path={{ tor_instance_parent_dir }}
+path={{ tor_DataDir }}/{{ item[0] }}_{{ item[1] }}
state=directory
owner={{ tor_user }}
+mode=0700
+ with_nested:
+ - {{ ansible_all_ipv4_addresses }}
+ - tor_ORPorts
-- name: ensure tor instances data dir exist
+- name: ensure tor log file(s) are not world readable
file:
-path={{ tor_instance_parent_dir }}/{{ item.name }}/data
-state=directory
-owner={{ tor_user }}
- with_items: proc_instances
-
-- name: ensure tor instances log file exist
Re: [tor-relays] tor weather not sending emails?
Just another update about this. It took about a day for Tor Weather to report that a different server went down... It took about 3 days for it to notice the first server went down. So, it's slower than molasses, but it will report system failures eventually. -- Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] new ansible-tor features: automatic instance configuration + automatic MyFamily generation (PATCH)
Hi Nusenu, Thanks for the patch. You've added quite a bit more features than 2. Would you mind telling me which 2 features are critical for your use-case and why? Can you share your ansible-tor playbook? Perhaps a redacted copy if you have sensitive information in it... I'd like for this ansible role to be useful to relay operators like yourself... so I'm very interested in learning about how you'd like to use it. Why do you think the ORPorts should default to 80 and 443? Are you operating an exit relay? This is a good idea - added torrc sanity check (tor --verify-config ) I think your auto tor instance deployment feature should be an optional feature that is off by default. The collecting fingerprints idea seems great for the myfamily torrc option is definitely a good idea. If using configure_apt_single.yml then the torrc is in fact owned by root... and tor will then drop prives. The other way tor is deployed with this role is using the configure_tor_instance.yml... and i suppose the individual torrc files could be owned as root as long as they are readable by the tor user. But does this matter? What are the implications? I'd be much more likely to merge your patches if they were one feature per patch... instead of this monolithic patch with many features. Furthermore... I hate centralized media and all but github sure would make patch submission and review easier. I definitely do not need any gpg signature on patches submitted. Your code will be reviewed no matter who has signed your key. =-p Sincerely, David On Mon, Feb 16, 2015 at 5:57 PM, Nusenu nus...@openmailbox.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi David, thanks for creating ansible-tor. I added two features that are crucial to me and maybe useful for others as well. If you like it, feel free to merge - this is my first ansible experience and it is lightly tested. Example: lets say you have added a new server to your inventory. The server has 3 public IP addresses (1.1.1.1, 2.2.2.2, 3.3.3.3). After running ansible-tor with the new changes you will have the following 6 tor instances/ORPorts running (without manually specifying IP addresses first): 1.1.1.1:80 1.1.1.1:443 2.2.2.2:80 2.2.2.2:443 3.3.3.3:80 3.3.3.3:443 including MyFamily configuration across all servers/instances. regards, Nusenu changes === - - auto instance deployment without manual IP/ORPort configuration (new) starts 2 tor instances per available IP address by default makes manually specifying IP addresses and ORPorts via proc_instances obsolete ORPorts default to 80 and 443 (DirPort not added yet) replace single.yml + instances.yml - instance.yml only (handles both cases dynamically) - - MyFamily autogeneration (new) Keeping all relay fingerprints in sync is probably one of the most annoying tasks for a relay operator managing multiple relays, now ansible takes care of this (all relays need to be in the 'relays' group) - - directory structure (changed) defaults: configs - /etc/tor/ip_orport.torrc log dir - /var/log/tor/ip_orport.log datadir - /var/lib/tor/ip_orport/ pid dir - /var/run/tor/ip_orport.pid (previously everything was located in /etc) - - added torrc sanity check (tor --verify-config ) (new) - - torrc files are owned by root (previously owned by $tor_user) - - the pid file check has been removed since the file is not required to exist (it will be created when tor starts) open - - - - it does not take care of instance removals yet (in case IPs are no longer available or amount of ORPorts have been reduced) - - allow opt-out - only 1 tor instance per host (even if there are more IPs available) - - DirPort support - - detect RFC1918 IPs (opt-in) -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJU4i+CAAoJEFv7XvVCELh0y+kP/i4Mn/XClgXYloGdgWU9UPR+ Y8yZv97FvJOMPI40tccPKcNPcLQFRvGFYkR96sAOGoMfbJT/tQeH2dOxwAEF31mv afFkLsVPAOpNzlyO2qP1mkLtB/aYXtZ6jb2+JtpAhVBLKOVFBN2nNRiwdgFYZFGy f0ZIp7xyR9XcAhXo4nc0hlETREAnbMOgFGM6vqqIpJfimF3liE6va5HNw2CD+7Zd MmeIOuVNvQh09SiYf48AJpBeBRoybOvmFIPphtXEYlC/y6cd/IyUIYdOBuaLa5td vQnrQOC7TUgp74uarl0yaatOYOEagl0lrNeN6+Vgy5e0e12TgVccWW5ZosM1PBXG VH2FTfjHXUO+VN0p4xn6AS0dhWTRKb7isj3jpznTMsiq0AcvXM6DZjkzkcCPChVz jptdUbNvgpdP7j5X11iZniGpxVe7aFo2wCzgZORY1xMysiigJsL4M/nonr4YO4G9 w7kyNcco9gStklJSvOJXbfX4HrOCuWdq8hp4xubyON+5jpEUgMmG1o/v5NJANV4C CLzlz4kf9l9o351Z7DJQzilxzDEwe6oZwSWnsq+yB65Mgj5sUJnchi40iPLOHSUr DaVSSUxoZ8VVNYqqvGYb2fysYa7DsCgofsF/eXP4QyJp1WFNwc0ft6qIhyAGIDwx RfwQHrA+Lg95mdXDyr0B =QHkD -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] updating obfuscations in windows bridges
Yawning Angel: On Mon, 16 Feb 2015 10:30:57 + eliaz el...@riseup.net wrote: s I read it, the tor browser bundle 3.x FAQ [1] implies that bridges on windows can use only obfs3 of the provided pluggable transports. Can someone let me know if this is correct? Huh? What does a old browser bundle FAQ have to do with running bridges on windows? My apologies if my original query led you astray. It was only about the documentation being less helpful to windows users than it could be: The FAQ I referenced includes information about Tor Browser 3.x, but only mentions obfs3: If you've installed Obfsproxy, you'll need to add one more line: ServerTransportPlugin obfs3 exec /usr/bin/obfsproxy managed I went to that FAQ after not being able to incorporate any other transport lines into torrc for a windows implementation of the browser by using information in torrc-defaults. Tor documentation often leaves windows users (well, me at least) to figure out for ourselves by way of tedious experiments whether it applies generally, or only to Unix implementations. This was the case in torrc-defaults, which is what led me to wonder whether I had made a mistake when attempting to write the lines into torrc or if indeed the lines, except for obfs3, were inapplicable in windows. The obfs3 line (as described in torrc-defaults) works fine, but torrc won't even accept obfs2, let alone fteproxy or flashproxy. No one should use obfs2 for anything, it's deprecated. Yeah, I know that. I was just illustrating another case where torrc unexpectedly refused to accept a line. Would torrc in windows accept obfs4 ? If you have an obfs4proxy binary compiled for windows, you can run an obfs4 bridge on windows (as well as any of the other transports supported by obfs4proxy, which is currently obfs2/obfs3). Above my pay grade, sorry. I'll get around to it one of these days. I'm not really understanding the question... HTH - eliaz ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Again Hibernations vs. limits, for the extreme case
I run a relay with decently high bandwidth, but limited monthly transit (3TB out). https://globe.torproject.org/#/relay/2EC042F4274CC8A54381C78E8D1BF322FA26A095 I gathered from previous discussions that a fast node that goes into hibernation is more beneficial to the network than an artificially throttled node. So I set a hibernation limit and no speed limit. However, it looks like my node is fast enough to burn all the transit in a couple of days when it has consensus, and (1 month - 2 days) is enough time to get forgotten. So I'm probably stuck in a cycle of month 1. slowly ramp up speed and consensus; go into hibernation for a few days; lose the Guard flag (- get more traffic); month 2. burn all the transit in 2 days go into hibernation for 25 days GOTO month 1 Is it still the case that I shouldn't put throttling in, even if this means that each other month I'll run at really low speed to ramp up consensus? Or should I combine the Hibernate setting with a reasonable limit of maybe 1 MB/s? Or maybe use daily limits in this case? (Please CC me, I might not read in-list-only replies) Thanks, Filippo ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] new ansible-tor features: automatic instance configuration + automatic MyFamily generation (PATCH)
responding inline Would you mind telling me which 2 features are critical for your use-case and why? - - automatic instance deployment (and all the dependencies that comes with that, like ORListenAddress - without it tor0 would block tor2 from starting since they are binding on the same port) - - automatic MyFamily management this is just too annoying to manage manually OK. I'd like for this feature to co-exist with the current configure_tor_instance.yml... because other entities are currently using that... including Mozilla. - - the directory layout change is more cosmetic but your current way (everything in /etc) is rather unusual and as an example would require custom logrotate configuration that wouldn't be required otherwise OK... I don't have a strong opinion... and I think the parent directory for all this should be configuration via a role variable so that the user can specify. I'd like for this ansible role to be useful to relay operators like yourself... so I'm very interested in learning about how you'd like to use it. - From the examples I assumed you are probably not using it mainly for relays, is that correct? Yes that is correct. I operate many Tor hidden services. However I initially created this Ansible role to help Moritz of torservers.net and those people that may be working for him; therefore pull requests and feedback helps; for instance Moritz specified several features it should have... and an engineer working for Mozilla chatted with me about the features they needed; then he sent me a pull request on github. One could also add some auto detection to see if the ports are already in use.. I think the sys admin should just know what they are doing; and should know which ports are available. If using configure_apt_single.yml then the torrc is in fact owned by root... and tor will then drop prives. The other way tor is deployed with this role is using the configure_tor_instance.yml... and i suppose the individual torrc files could be owned as root as long as they are readable by the tor user. But does this matter? What are the implications? On a default install they are owned by root, I just reverted the change from owner=tor_user to owner=root to restore defaults. Implication.. tor_user will not be able to rewrite/manipulate its own configuration. Yes I agree. I'd be much more likely to merge your patches if they were one feature per patch... instead of this monolithic patch with many features. Yes, that is what I expected, but then I thought that the two main changes code wise (autoconfig + directory structure) are dependent on each other anyway. Merging autoconfig without the directory restructuring (or vice versa) wouldn't be much fun since these modifications always touch overlapping areas. If you want to add it as additional option, including it as a separate yml in tasks/main.yml + separate torrc is also a possibility - but probably not the nicest way (duplicate code, multiple torrc's). OK... I agree with you... but let's make this a seperate yml task file; your use is quite different than most of the entities currently using this ansible role. So let's add these as a new task file instead of modifying the existing task file. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [tor-assistants] Running obfs4proxy on Debian Stable
Alexander Dietrich transcribed 0.9K bytes: Ok, I'll bite: what would somebody have to know to make this happen? I know nothing of Ubuntu's policies for package inclusion in their distribution channels; you might try asking their developers. However, obfs4proxy will likely never be included in Debian wheezy-backports. [0] [0]: http://lists.alioth.debian.org/pipermail/pkg-anonymity-tools/Week-of-Mon-20150202/001119.html -- ♥Ⓐ isis agora lovecruft _ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt signature.asc Description: Digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] new ansible-tor features: automatic instance configuration + automatic MyFamily generation (PATCH)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi David, thanks for your quick feedback. Would you mind telling me which 2 features are critical for your use-case and why? - - automatic instance deployment (and all the dependencies that comes with that, like ORListenAddress - without it tor0 would block tor2 from starting since they are binding on the same port) - - automatic MyFamily management this is just too annoying to manage manually - - the directory layout change is more cosmetic but your current way (everything in /etc) is rather unusual and as an example would require custom logrotate configuration that wouldn't be required otherwise Can you share your ansible-tor playbook? Since everything tor process specific is handled in ansible-tor, my playbook will mainly just references the role. I'd like for this ansible role to be useful to relay operators like yourself... so I'm very interested in learning about how you'd like to use it. - From the examples I assumed you are probably not using it mainly for relays, is that correct? Why do you think the ORPorts should default to 80 and 443? It is assumed that these well known ports are less likely blocked by outbound firewalls and therefore more useful for clients than on some highports. Once dirport support is added, I would use 80 as dirport. For an example of common ORPorts see https://atlas.torproject.org/#search/contact:torservers ..but since it is very easy to modify the defaults, I've no strong feeling what is actually defined in default/main.yml. One could also add some auto detection to see if the ports are already in use.. I think your auto tor instance deployment feature should be an optional feature that is off by default. Yes that is fine, configuration changes are easy enough. If using configure_apt_single.yml then the torrc is in fact owned by root... and tor will then drop prives. The other way tor is deployed with this role is using the configure_tor_instance.yml... and i suppose the individual torrc files could be owned as root as long as they are readable by the tor user. But does this matter? What are the implications? On a default install they are owned by root, I just reverted the change from owner=tor_user to owner=root to restore defaults. Implication.. tor_user will not be able to rewrite/manipulate its own configuration. I'd be much more likely to merge your patches if they were one feature per patch... instead of this monolithic patch with many features. Yes, that is what I expected, but then I thought that the two main changes code wise (autoconfig + directory structure) are dependent on each other anyway. Merging autoconfig without the directory restructuring (or vice versa) wouldn't be much fun since these modifications always touch overlapping areas. If you want to add it as additional option, including it as a separate yml in tasks/main.yml + separate torrc is also a possibility - but probably not the nicest way (duplicate code, multiple torrc's). Furthermore... I hate centralized media and all but github sure would make patch submission and review easier. Yes, I'm considering it if this becomes something reoccurring. thanks, Nusenu -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJU4mGiAAoJEFv7XvVCELh0QMAQAIMmbJfJ1cLBdNXeRi+x9CLo LwYbFCP1FkMJHN6wfb/Q5wHejq88WIgUxUeob4KMVl30mCVxGIpOYZDb3rsvB3mi lIzFiZUt/eJo40Gjdx4/BgEArEaAsmOix2O8Ev6E84bl9J/zcp8EIFPcYhtrERJ/ zoV8iHeeJnuGGYa2zTDHS2ONtJ4lE7K/DX9NmVj45jmaHOKX8Y5o1klHSnNZ7yAR qGDRqvWlVeDwVRq+xXAyn1GK43SZPydNxZkHjMPmvKOAVGgIXgnxgtpmzj+87j/W UBB6waNmVfMJvCPreRM7Zgc2rhUAZx1TsIy78v3g7rWns0rd6hzm4lzzaP5aBhH0 8fK++UQMwPz+o7fIyKfiJLmP6TxxGk8AZpcrLXuCuDMfGi56/kHVp9P54xJSbYqV YNjVgVelAyZ62YB3tx3J+CWtOxbn3dHT0yllXDOQes6+/x0h7igod/2OWZBG6O6y SCEO2GPqMHx5ZLxvsCjio1FG1oPcMAT4lNOtNPDNxJPX5J8Vwkq4wmIDlj+zJM+m R8dOcqJ8sKtQx98rADlachXwFEFne9VEvqTj9oyq0O4szPx/jM9QAVhvAjlWqCM/ hJ+opaH/xhLs2Vu+UGqUosU23AO1p5fB+/KA4cY4CrrqJ1Inn687i3OWm6RC3cRi kg52xwIdT354yq6xpMCu =qFmI -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [tor-assistants] Running obfs4proxy on Debian Stable
On Sat, 14 Feb 2015 11:50:48 +0100 Alexander Dietrich alexan...@dietrich.cx wrote: So it's probably safer to wait for obfs4proxy to show up in Ubuntu repositories. Is there already a plan for that? There are no plans for this currently, and it is unlikely to happen unless someone steps up to do it. Regards, -- Yawning Angel pgpmuupux5jWY.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] updating obfuscations in windows bridges
On Mon, 16 Feb 2015 10:30:57 + eliaz el...@riseup.net wrote: s I read it, the tor browser bundle 3.x FAQ [1] implies that bridges on windows can use only obfs3 of the provided pluggable transports. Can someone let me know if this is correct? Huh? What does a old browser bundle FAQ have to do with running bridges on windows? The obfs3 line (as described in torrc-defaults) works fine, but torrc won't even accept obfs2, let alone fteproxy or flashproxy. No one should use obfs2 for anything, it's deprecated. Would torrc in windows accept obfs4 ? - thanks, eliaz If you have an obfs4proxy binary compiled for windows, you can run an obfs4 bridge on windows (as well as any of the other transports supported by obfs4proxy, which is currently obfs2/obfs3). I'm not really understanding the question... -- Yawning Angel pgpOcwxBJWQa3.pgp Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] updating obfuscations in windows bridges
s I read it, the tor browser bundle 3.x FAQ [1] implies that bridges on windows can use only obfs3 of the provided pluggable transports. Can someone let me know if this is correct? The obfs3 line (as described in torrc-defaults) works fine, but torrc won't even accept obfs2, let alone fteproxy or flashproxy. Would torrc in windows accept obfs4 ? - thanks, eliaz [1] https://www.torproject.org/docs/faq#TBB3.x ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
