From: Richard Johnson <rdump@river.com> To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] Platform diversity in Tor network [was: OpenBSD doc/TUNING]

On 2014-11-05 10:47, Libertas wrote:

...

I appreciate your interest! Also, I hope I'm not speaking with too much authority. If anyone here has more OpenBSD experience than me, please send addendums or corrections.

Maybe call this an addendum? Some version of the following work in progress is going onto our local documentation store for others maintaining our OpenBSD relays.

It's a bit long-winded for inclusion in doc/TUNING per https://trac.torproject.org/projects/tor/ticket/13702 , as it's intended to educate *BSD and Linux sysadmins about a smidgen of the why behind the tuning recommendations, as well as point at further exploration.

Richard

------- Our OpenBSD tuning for Tor involves: ... 4) Probably running more than one relay on a host to use available CPU cores and bandwidth. ... 4) Loading more CPU cores

If you have one of your CPUs maxed out running a Tor relay, with the other CPU(s) mostly idle (see top(1)), yet you have bandwidth to spare still, you can run additional Tor instances to sop some of it up.

The sanest way to handle this is to make each relay a stand-alone entity with a naming scheme to keep them straight. Here, we'll use "tor#" for every relay past the first.

Make per-relay directories in /var owned by _tor:_tor mode 700 drwx------ 5 _tor _tor 512 Jan 13 18:52 /var/tor/ drwx------ 5 _tor _tor 512 Jan 13 22:39 /var/tor2/ drwx------ 5 _tor _tor 512 Jan 13 22:39 /var/tor3/ ... Copy the tor startup script /etc/rc.d/tor to match the naming scheme. /etc/rc.d/tor2 /etc/rc.d/tor3 ... Copy the torrc from /etc/tor/torrc. /etc/tor/torrc2 /etc/tor/torrc3 ... Modify /etc/tor/torrc2, /etc/tor/torrc3, ... so they refer to their appropriate private DataDirectory and PidFile, listen on the appropriate ports and IP addresses, and have the appropriate exit policies. (Remember that the public Tor network will by design ignore more than two relays per IP address.) DataDirectory /var/tor2 PidFile /var/tor2/pid ControlPort 9222 Address 10.2.2.2 ORPort 8222 DirPort 7222 ... DataDirectory /var/tor3 PidFile /var/tor3/pid ControlPort 9333 Address 10.3.3.3 ORPort 8333 DirPort 7222 ... Set each relay to launch at system startup via the named /etc/rc.d scripts in /etc/rc.conf.local's pkg_scripts. tor_flags="${tor_flags} -f /etc/tor/torrc" tor2_flags="${tor2_flags} -f /etc/tor/torrc2" tor3_flags="${tor3_flags} -f /etc/tor/torrc3" ... pkg_scripts=" ... tor tor2 tor3 ..." Set openfiles-max for each named pkg_script from /etc/rc.conf.log in /etc/login.conf. tor:\ :openfiles-max=8192:\ :tc=daemon: tor2:\ :openfiles-max=8192:\ :tc=daemon: tor3:\ :openfiles-max=8192:\ :tc=daemon: ... Remember to allow inbound traffic to the additional ports set in /etc/tor/torrc[#] in your /etc/pf.conf.

Why give advice on "tor3" when the current consensus parameter for limit per IP is 2? In case someone has an extra IP? Or are you hoping we will increase the consensus parameter to 3? I could revive that suggestion, by the way - it stalled as trac #13414 due to concerns with making sybils easier. https://trac.torproject.org/projects/tor/ticket/13414 Maybe we could try for 3 per IP? teor pgp 0xABFED1AC hkp://pgp.mit.edu/ https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 http://0bin.net/paste/Mu92kPyphK0bqmbA#Zvt3gzMrSCAwDN6GKsUk7Q8G-eG+Y+BLpe7wt...