Hi,
i have installed a new relay on Debian 8 and playing around with the arm tool.
1. Issue: Seeing Connections
I have added 'DisableDebuggerAttachment 0' to the config file as suggested and now i get this:
17:20:09 [ARM_NOTICE] We were unable to use any of your system's resolvers to get tor's connections. This is fine, but means that the connect- ions page will be empty. This is usually permissions related so if you would like to fix this then run arm with the same user as tor (ie, "sudo -u <tor user> arm"). 17:19:54 [ARM_NOTICE] Unable to query connections with lsof, trying ss 17:19:39 [ARM_NOTICE] Unable to query connections with sockstat, trying lsof 17:19:24 [ARM_NOTICE] Unable to query connections with netstat, trying sockstat 17:19:09 [ARM_NOTICE] Unable to query connections with proc, trying netstat
Tor runs on Debian as user 'debian-tor' with no shell, so i cant just do 'sudo -u <tor user> arm' even if sudo was installed on the server. But i added my user to the debian-tor group. On a side note i never could get the CookieAuthentication working either. Seems to be permission issues with the default installation. Does somebody else have this issues on Debian?
2. Issue: It always says this message in the arm logs even if the service is just started a moment ago. If i reload the config it says the same thing shortly after.
17:18:59 [ARM_WARN] The torrc differs from what tor's using. You can issue a sighup to reload the torrc values by pressing x. - torrc values differ on lines: 118, 127
3. Issue: I dont understand this message. Nickname is edited by me so it does not match its default value. Also why is it unneeded?
17:18:59 [ARM_NOTICE] Unneeded torrc entries found. They've been highlighted in blue on the torrc page. - entry matches its default value: Nickname (line 117)
Hi!
On 10.11.2016 19:27, Dennis Christ wrote:
- Issue: Seeing Connections
Im not sure, but I've only copied the default armrc to /var/lib/tor/.arm/ and set the proper permissions.
As I see, there is no /usr/share/doc/arm/armrc.sample. I've fetched it from here: https://www.atagar.com/arm/. If your are using arm with another user, armrc should be in your home directory.
Tor runs on Debian as user 'debian-tor' with no shell, so i cant just do 'sudo -u <tor user> arm' even if sudo was installed on the server. But i added my user to the debian-tor group. On a side note i never could get the CookieAuthentication working either. Seems to be permission issues with the default installation. Does somebody else have this issues on Debian?
You don't need a shell for the debian-tor user. CookieAuthentication should work, if you set CookieAuthentication 1 in /etc/tor/torrc and are using an armrc file.
- Issue: It always says this message in the arm logs even if the
service is just started a moment ago. If i reload the config it says the same thing shortly after.
Yes, that looks like some Debian issue. I've seen the same message with "RunAsDaemon", which is the default value. But that doesn't hurt. I just ignore this message.
- Issue: I dont understand this message. Nickname is edited by me so it
does not match its default value. Also why is it unneeded?
Try to have a look into /etc/default/tor and /usr/share/tor/tor-service-defaults-torrc, there should be some relevant settings.
Hopefully it helps.
Regards,
You don't need a shell for the debian-tor user. CookieAuthentication should work, if you set CookieAuthentication 1 in /etc/tor/torrc and are using an armrc file.
I think the problem with CookieAuthentication was that the cookie file control_auth_cookie gets written to /var/lib/tor. This directory is only readable by user debian-tor and not even group readable. I have put CookieAuthFileGroupReadable 1 into the config file. But with my standard user which is in the debian-tor group i cannot access this file inside /var/lib/tor because the permissions of this directory are set up by tor on startup to 700.
Try to have a look into /etc/default/tor and /usr/share/tor/tor-service-defaults-torrc, there should be some relevant settings.
Hopefully it helps.
Maybe i should have add that i do not use the debian init.d script to start up tor but a native systemd service file. I think its a shame that debian switched to systemd but still relays on init.d scripts for so many services. So /etc/default/tor does not get used.
Hi!
On 11.11.2016 14:14, Dennis Christ wrote:
I think the problem with CookieAuthentication was that the cookie file control_auth_cookie gets written to /var/lib/tor. This directory is only readable by user debian-tor and not even group readable. I have put CookieAuthFileGroupReadable 1 into the config file. But with my standard user which is in the debian-tor group i cannot access this file inside /var/lib/tor because the permissions of this directory are set up by tor on startup to 700.
Yes, you are right. But CookieAuthentication should work. You cannot query all of the connections without access to /var/lib/tor. You only will see circuits. I suggest to use "sudo -u debian-tor arm", if you like to use all of the arm pages. Otherwise you have to change the permissions. In my case, there is also the setgid flags on the directories (2700 drwx--S---).
Maybe i should have add that i do not use the debian init.d script to start up tor but a native systemd service file.
Me too
I think its a shame that debian switched to systemd but still relays on init.d scripts for so many services. So /etc/default/tor does not get used.
No, /etc/default/tor isn't used with systemd. Nevertheless there a some services which rely on System V init scripts. Sometimes it is a ugly mixture of both.
Regards,
On Fri, 11 Nov 2016, at 07:16 PM, diffusae wrote:
Yes, you are right. But CookieAuthentication should work. You cannot query all of the connections without access to /var/lib/tor. You only will see circuits. I suggest to use "sudo -u debian-tor arm", if you like to use all of the arm pages. Otherwise you have to change the permissions. In my case, there is also the setgid flags on the directories (2700 drwx--S---).
Sorry not fully read the correspondence here but perhaps a tidier option might be the one recommended on the tor website[1] of doing
sudo adduser $USER debian-tor
The alternative of running as the debian-tor user is a 'bad idea', see [2] from last July
[1] https://www.torproject.org/docs/tor-relay-debian.html.en#after [2] https://lists.torproject.org/pipermail/tor-relays/2016-July/009608.html
Yes that is what i tried to do. But it does not work in my case.
$ arm [Errno 13] Permission denied: '/var/lib/tor/control_auth_cookie'
Even if my user is in the group debian-tor the user has no right to access /var/lib/tor.
$ ls -l /var/lib | grep tor drwx--S--- 4 debian-tor debian-tor 4096 Nov 12 12:38 tor
Am 12.11.2016 um 10:33 schrieb Louie Cardone-Noott:
On Fri, 11 Nov 2016, at 07:16 PM, diffusae wrote:
Yes, you are right. But CookieAuthentication should work. You cannot query all of the connections without access to /var/lib/tor. You only will see circuits. I suggest to use "sudo -u debian-tor arm", if you like to use all of the arm pages. Otherwise you have to change the permissions. In my case, there is also the setgid flags on the directories (2700 drwx--S---).
Sorry not fully read the correspondence here but perhaps a tidier option might be the one recommended on the tor website[1] of doing
sudo adduser $USER debian-tor
The alternative of running as the debian-tor user is a 'bad idea', see [2] from last July
[1] https://www.torproject.org/docs/tor-relay-debian.html.en#after [2] https://lists.torproject.org/pipermail/tor-relays/2016-July/009608.html _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Sat, 12 Nov 2016 at 12:41 Dennis Christ lists@ollic.de wrote:
Yes that is what i tried to do. But it does not work in my case.
$ arm [Errno 13] Permission denied: '/var/lib/tor/control_auth_cookie'
Even if my user is in the group debian-tor the user has no right to access /var/lib/tor.
$ ls -l /var/lib | grep tor drwx--S--- 4 debian-tor debian-tor 4096 Nov 12 12:38 tor
Am 12.11.2016 um 10:33 schrieb Louie Cardone-Noott:
On Fri, 11 Nov 2016, at 07:16 PM, diffusae wrote:
Yes, you are right. But CookieAuthentication should work. You cannot query all of the connections without access to /var/lib/tor. You only will see circuits. I suggest to use "sudo -u debian-tor arm", if you like to use all of the arm pages. Otherwise you have to change the permissions. In my case, there is also the setgid flags on the directories (2700 drwx--S---).
Sorry not fully read the correspondence here but perhaps a tidier option might be the one recommended on the tor website[1] of doing
sudo adduser $USER debian-tor
The alternative of running as the debian-tor user is a 'bad idea', see [2] from last July
[1] https://www.torproject.org/docs/tor-relay-debian.html.en#after [2] https://lists.torproject.org/pipermail/tor-relays/2016-July/009608.html
Hi
You could just modify the systemd service file for tor, with something like ExecStartPre=/usr/bin/install -Z -m 02755 -o debian-tor -g debian-tor -d /var/run/tor ExecStartPre=/usr/bin/install -Z -m 02750 -o debian-tor -g debian-tor -d /var/log/tor
Cheers Seb
On 11/12/2016 8:34 AM, r1610091651 wrote:
On Sat, 12 Nov 2016 at 12:41 Dennis Christ <lists@ollic.de mailto:lists@ollic.de> wrote:
Yes that is what i tried to do. But it does not work in my case. $ arm [Errno 13] Permission denied: '/var/lib/tor/control_auth_cookie' Even if my user is in the group debian-tor the user has no right to access /var/lib/tor. $ ls -l /var/lib | grep tor drwx--S--- 4 debian-tor debian-tor 4096 Nov 12 12:38 tor Am 12.11.2016 um 10:33 schrieb Louie Cardone-Noott: > On Fri, 11 Nov 2016, at 07:16 PM, diffusae wrote: >> Yes, you are right. But CookieAuthentication should work. You cannot >> query all of the connections without access to /var/lib/tor. You only >> will see circuits. I suggest to use "sudo -u debian-tor arm", if you >> like to use all of the arm pages. Otherwise you have to change the >> permissions. In my case, there is also the setgid flags on the >> directories (2700 drwx--S---). > Sorry not fully read the correspondence here but perhaps a tidier option > might be the one recommended on the tor website[1] of doing > > sudo adduser $USER debian-tor > > The alternative of running as the debian-tor user is a 'bad idea', see > [2] from last July > > [1] https://www.torproject.org/docs/tor-relay-debian.html.en#after > [2] > https://lists.torproject.org/pipermail/tor-relays/2016-July/009608.htmlHi
You could just modify the systemd service file for tor, with something like ExecStartPre=/usr/bin/install -Z -m 02755 -o debian-tor -g debian-tor -d /var/run/tor ExecStartPre=/usr/bin/install -Z -m 02750 -o debian-tor -g debian-tor -d /var/log/tor
Cheers Seb
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
A little OT, but if Arm is giving you trouble perhaps try using nload or lsof to view activity on your relay. When I started running a tor relay I was very dependent on Arm to, 'see what was going on', but over time I realized that if things were going smoothly there was little need to run a background app such as Arm.
Hi!
On 12.11.2016 12:40, Dennis Christ wrote:
Yes that is what i tried to do. But it does not work in my case.
$ arm [Errno 13] Permission denied: '/var/lib/tor/control_auth_cookie'
That is a bit odd. I don't have '/var/lib/tor/control_auth_cookie' It resides in /var/run/tor/control.authcookie
-rw-r----- 1 debian-tor debian-tor 32 /var/run/tor/control.authcookie
So read access should be possible.
If I remove this file, I also get [Errno 2] No such file or directory: '/var/run/tor/control.authcookie'
Does your user have read access to /var/run/tor?
Which version of arm you are using?
I use arm version 1.4.5.0 (released April 28, 2012)
Am 12.11.2016 um 10:33 schrieb Louie Cardone-Noott:
The alternative of running as the debian-tor user is a 'bad idea', see [2] from last July
I didn't know this also, but is it really a big security issue unless you don't trust the running arm binary? I am only asking, because if you run it as user in the debian-tor group, you don't have full access to the control port, so the connections page will be empty.
[ARM_NOTICE] Unable to query connections with lsof, trying ss [ARM_NOTICE] Unable to query connections with sockstat, trying lsof [ARM_NOTICE] Unable to query connections with netstat, trying sockstat [ARM_NOTICE] Unable to query connections with proc, trying netstat
Maybe I did something wrong?
Regards,
That is a bit odd. I don't have '/var/lib/tor/control_auth_cookie' It resides in /var/run/tor/control.authcookie
-rw-r----- 1 debian-tor debian-tor 32 /var/run/tor/control.authcookie
So read access should be possible.
If I remove this file, I also get [Errno 2] No such file or directory: '/var/run/tor/control.authcookie'
Does your user have read access to /var/run/tor?
Which version of arm you are using?
I use arm version 1.4.5.0 (released April 28, 2012)
Yes i also have this file and my user can access that one. But that is not the file arm tries to access apparently.
-rw-r----- 1 debian-tor debian-tor 32 Nov 3 19:05 /var/run/tor/control.authcookie
Same arm version:
arm version 1.4.5.0 (released April 28, 2012)
On Fri, Nov 11, 2016 at 02:14:01PM +0100, Dennis Christ wrote:
I think the problem with CookieAuthentication was that the cookie file control_auth_cookie gets written to /var/lib/tor. This directory is only readable by user debian-tor and not even group readable. I have put CookieAuthFileGroupReadable 1 into the config file. But with my standard user which is in the debian-tor group i cannot access this file inside /var/lib/tor because the permissions of this directory are set up by tor on startup to 700.
Right, this is not the way you should be doing it.
My /usr/share/tor/tor-service-defaults-torrc file has these lines in it:
CookieAuthentication 1 CookieAuthFileGroupReadable 1 CookieAuthFile /var/run/tor/control.authcookie
So you shouldn't be needing to add any lines to your /etc/tor/torrc file.
Maybe i should have add that i do not use the debian init.d script to start up tor but a native systemd service file. I think its a shame that debian switched to systemd but still relays on init.d scripts for so many services. So /etc/default/tor does not get used.
This sounds bad too. In fact, it sounds like one of those "you broke the package, and now you get to keep both pieces" situations. :)
I believe that the Tor deb, including the one intended for jessie, should work with systemd well: https://gitweb.torproject.org/debian/tor.git/tree/debian/changelog?id=debian... Am I mistaken?
That said, be sure you're using a recent Tor deb: https://www.torproject.org/docs/debian and not the ancient Tor 0.2.5.x in vanilla jessie.
--Roger
This sounds bad too. In fact, it sounds like one of those "you broke the package, and now you get to keep both pieces" situations. :)
I believe that the Tor deb, including the one intended for jessie, should work with systemd well: https://gitweb.torproject.org/debian/tor.git/tree/debian/changelog?id=debian... Am I mistaken?
That said, be sure you're using a recent Tor deb: https://www.torproject.org/docs/debian and not the ancient Tor 0.2.5.x in vanilla jessie.
--Roger
I removed the jessie tor package now and installed the version from the torproject repo which is 0.2.8.9. There was alot of things done regarding systemd in that new version it seems. They added sd-notify and a service file for instantiated services. I am using tor@default.service and everything works now.
So it propably was my own service file which did not all the things needed to set up tor for startup. For example this ExecStartPre command: /usr/bin/install -Z -m 02755 -o debian-tor -g debian-tor -d /var/run/tor and also starting tor with parameter --defaults-torrc /usr/share/tor/tor-service-defaults-torrc.
Thanks everybody
Hi!
On 13.11.2016 03:00, Roger Dingledine wrote:
So you shouldn't be needing to add any lines to your /etc/tor/torrc file.
Right, that what I've meant before.
I believe that the Tor deb, including the one intended for jessie, should work with systemd well: https://gitweb.torproject.org/debian/tor.git/tree/debian/changelog?id=debian... Am I mistaken?
Yes, it works well with systemd. The only "problem" I've recognized is, that systemd starts tor with the --RunAsDaemon 0 option. The default setting in /usr/share/tor/tor-service-defaults-torrc is "RunAsDaemon 1". If you use arm, it will be shown, that you are not using the defaults. Also if you set this to 1 in /etc/tor/torrc, it will be started with 0. This settings will be ignored.
Regards,
On 11 Nov. 2016, at 05:27, Dennis Christ lists@ollic.de wrote:
Hi,
i have installed a new relay on Debian 8 and playing around with the arm tool.
...
- Issue: It always says this message in the arm logs even if the service is just started a moment ago. If i reload the config it says the same thing shortly after.
17:18:59 [ARM_WARN] The torrc differs from what tor's using. You can issue a sighup to reload the torrc values by pressing x.
- torrc values differ on lines: 118, 127
What is on lines 118 and 127? This could be a bug in Tor, where it changes the options it would write out, (if you asked it to write out your torrc file) rather than changing its internal idea of those options.
Please log a ticket under Core Tor / Tor with the names of those options at: https://trac.torproject.org/projects/tor/newticket
- Issue: I dont understand this message. Nickname is edited by me so it does not match its default value. Also why is it unneeded?
17:18:59 [ARM_NOTICE] Unneeded torrc entries found. They've been highlighted in blue on the torrc page.
- entry matches its default value: Nickname (line 117)
What is on line 117? This could be a bug in Tor, or it could be a bug in arm.
The default nickname is NULL, which gets changed to "Unnamed" on relays.
So if your nickname is different to "Unnamed", log a bug against Core Tor / Nyx (the new name for arm). https://trac.torproject.org/projects/tor/newticket
And please also log a ticket under Core Tor / Tor saying that we are modifying Nickname from its default value, and writing it out again, rather than modifying our idea of it internally. https://trac.torproject.org/projects/tor/newticket
T
Line 118 is actually an empty line, but on 117 is this:
Nickname "Iridium"
Line 127 is also empty, but on 126 is this:
RelayBandwidthBurst 1.5 MB
I did not set up tor to write out the torrc file. But if have noticed on the Tor Configuration File page in arm these two config values are in red with another value behind it:
Nickname "Iridium" (Iridium) RelayBandwidthBurst 1.5 MB (1572864)
Should i file a bug report?
Am 11.11.2016 um 05:00 schrieb teor:
On 11 Nov. 2016, at 05:27, Dennis Christ lists@ollic.de wrote:
Hi,
i have installed a new relay on Debian 8 and playing around with the arm tool.
...
- Issue: It always says this message in the arm logs even if the service is just started a moment ago. If i reload the config it says the same thing shortly after.
17:18:59 [ARM_WARN] The torrc differs from what tor's using. You can issue a sighup to reload the torrc values by pressing x.
- torrc values differ on lines: 118, 127
What is on lines 118 and 127? This could be a bug in Tor, where it changes the options it would write out, (if you asked it to write out your torrc file) rather than changing its internal idea of those options.
Please log a ticket under Core Tor / Tor with the names of those options at: https://trac.torproject.org/projects/tor/newticket
- Issue: I dont understand this message. Nickname is edited by me so it does not match its default value. Also why is it unneeded?
17:18:59 [ARM_NOTICE] Unneeded torrc entries found. They've been highlighted in blue on the torrc page.
- entry matches its default value: Nickname (line 117)
What is on line 117? This could be a bug in Tor, or it could be a bug in arm.
The default nickname is NULL, which gets changed to "Unnamed" on relays.
So if your nickname is different to "Unnamed", log a bug against Core Tor / Nyx (the new name for arm). https://trac.torproject.org/projects/tor/newticket
And please also log a ticket under Core Tor / Tor saying that we are modifying Nickname from its default value, and writing it out again, rather than modifying our idea of it internally. https://trac.torproject.org/projects/tor/newticket
T
Am 11.11.2016 um 13:51 schrieb Dennis Christ:
Line 118 is actually an empty line, but on 117 is this:
Nickname "Iridium"
Try using your nickname without quotes, like so:
Nickname Iridium
Line 127 is also empty, but on 126 is this:
RelayBandwidthBurst 1.5 MB
You could try to use kilobytes/s instead of a decimal number in MB
RelayBandwidthBurst 1536 KB
I did not set up tor to write out the torrc file. But if have noticed on the Tor Configuration File page in arm these two config values are in red with another value behind it:
Nickname "Iridium" (Iridium) RelayBandwidthBurst 1.5 MB (1572864)
Should i file a bug report?
Try using the changes I mentioned and if it still has problems, I would definitely file a bug report.
Best, Michael
Hi!
On 11.11.2016 14:10, Michael Armbruster wrote:
Try using your nickname without quotes, like so:
Nickname Iridium
Yes, I can confirm, that Nickname should be set without quotes.
You could try to use kilobytes/s instead of a decimal number in MB
RelayBandwidthBurst 1536 KB
The Bandwidth could be set with KBytes, also MB or GB works, but only without a delimeter.
Should i file a bug report?
Try using the changes I mentioned and if it still has problems, I would definitely file a bug report.
I guess that it is a syntax error instead of a bug in Tor. If you set the correct values it should work.
Regards,
Tried it out and that solved the message about reloading the config file. What still remains is this message:
12:30:13 [ARM_NOTICE] Unneeded torrc entries found. They've been highlighted in blue on the torrc page. - entry matches its default value: Nickname (line 117)
Line 117 is now this:
Nickname Iridium
So this is probably a bug.
Am 11.11.2016 um 14:10 schrieb Michael Armbruster:
Am 11.11.2016 um 13:51 schrieb Dennis Christ:
Line 118 is actually an empty line, but on 117 is this:
Nickname "Iridium"
Try using your nickname without quotes, like so:
Nickname Iridium
Line 127 is also empty, but on 126 is this:
RelayBandwidthBurst 1.5 MB
You could try to use kilobytes/s instead of a decimal number in MB
RelayBandwidthBurst 1536 KB
I did not set up tor to write out the torrc file. But if have noticed on the Tor Configuration File page in arm these two config values are in red with another value behind it:
Nickname "Iridium" (Iridium) RelayBandwidthBurst 1.5 MB (1572864)
Should i file a bug report?
Try using the changes I mentioned and if it still has problems, I would definitely file a bug report.
Best, Michael
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays@lists.torproject.org
-
Dennis Christ -
diffusae -
Kurt Besig -
Louie Cardone-Noott -
Michael Armbruster -
r1610091651 -
Roger Dingledine -
teor -
theonionbox＠gmx.com -
Volker Mink