Tools for managing multiple relays
Hi, I am currently running three small relays on two different services/ISPs. I have two somewhat unrelated questions: * given costant resource (i.e. euro/month) I can afford to run relays is it in general better to run one bigger relay or, say, two smaller ones. * are there any tools to manage multiple tor node? For example, if I want to check if there are security updates I have to login separately in each system and launch them manually. Is this the way I should do this or there are ways to monitor the status of all my nodes and maintaing them as a whole. Thanks in advance. Cristian
On 15 Oct 2015, at 07:55, Cristian Consonni <kikkocristian@gmail.com> wrote:
Hi,
I am currently running three small relays on two different services/ISPs.
I have two somewhat unrelated questions: * given costant resource (i.e. euro/month) I can afford to run relays is it in general better to run one bigger relay or, say, two smaller ones.
One bigger relay - more bandwidth, less latency, and less work for you, unless… you are providing diversity of locations (geographic or AS), operating systems, or configurations with your multiple relays.
* are there any tools to manage multiple tor node? For example, if I want to check if there are security updates I have to login separately in each system and launch them manually. Is this the way I should do this or there are ways to monitor the status of all my nodes and maintaing them as a whole.
Debian has an unattended-upgrades package that will even restart the machine when needed, if configured to do so. (I think there’s another package for the restarts.) It will also send emails every time it upgrades a package. You might want to consider also doing Tor version upgrades this way, but I’ve found that it's best to do them manually but regularly, then check they worked. Others might have better experiences with automated Tor upgrades. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
2015-10-14 23:00 GMT+02:00 Tim Wilson-Brown - teor <teor2345@gmail.com>:
On 15 Oct 2015, at 07:55, Cristian Consonni <kikkocristian@gmail.com> wrote: I am currently running three small relays on two different services/ISPs.
I have two somewhat unrelated questions: * given costant resource (i.e. euro/month) I can afford to run relays is it in general better to run one bigger relay or, say, two smaller ones.
One bigger relay - more bandwidth, less latency, and less work for you, unless… you are providing diversity of locations (geographic or AS), operating systems, or configurations with your multiple relays.
I am providing geographic diversity, yes.
* are there any tools to manage multiple tor node? For example, if I want to check if there are security updates I have to login separately in each system and launch them manually. Is this the way I should do this or there are ways to monitor the status of all my nodes and maintaing them as a whole.
Debian has an unattended-upgrades package that will even restart the machine when needed, if configured to do so. (I think there’s another package for the restarts.) It will also send emails every time it upgrades a package.
You might want to consider also doing Tor version upgrades this way, but I’ve found that it's best to do them manually but regularly, then check they worked. Others might have better experiences with automated Tor upgrades.
thanks for the advice. Cristian
You could use something like Puppet or Chef to manage multiple nodes. However, the compute resources and time involved with setting up either solution are high enough that it probably wouldn't make sense to do this for only 3 nodes.
Green Dream disturbed my sleep to write:
You could use something like Puppet or Chef to manage multiple nodes. However, the compute resources and time involved with setting up either solution are high enough that it probably wouldn't make sense to do this for only 3 nodes.
An alternative to Puppet or Chef (and I'm a fan of both) would be Ansible; it's much simpler to pick up, and uses SSH to connect to machines to manage them -- no master server needed. I'd say that with three nodes, something like this is pretty close to being worth your time. Have a look through the walkthrough: http://docs.ansible.com/ansible/intro_getting_started.html Thanks, Hugh -- Saint Aardvark the Carpeted http://saintaardvarkthecarpeted.com Because the plural of Anecdote is Myth.
An alternative to Puppet or Chef (and I'm a fan of both) would be Ansible; it's much simpler to pick up, and uses SSH to connect to machines to manage them -- no master server needed.
You just changed my life. I just hadn't looked into Ansible yet. It took about 5 minutes to setup, and seems ideal for managing a handful of nodes. Thank you!
On 10/15/2015 01:22 AM, Green Dream wrote:
An alternative to Puppet or Chef (and I'm a fan of both) would be Ansible; it's much simpler to pick up, and uses SSH to connect to machines to manage them -- no master server needed. You just changed my life. I just hadn't looked into Ansible yet. It took about 5 minutes to setup, and seems ideal for managing a handful of nodes. Thank you!
See https://github.com/nusenu/ansible-relayor ! -- Moritz Bartl https://www.torservers.net/
2015-10-14 23:46 GMT+02:00 Saint Aardvark the Carpeted <aardvark@saintaardvarkthecarpeted.com>:
An alternative to Puppet or Chef (and I'm a fan of both) would be Ansible; it's much simpler to pick up, and uses SSH to connect to machines to manage them -- no master server needed. I'd say that with three nodes, something like this is pretty close to being worth your time. Have a look through the walkthrough:
2015-10-15 11:56 GMT+02:00 Moritz Bartl <moritz@torservers.net>:
I have played a little with Ansible over a week-end some months ago, I will check it out again. Thanks for the pointers. Cristian
participants (5)
-
Cristian Consonni -
Green Dream -
Moritz Bartl -
Saint Aardvark the Carpeted -
Tim Wilson-Brown - teor