Opened 5 years ago

Closed 4 years ago

#14995 closed enhancement (implemented)

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

Reported by: cypherpunks Owned by: weasel
Priority: Medium Milestone:
Component: Applications/Tor bundles/installation Version:
Severity: Normal Keywords:
Cc: qbi, tyseom, lunar Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

Attachments (2)

tor.init.patch (3.4 KB) - added by cypherpunks 5 years ago.
patch adding multi-instance support to init script with opt-in config paramet MULTI_INSTANCE
tor.init.new (6.7 KB) - added by cypherpunks 5 years ago.
the entire startup script (not just the patch)

Download all attachments as: .zip

Change History (32)

comment:1 Changed 5 years ago by federico3

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]

comment:2 Changed 5 years ago by federico3

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

comment:3 Changed 5 years ago by cypherpunks

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

Last edited 5 years ago by cypherpunks (previous) (diff)

Changed 5 years ago by cypherpunks

Attachment: tor.init.patch added

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

Changed 5 years ago by cypherpunks

Attachment: tor.init.new added

the entire startup script (not just the patch)

comment:4 Changed 5 years ago by cypherpunks

Status: newneeds_review

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

comment:5 Changed 5 years ago by cypherpunks

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.

comment:6 Changed 5 years ago by cypherpunks

Owner: changed from erinn to weasel
Status: needs_reviewassigned

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

comment:7 Changed 5 years ago by cypherpunks

Status: assignedneeds_review

comment:9 Changed 5 years ago by federico3

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)

comment:10 Changed 5 years ago by cypherpunks

thanks, merged.

comment:11 Changed 5 years ago by cypherpunks

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

comment:12 Changed 5 years ago by qbi

Cc: qbi added

comment:13 Changed 5 years ago by mo

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

comment:14 Changed 5 years ago by weasel

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.

comment:15 Changed 5 years ago by cypherpunks

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)

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?

comment:16 in reply to:  13 Changed 5 years ago by cypherpunks

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.

comment:17 Changed 5 years ago by tyseom

Cc: tyseom added

comment:18 in reply to:  15 Changed 5 years ago by cypherpunks

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

Last edited 5 years ago by cypherpunks (previous) (diff)

comment:19 Changed 5 years ago by cypherpunks

Status: needs_reviewnew

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

comment:20 Changed 5 years ago by cypherpunks

Status: newneeds_revision

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.

comment:21 Changed 5 years ago by cypherpunks

Status: needs_revisionneeds_review

comment:22 Changed 5 years ago by cypherpunks

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

comment:23 Changed 5 years ago by cypherpunks

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..

comment:25 Changed 5 years ago by nickm

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?)

comment:26 Changed 5 years ago by cypherpunks

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 <torpid>"
on the command line works fine.

comment:27 Changed 5 years ago by cypherpunks

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

comment:28 Changed 5 years ago by cypherpunks

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

comment:29 Changed 5 years ago by lunar

Cc: lunar added

comment:30 Changed 4 years ago by cypherpunks

Resolution: implemented
Severity: Normal
Status: needs_reviewclosed

implemented in tor 0.2.7.4-rc-1

Note: See TracTickets for help on using tickets.