debian packages: systemd unit files (with multi-instance support)

Basically every relay operator who wants to make use of available system ressources (CPU, RAM, bandwidth) has to run multiple tor instances on a single host, but the current init script does not include such a feature and everyone who needs it has to hack something togheter on their own.

This ticket is about modifying/extending /etc/init.d/tor (shipped with your debian packages) to allow for easy multi-tor instance handling.

The idea is to introduce an new boolean "MULTI_INSTANCE" in /etc/default/tor

If MULTI_INSTANCE is set to "yes" the init script would start a tor instance per every available *.torrc file in /etc/tor, in all other cases proceed as usual (current behaviour). This allows for an easy and transparent transitioning.

If this is acceptable to you I would go ahead and implement it based on this script that is currently used by torservers: https://gist.github.com/7adietri/9122199 https://www.torservers.net/wiki/setup/server#multiple_tor_processes

but doesn't include the opt-in (MULTI_INSTANCE boolean) yet.

added component::applications/tor bundles/installation owner::weasel priority::medium resolution::implemented severity::normal status::closed type::enhancement labels

There is another reason to support multiple instances: it is not recommended to enable relaying and configure onion services on the same instance. [For security reasons and also because once the relay reaches its bandwidth limit it stops the onion services as well, IIRC]

The script on GitHub scans for /etc/tor/*.cfg In order for the user to be able to enable/disable instances, /etc/tor/enabled and /etc/tor/available could be used, or, in alternative, /etc/tor/torrc.d

Thanks for the input I'll take that into account (I'll try to put something together today).

Trac:
tor.init.patch

patch adding multi-instance support to init script with opt-in config paramet MULTI_INSTANCE

Trac:
tor.init.new

the entire startup script (not just the patch)

added the patch based on [1]

If MULTI_INSTANCE is set to 'yes', we scan for files in /etc/tor/enabled/*.torrc.

It has been lightly tested on debian 7.

Looking forward to your feedback.

[1] https://gist.github.com/7adietri/9122199

Trac:
Status: new to needs_review

If you run in MULTI_INSTANCE mode you will also want to set

DEFAULT_ARGS=""

in your /etc/default/tor

otherwise multiple tor instances write to the same CookieAuthFile and ControlSocket.

Or maybe we should take care of that by default by overriding DEFAULT_ARGS if MULTI_INSTANCE is 'yes'?

I think that makes sense.

According to the debian package info, weasel is the maintainer for debian packages - reassigning it accordingly.

Trac:
Status: needs_review to assigned
Owner: erinn to weasel

Trac:
Status: assigned to needs_review

latest version: https://github.com/nusenu/tor-multi-instance-initscripts/blob/master/debian/tor

I've added a small patch to make the indentation consistent with the previous code: https://github.com/FedericoCeratto/tor-multi-instance-initscripts/tree/master/debian

(We could use this repo for tracking the evolution of the script, I'll be happy to accept PR)

thanks, merged.

added an additional check to output a more obvious error message if /etc/tor/enabled is not existing or empty.

https://github.com/nusenu/tor-multi-instance-initscripts/commit/f8c4b8bc53d803c09060e4f15b8118aad01e61e5

Trac:
Cc: N/A to qbi

Hm. I don't like how you need to specifically enable this. Can't we make it so it picks up torrc*?

My current plan is to first make a systemd unit file, and then add some support for multiple instances based on that, similar to how one can run multiple postgresql clusters, ideally with a per-instance user (in addition to datadir, config dir, etc.).

Either way, the Tor trac is not the place to discuss Debian packaging enhancements.

Just to be clear which debian packages I'm talking about here. This has been filed in trac because it is about the torproject's debian packages located here: https://deb.torproject.org/torproject.org/dists/ (maybe the title of this trac entry was a bit misleading, I just wanted to split that ticket from hiviah's RPM ticket #14996 (moved))

Where should I file tickets if tor trac is not the correct place for that? (unless otherwise stated I will continue the discussion here)

Anyway, I find it great to hear that you have plans for systemd unit files - that was also something I was thinking about because debian goes systemd anyway. Do you have some prototype unit files already, that we could look at and test?

Replying to mo:

Hm. I don't like how you need to specifically enable this. Can't we make it so it picks up torrc*?

Could you elaborate on why you do not like it? Modifying a single line in a config file to opt-in doesn't seem to be a big effort, no? (and my ansible role will take care of that as well ;)

The motivation was to preserve old behaviour and provide an smooth upgrade path that doesn't break for users not expecting this.

If you start parsing any torrc files without explicitly requiring opt-in, this will likely break things somewhere I guess.

Trac:
Username: tyseom
Cc: qbi to qbi, tyseom

Replying to cypherpunks:

Do you have some prototype unit files already, that we could look at and test?

To answer this question myself: https://gitweb.torproject.org/debian/tor.git/tree/contrib/dist/tor.service.in

Since we have a clear info from weasel, that we should aim for systemd unit files I changed the status accordingly.

Trac:
Status: needs_review to new

single instance unit file https://github.com/nusenu/tor-multi-instance-initscripts/commit/5f66eb7ea843d8c5298ef8d7828ced09df89139e

multi instance unit file https://github.com/nusenu/tor-multi-instance-initscripts/commit/fe3198c404eb4ea9b077999a0dd17cb9829bfe1a

known problems:

• reload does not work - haven't found the root cause yet
• doesn't work with systemd shipped with wheezy-backports (problem related to the use of NoNewPrivileges = yes

Looking forward to reading your comments.

Trac:
Status: new to needs_revision

Trac:
Status: needs_revision to needs_review

Trac:
Summary: debian packages: add support for multiple tor instances to init.d start script to debian packages: systemd unit files (with multi-instance support)

I found the reason why 'systemctl reload ..' does not work, it is one of the hardening restrictions.

If you comment out this line, reload will work:

CapabilityBoundingSet = CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE

lets see what we have to add to the list to get it working with that line..

The reload problem has been fixed by adding "CAP_KILL" to the list.

https://github.com/nusenu/tor-multi-instance-initscripts/blob/master/debian/tor%40.service https://github.com/nusenu/tor-multi-instance-initscripts/blob/master/debian/tor.service

Hm. Should we look at the CAP_KILL change for 0.2.6? (And why does Tor need CAP_KILL? For tor_terminate_process? For pluggable transports?)

I don't think tor needs CAP_KILL at all. It is the ExecReload command that needs it. Line 9: https://github.com/nusenu/tor-multi-instance-initscripts/blob/master/debian/tor.service#L9

At least that is my interpretation because running tor without CAP_KILL and executing

"kill -HUP " on the command line works fine.

FTR: The 'CAP_KILL' capa. requirement is likely just a systemd bug http://lists.freedesktop.org/archives/systemd-devel/2015-March/029609.html

new location for the latest multi-instance service files:

for Debian Jessie: https://github.com/nusenu/ansible-relayor/blob/master/files/debian_tor%40.service

for Ubuntu 15.04 (including AppArmor support): https://github.com/nusenu/ansible-relayor/blob/master/files/ubuntu_tor%40.service

Trac:
Cc: qbi, tyseom to qbi, tyseom, lunar

implemented in tor 0.2.7.4-rc-1

Trac:
Resolution: N/A to implemented
Sponsor: N/A to N/A
Severity: N/A to Normal
Status: needs_review to closed

closed

mentioned in issue #14996 (moved)

mentioned in issue tpo/core/rpm-package#14996 (closed)