On 08.08.2017 05:36, teor wrote:
> Distributing changes conveniently is different to deciding whether to
> apply them. Machines are good at the first task, but the second task
> needs multiple people.
Our discussion made me reevaluate my own process of distributing config
data. In particular, I've made some tests with the free version of
Ansible (https://www.ansible.com/), and set the following up on my
1. Shared Tor config data is stored locally. The data store is manually
synced with a central repository (e.g. Subversion) for version control
and backups, but changes could of course also be applied using Git or
other mechanisms. It would be easy to verify if somebody else made a
change, if multiple people were involved, as per your use-case.
2. I wrote a small Ansible playbook that, after being manually invoked,
automatically pushes config data to all my remote Tor nodes that require
changes, and sends a HUP signal if changes were made.
This method requires Ansible to be installed only on the managing
notebook/PC/whatever. There is no additional setup on my Tor nodes
(key-based SSH is required anyway).
Pushing changes to the Tor nodes requires entering both local SSH key
password (ssh-agent can be used, of course) and remote SUDO password,
the latter assuming that the remote SSH user is different from the
remote Tor user. Changes only happen when manually triggered, but it is
still very convenient. Tor processes restarting/reloading don't cause
tor-relays mailing list