-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hi,
computers are better at doing repeatable things over and over again so let them take care of boring tasks.
Based on David's ansible-tor [1] I created an ansible role to make relay operations more convenient (see the initial commit message for a longer list of changes).
https://github.com/nusenu/relayor
Core features:
- - configure multipe tor instances on a server automatically generates two instances per available IP address (Memory auto detection is not implemented yet) - - take care of MyFamily automatically - - user configurable Nickname prefix - - easy Exit/Non-Exit setting (boolean) - - alpha vs. stable releases (boolean)
Supported platforms: - Debian - CentOS - OpenBSD
Everything is still fresh, so I would NOT recommend to use this on production relays. Testing and review is appreciated.
There is still a crucial piece missing (init scripts), but I hope tor packagers are willing to incorporate multi-init support patches (see issues).
I also have parts that adds monitoring (munin+vnstat+webserver) but that will go into a separate role.
If you have never heard of ansible, it speaks to your servers using SSH and does not require an agent or a central management server - just run it from you client machine. http://www.ansible.com/resources (not entirely torbrowser friendly) http://docs.ansible.com
If you are planing to run this role over tor when connecting to your servers, make sure you have the following set in your ~/.ansible.cfg: ssh_args = -o ControlMaster=auto -o ControlPersist=60s
This ansible role is not about bridges or hidden services, but I'd like to add "management HSes" (SSH and monitoring) in the future.
Nusenu
[1] https://github.com/david415/ansible-tor
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
I'm sorry if you are looking for the repo, github decided to hide my account from the public.. (without sending an email notification about anything)
" One of our mostly harmless robots seems to think you are not a human. Because of that, it's hidden your profile from the public. "
On 2015-02-27 14:53, Nusenu wrote:
Supported platforms:
...
- OpenBSD
Everything is still fresh, so I would NOT recommend to use this on production relays. Testing and review is appreciated.
There is still a crucial piece missing (init scripts), but I hope tor packagers are willing to incorporate multi-init support patches (see issues).
In the interest of going with the OS flow and intent/defaults, I recommend the following for OpenBSD.
Configure relays with a unique ${tag} appended to "tor".
Say you have 2 IPs, want to run 4 total relays, and you want ${tag} to be 1 2 3 or 4. Call each by the name tor${tag}, and use that name to set up resources.
Content changes in the /etc/rc.d/tor... startup/shutdown scripts are unneeded. Straight copies to /etc/rc.d/tor${tag} are best for avoiding having to maintain them separately across upgrades.
Give each relay its own torrc via /etc/tor/tor${tag}, and each its own /var/tor${tag} directory referenced in that torrc.
Then in /etc/rc.conf.local, hook them together and tell OpenBSD how to launch each of them: tor1_flags = {tor1_flags} -f /etc/tor/tor1 tor2_flags = {tor2_flags} -f /etc/tor/tor2 tor3_flags = {tor3_flags} -f /etc/tor/tor3 tor4_flags = {tor4_flags} -f /etc/tor/tor4 pkg_scripts = "... tor1 tor2 tor3 tor4"
At the end of /etc/login.conf, tell OpenBSD to give them a few more resources than the default for daemon class: -------8<------- # Override resource limits for certain LOCAL daemons started by rc.d(8) # # For Tor, set an openfiles-max to override default openfiles-max 1024 # (we leave _tor user in 'daemon' class and rely on /etc/rc.d/tor* names # to pick up possibly unique settings for each instance) tor1:\ :openfiles-cur=1024:\ :openfiles-max=8192:\ :tc=daemon: tor2:\ :openfiles-cur=1024:\ :openfiles-max=4096:\ :tc=daemon: tor3:\ :openfiles-cur=1024:\ :openfiles-max=8192:\ :tc=daemon: tor4:\ :openfiles-cur=1024:\ :openfiles-max=8192:\ :tc=daemon: -------8<-------
Richard
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Hi,
Content changes in the /etc/rc.d/tor... startup/shutdown scripts are unneeded. Straight copies to /etc/rc.d/tor${tag} are best for avoiding having to maintain them separately across upgrades.
I saw your previous email with this description for multiple tor instances on OpenBSD, but it is my intention to get multi-instance support into the upstream package - also for OpenBSD.
For the following reasons:
- - we prefer having a single line in /etc/login.conf for all tor instances, no matter how many you run (compared to N lines if you run N tor instances) This is the reason we assign a custom login class to the _tor user (as you probably saw) - - no need to copy files in /etc/rc.d/
- - we can simply rely on ansible's service module without "manually" tweaking rc.conf.local with a file module (manually tweaking it is assumed to be more error prone)
- - fewer lines are easier to maintain (and faster generated)
In the meantime (and as an alternative approach) I will simply go with rc.local.
Thanks for your feedback.
btw: github restored my account - repo is available again
tor-relays@lists.torproject.org
-
Nusenu -
Richard Johnson