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 notebook:
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 adverse effects.
-Ralph