nusenu / ansible-relayor Goto Github PK

When installing tor via pkg, openssl from base is used, which comes without enable-ec_nistp_64_gcc_128 support.

[notice] We were built to run on a 64-bit CPU, with OpenSSL 1.0.1 or later, but with a version of OpenSSL that apparently lacks accelerated support for the NIST P-224 and P-256 groups. Building openssl with such support (using the enable-ec_nistp_64_gcc_128 option when configuring it) would make ECDH much faster.

To compile with openssl from ports:
make WITH_OPENSSL_PORT=yes install

https://trac.torproject.org/projects/tor/ticket/14996

works fine without systemd hardening options enabled

Currently we allow CAP_DAC_OVERRIDE CAP_CHOWN even if we do not actually need it.
https://github.com/nusenu/ansible-relayor/blob/master/files/debian_tor%40.service#L34
These capabilities are only needed if tor_enableControlSocket is True.

Generate the CapabilityBoundingSet in tor's service file dynamically based on the actual torrc ControlSocket setting.

https://github.com/nusenu/ansible-relayor/blob/master/tasks/openbsd_install.yml#L15

To avoid looking into deprecated/unmaintained stuff (ref: david415/ansible-tor#8)

Also, what are your thoughts on ansigenome, rolespec and Travis CI.

I will look into your modifications and compare them with what I did with the david415.tor role lately.

PS: Why did you not just fork https://github.com/david415/ansible-tor and instead did git init && git add .?

ansible executes:
systemctl is-enabled tor
output (retval=1):
Failed to get unit file state for tor.service: No such file or directory

so ansible believes tor is disabled already

systemd 215-14's man page about CapabilityBoundingSet:
This option may appear more than once in which case the bounding sets are merged.

So
CapabilityBoundingSet = cap1 cap2

should be semantically identical to

CapabilityBoundingSet = cap1
CapabilityBoundingSet = cap2 

but that is not the case.

This should speedup things for large families.

Adding a new server would include two steps:

1. run installation tags on new server
2. run configuration tags on all servers (for MyFamily)

Lets also consider OS family specific tags (Linux, FreeBSD, OpenBSD), so an operator running only one OS type can significantly speed things up.

http://docs.ansible.com/playbooks_tags.html

ansible/ansible-modules-core#1797
ansible/ansible-modules-core#1796

Currently we fail hard if ports are not available on the system.
Provide a var that allows the user to opt-in for automatic ports bootstrapping.

wget http://ftp.openbsd.org/pub/OpenBSD/5.7/xenocara.tar.gz http://ftp.openbsd.org/pub/OpenBSD/5.7/ports.tar.gz  http://ftp.openbsd.org/pub/OpenBSD/5.7/SHA256.sig

signify -C -p /etc/signify/openbsd-57-base.pub -x SHA256.sig xenocara.tar.gz ports.tar.gz
tar ...
cvs ...

Currently we generate a temporary torrc file [1] without myfamily to generate the keys, but that step is not necessary if keys are already present.
Lets detect that case and skip temporary torrc files step then.

[1] https://github.com/nusenu/ansible-relayor/blob/master/tasks/configure.yml#L44

As per subject, if an operator already has other nodes and want to launch a new node (or group of nodes) it should be possible to specify the other nodes fingerprint to be added to the MyFamily configuration in addition to the automatic discovery of the hosts in the group.

https://trac.torproject.org/projects/tor/wiki/doc/IPv6RelayHowto

We will want ControlPort support to integrate with:
https://github.com/mweinelt/munin-tor

http://lists.freedesktop.org/archives/systemd-devel/2015-April/030404.html

Tasks having this when check do not run, they are skipped but they shouldn't.

Affected tasks:

- name: Ensure system-wide runtime file descriptor limits are reasonable (OpenBSD)
- name: Ensure system-wide persistent file descriptor limits are reasonable (OpenBSD)

If '--list-finterprint' gives us no fingerprint we end up writing a MyFamily config entry without any fingerprints. Detect and abort.

This is not a bug in this ansible role but it affects us.

Impact of this problem:

/etc/rc.d/tor start
might never start the intended daemon if another tor instance is already running (rc_check believes tor is already running).

/etc/rc.d/tor stop
might kill all (including unrelated) tor instances instead of one.

/etc/rc.d/tor restart
might kill all tor instances and starts only one.

One line (actually one character) "patch" submitted to the OpenBSD tor maintainer:

8a9,10
> pexp="${daemon}${daemon_flags:+ ${daemon_flags}}$"
> 

references:
http://article.gmane.org/gmane.os.openbsd.misc/222896

Due the incomplete integration of our system services (tor instances), log files in /var/log/tor get rotated but tor instances do not get the SIGHUP to reopen the new file.

https://trac.torproject.org/projects/tor/ticket/14995

Add an additional check to see whether fingerprint is more than one line.
(The current check passes if the first line matches the regex)

Having examples in the README is useful, but I think that it would be better to have complete playbooks with comments with clear instructions on how to use them directly in the repo. I will provide a new pull request if this idea is accepted.

also relevant:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761404

http://docs.ansible.com/user_module.html

waiting for
https://bugs.torproject.org/14997

https://github.com/nusenu/ansible-relayor/blob/master/files/centos_tor%40.service#L34

after running

ansible-playbook tor.yml -l server --tags openbsd

there is only one tor instance started with the appropriate '-f ' parameter, the second tor instance runs the default torrc /etc/tor/torrc

Manually starting it (tor -f ..) works fine.
/etc/rc.conf.local looks fine.

/etc/rc.d/tor_IP_port start
does NOT start tor as expected (only in one case)

ansible version: 1.9.1

We do not want to run two instances per IP if we do not have enough RAM for that..
Currently the operator has to adjust tor_maxips in such cases manually.

I'm missing a way in ansible to limit the iterations of a with_nested loop to a given
value.

waiting for
https://bugs.torproject.org/15015

https://lists.fedoraproject.org/pipermail/selinux/2015-April/016644.html

changing the user's (_tor) login class +
/etc/login.conf:
tordaemon::openfiles-max=13500::tc=daemon:

does not work as expected

On DigitalOcean and other ISP the machines come with only the root user present. By default (on Debian 8.0 and 8.1) sudo is not installed.

If the machine is dedicated to be a Tor node I see no reason to install sudo and add another user for the installation of Tor.

It should be possible then to check if the user is already root and, if so, do not add sudo to all commands. Furthermore the sudo directive in anslble playbooks is deprecated.

If setting up the node with root is not advisable then it should be mentioned (e.g. in the README).

https://github.com/nusenu/ansible-relayor/blob/master/files/debian_tor%40.service#L30

https://lists.torproject.org/pipermail/tor-dev/2015-April/008638.html

listen queue overflow example:
https://lists.freebsd.org/pipermail/freebsd-stable/2013-August/074561.html

Lets set it to 2048.

https://www.freebsd.org/doc/handbook/configtuning-kernel-limits.html

ansible/ansible-modules-core#1627

We will start requiring systemd and ship our own systemd unit files that support multiple instances (if they are not in any upstream packages). We will not interfere with the init.d script or systemd unit file from the packager.

With this step we will also replace direct invocations of 'tor' via the shell module
https://github.com/nusenu/ansible-relayor/blob/master/tasks/configure.yml#L109
with the systemctl/service module.

Tested unit file on debian jessie:
https://github.com/nusenu/tor-multi-instance-initscripts/blob/master/debian/tor%40.service

We will no longer support debian wheezy once we migrate to systemd, but we hope that jessie isn't to far from being released.

We don't want to proceed if a host has not been reachable during 'gathering facts' phase, because that would prevent the collection of relay fingerprints and incomplete MyFamily settings.

http://docs.ansible.com/playbooks_delegation.html

max_fail_percentage: 1
serial: 1

Hiroki Sato wrote a patch [1] for /etc/rc.subr to support multiple instances of a single rc script.
It will probably included in FreeBSD 10.2 - scheduled for Nov 2015.

[1] http://lists.freebsd.org/pipermail/freebsd-rc/2014-October/003570.html

We currently use pkg to install tor, but
OpenBSD 5.7 provides an outdated tor package (v0.2.5.10) via:
http://ftp.openbsd.org/pub/OpenBSD/5.7/packages/amd64/

Ports in -stable ships the last 0.2.5.x (currently 0.2.5.12).
So the better option would be to install the port.
There is currently no ansible module for OpenBSD ports as far as I've seen, so this will be an 'command/shell' module task.

I'm also inclined to install tor 0.2.6.x which is not directly available in the -stable ports put the patch to MAIN is minimal (changes only the tor version number and fingerprint).

Another alternative would be to take the tor 0.2.6.x package from snapshot
http://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/amd64/
(probably not the best / cleanest idea since mixing -stable with snapshot packages is strongly discouraged)

So for now I'm inclined to go with 0.2.5.12 from -stable ports, in future we want to switch to 0.2.6.x.