Ability to configure many instances of TOR (multiple ports) at the start command
ggondim opened this issue · comments
Hi @GouveaHeitor,
I'm working in a patch somewhat related to this issue.
Will try to add this behavior.
Checking how tor works with multiple instances of itself I found that the command systemd runs (and that Nipe uses) for executing tor is:
/usr/bin/tor --runasdaemon 0 --defaults-torrc /usr/share/tor/defaults-torrc -f /etc/tor/%i.torrc
(got from /usr/lib/systemd/system/tor@.service)
forcing the user (or Nipe, in this case) to call systemctl start tor@<custom_config>.service. With that, the user can't just install a config file anywhere he was willing, he's forced to place the new instance config file within /etc/tor dir, otherwise Nipe would be forced to run tor from its normal command line, like tor -f <custom_config>, which is acceptable but requires more care around user's capabilities to exec some privileged commands.
The solution for Nipe that I would suggest is: make Nipe's install -c command ('develop' branch only) to only ask for a the name of the custom config file and then place it into /etc/tor/ + .torrc suffix, for example:
$ ./nipe.pl install -c nipe_cfg
(...)
$ ls /etc/tor
... nipe_cfg.torrc
In this way Nipe would be following the standards of Tor project.
What do you think @GouveaHeitor ?
Ok, forget it. The systemd tor@.service file is present only in Fedora's tor package, I didn't find it not even in OpenSuse (which is a systemd and rpm based distro) nor in any other debian derived distros (which aren't systemd based, yet).
Ok, this issue is partially solved by the PR #87. What I mean by "partially" is that with that code Nipe accepts different custom config files created by the user, no matter the source of creation of that. However nipe still can't run different instances of tor at the same time. The reason for that is the way nipe configures the firewall to route/forward tcp and udp packets. If a new instance of nipe gets executed the new iptable rules would conflict with the old one.
@GouveaHeitor do you have plans to work on such support of "multiple" iptables configuration? I'm not even sure if that would be feasible or worth (I would vote for "no").
Many thanks.
I believe that the best solution for this issue was the one you proposed in PR # 87!
The other "solution" alternatives could create more problems instead of actually helping something.
I will close this issue when the content of develop is merged to master