Bug 1071981 - network/tor: add multi-instance systemd service file
network/tor: add multi-instance systemd service file
Status: CONFIRMED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Network
Current
All openSUSE 42.3
: P5 - None : Enhancement (vote)
: Current
Assigned To: Bernhard Wiedemann
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2017-12-08 14:58 UTC by nusenu nusenu
Modified: 2019-01-14 10:13 UTC (History)
1 user (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description nusenu nusenu 2017-12-08 14:58:43 UTC
Tor does not scale well on multi-core machines, this is why fast relays run multiple tor instances on a single server.

Most packages for other Linux Distributions (Debian, Ubuntu, Fedora, CentOS, ...) ship a multi-instance systemd service file to support multiple tor instances.

openSUSE currently does not ship such a systemd service file but it would not require much.

You can have a look at Fedora's multi-instance service file here:
http://pkgs.fedoraproject.org/cgit/rpms/tor.git/tree/tor@.service


The important part is that a package update restarts all tor instances.

General information on systemd multi-instance support:
http://0pointer.de/blog/projects/instances.html

I'm happy to test any multi-instance service files.
Comment 1 Andreas Stieger 2017-12-11 19:28:08 UTC
Is this suitable for a general purpose package? Users would be virtually guaranteed to not configure family correctly. Relay operators can deploy a non-vendor multi-instance service file.
Comment 2 nusenu nusenu 2017-12-11 19:41:12 UTC
(In reply to Andreas Stieger from comment #1)
> Is this suitable for a general purpose package? 

Debian/Ubuntu, Fedora, RHEL/CentOS, FreeBSD deemed it suitable.

> Users would be virtually
> guaranteed to not configure family correctly. 

That is why I maintain
https://github.com/nusenu/ansible-relayor
(I'd like to add openSUSE support for it)

> Relay operators can deploy a
> non-vendor multi-instance service file.

I used to do that for other OSes before but over time 
it is best if it is shipped by the maintainer directly.


btw: I noticed that the current tor package  still uses torctl and hardcodes certain configuration parameters, would you be open to switch to a native systemd service file? (separate bugzilla entry)
Comment 3 Andreas Stieger 2017-12-11 20:04:48 UTC
Not everything that can be done should be done. The existence of this third party configuration tool supports my point, and I have to consider a certain user type here. At the very release this needs to come with a big fat README.

(In reply to nusenu nusenu from comment #2)
> btw: I noticed that the current tor package  still uses torctl and hardcodes
> certain configuration parameters, would you be open to switch to a native
> systemd service file? (separate bugzilla entry)

Sure.
Comment 4 nusenu nusenu 2017-12-11 23:37:54 UTC
(In reply to Andreas Stieger from comment #3)
> Not everything that can be done should be done. The existence of this third
> party configuration tool supports my point, and I have to consider a certain
> user type here. At the very release this needs to come with a big fat README.

Thanks for considering. I can test the multi-instance service file, but maybe lets do the bugzilla entry bellow first.


> (In reply to nusenu nusenu from comment #2)
> > btw: I noticed that the current tor package  still uses torctl and hardcodes
> > certain configuration parameters, would you be open to switch to a native
> > systemd service file? (separate bugzilla entry)
> 
> Sure.

Thanks, I submitted it as:
https://bugzilla.opensuse.org/show_bug.cgi?id=1072274
Comment 5 nusenu nusenu 2018-03-06 15:03:57 UTC
Hello Andreas,

do you have plans to add a multi-instance systemd service file
within 2018?

thanks,
nusenu
Comment 6 Andreas Stieger 2018-03-06 16:26:10 UTC
I have no particular schedule for this bug, as it covers a non-default requirement and has a local work-around. Probably with the next tor branch.