My relay became one of the "rejected" since the heartbleed vulnerability surfaced so I reformatted my XP relay and did a fresh Ubuntu 14.04 LTS install. Built vidalia-0.2.21 from source using:
deb http://deb.torproject.org/torproject.org trusty main deb-src http://deb.torproject.org/torproject.org trusty main
apt-get install build-essential fakeroot devscripts qt4-dev-tools qt4-designer libqt4-dev g++ cmake apt-get build-dep vidalia
mkdir ~/debian-packages; cd ~/debian-packages apt-get source vidalia cd vidalia-* debuild -rfakeroot -uc -us cd ..
sudo dpkg -i vidalia_*.deb
Edited /etc/tor/torrc allowing connection ports.
I'm unable to open vidalia with these error messages:
1. As non-admin: /usr/bin/vidalia
(process:540): GConf-WARNING **: Client failed to connect to the D-BUS daemon: An AppArmor policy prevents this sender from sending this message to this recipient, 0 matched rules; type="method_call", sender="(null)" (inactive) interface="org.freedesktop.DBus" member="Hello" error name="(unset)" requested_reply="0" destination="org.freedesktop.DBus" (bus)
(<unknown>:540): GLib-GIO-ERROR **: No GSettings schemas are installed on the system Trace/breakpoint trap (core dumped)
2. As root: /usr/bin/vidalia
No protocol specified vidalia: cannot connect to X server :0
3. As root: /usr/bin/X11/vidalia
No protocol specified vidalia: cannot connect to X server :0
I've seen similar errors searching for a fix, but none that seemed "resolved". Any suggestions would be appreciated as I'd like to get back up and running ASAP
Thanks
------------------------------------------------------------------------
On Sat, Apr 19, 2014 at 10:42 PM, kbesig kbesig@socal.rr.com wrote:
- As root: /usr/bin/vidalia
No protocol specified vidalia: cannot connect to X server :0
I am not sure if you should be running vidalia as root, but if you wish to test:
1. Open a terminal before you switch to root 2.
xhost local:root
3. Be aware that any program running as root can now manipulate your display
The effect will last till you restart X.
Yes, thanks for the concern regarding root, I was doing so for test purposes only. :/usr/bin$ xhost local:root
non-network local connections being added to access control list :/usr/bin$ /usr/bin/vidalia
(process:1341): GConf-WARNING **: Client failed to connect to the D-BUS daemon: An AppArmor policy prevents this sender from sending this message to this recipient, 0 matched rules; type="method_call", sender="(null)" (inactive) interface="org.freedesktop.DBus" member="Hello" error name="(unset)" requested_reply="0" destination="org.freedesktop.DBus" (bus)
(<unknown>:1341): GLib-GIO-ERROR **: No GSettings schemas are installed on the system Trace/breakpoint trap (core dumped)
** On 04/19/2014 08:09 AM, Sanjeev Gupta wrote:
On Sat, Apr 19, 2014 at 10:42 PM, kbesig <kbesig@socal.rr.com mailto:kbesig@socal.rr.com> wrote:
2. As root: /usr/bin/vidalia No protocol specified vidalia: cannot connect to X server :0
I am not sure if you should be running vidalia as root, but if you wish to test:
- Open a terminal before you switch to root
- |xhost local:root|
- Be aware that any program running as root can now manipulate your display
The effect will last till you restart X.
-- Sanjeev Gupta +65 98551208 http://www.linkedin.com/in/ghane
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Sat, Apr 19, 2014 at 11:46 PM, kbesig kbesig@socal.rr.com wrote:
Yes, thanks for the concern regarding root, I was doing so for test purposes only. :/usr/bin$ xhost local:root
non-network local connections being added to access control list :/usr/bin$ /usr/bin/vidalia
(process:1341): GConf-WARNING **: Client failed to connect to the D-BUS daemon: An AppArmor policy prevents this sender from sending this message to this recipient, 0 matched rules; type="method_call", sender="(null)" (inactive) interface="org.freedesktop.DBus" member="Hello" error name="(unset)" requested_reply="0" destination="org.freedesktop.DBus" (bus)
(<unknown>:1341): GLib-GIO-ERROR **: No GSettings schemas are installed on the system Trace/breakpoint trap (core dumped)
My workaround only enabled root to connect, the AppArmor issue still needs to be resolved :-)
Why not use the .deb repos?
On 04/19/2014 05:42 PM, kbesig wrote:
My relay became one of the "rejected" since the heartbleed vulnerability surfaced so I reformatted my XP relay and did a fresh Ubuntu 14.04 LTS install. Built vidalia-0.2.21 from source using:
I would suggest completely avoiding (the burden of) Vidalia. You can just install Tor as standalone daemon : https://www.torproject.org/docs/debian.html.en
If you want an interface to inspect your relay's traffic (the reason you wanted Vidalia?), I suggest tor-arm (provided you've already added Tor's repositories):
apt-get install tor-arm
then run :
sudo -u debian-tor arm
Cheers, Alex
Thanks for that, Alex, I had no problems installing Tor and have been starting the gui using the shell script : ~/Tor/tor-browser_en-US$ sh start-tor-browser
Launching Tor Browser Bundle for Linux in /home/user/Tor/tor-browser_en-US <yada-yada>
I'll give your suggestion, "tor-arm", a try.
On 04/19/2014 08:16 AM, irregulator@riseup.net wrote:
On 04/19/2014 05:42 PM, kbesig wrote:
My relay became one of the "rejected" since the heartbleed vulnerability surfaced so I reformatted my XP relay and did a fresh Ubuntu 14.04 LTS install. Built vidalia-0.2.21 from source using:
I would suggest completely avoiding (the burden of) Vidalia. You can just install Tor as standalone daemon : https://www.torproject.org/docs/debian.html.en
If you want an interface to inspect your relay's traffic (the reason you wanted Vidalia?), I suggest tor-arm (provided you've already added Tor's repositories):
apt-get install tor-arm
then run :
sudo -u debian-tor arm
Cheers, Alex _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Sorry for the spam in advance..
Install of tor-arm went well enough, no error msg's.
~$ sudo -u debian-tor arm
Traceback (most recent call last): File "/usr/share/arm/starter.py", line 578, in <module> cli.controller.startTorMonitor(time.time() - initTime) File "/usr/share/arm/cli/controller.py", line 700, in startTorMonitor curses.wrapper(drawTorMonitor, startTime) File "/usr/lib/python2.7/curses/wrapper.py", line 43, in wrapper return func(stdscr, *args, **kwds) File "/usr/share/arm/cli/controller.py", line 795, in drawTorMonitor cli.wizard.showWizard() File "/usr/share/arm/cli/wizard.py", line 313, in showWizard relaySelection = RelayType.RESUME if manager.isTorrcAvailable() else RelayType.RELAY File "/usr/share/arm/cli/controller.py", line 487, in isTorrcAvailable torrcLoc = self.getTorrcPath() File "/usr/share/arm/cli/controller.py", line 479, in getTorrcPath return self._controller.getDataDirectory() + "torrc" File "/usr/share/arm/cli/controller.py", line 406, in getDataDirectory if not os.path.exists(dataDir): os.makedirs(dataDir) File "/usr/lib/python2.7/os.py", line 157, in makedirs mkdir(name, mode) OSError: [Errno 13] Permission denied: '/home/user/.arm/' Exception in thread Thread-3 (most likely raised during interpreter shutdown): Traceback (most recent call last):Exception in thread Thread-2 (most likely raised during interpreter shutdown): File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner File "/usr/share/arm/cli/logPanel.py", line 1189, in runException in thread Thread-4 (most likely raised during interpreter shutdown): Traceback (most recent call last): File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner File "/usr/share/arm/cli/connections/connPanel.py", line 281, in run File "/usr/lib/python2.7/threading.py", line 202, in release <type 'exceptions.TypeError'>: 'NoneType' object is not callable
File "/usr/lib/python2.7/threading.py", line 202, in release <type 'exceptions.TypeError'>: 'NoneType' object is not callableTraceback (most recent call last):
Any ideas??
On 04/19/2014 08:16 AM, irregulator@riseup.net wrote:
On 04/19/2014 05:42 PM, kbesig wrote:
My relay became one of the "rejected" since the heartbleed vulnerability surfaced so I reformatted my XP relay and did a fresh Ubuntu 14.04 LTS install. Built vidalia-0.2.21 from source using:
I would suggest completely avoiding (the burden of) Vidalia. You can just install Tor as standalone daemon : https://www.torproject.org/docs/debian.html.en
If you want an interface to inspect your relay's traffic (the reason you wanted Vidalia?), I suggest tor-arm (provided you've already added Tor's repositories):
apt-get install tor-arm
then run :
sudo -u debian-tor arm
Cheers, Alex _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Getting closer: I can run tor arm as root, but get this error as <user>: ~$ sudo -u debian-tor arm [sudo] password for <user>: Connection refused. Is the ControlPort enabled?
Where is arm's config?
On 04/19/2014 09:19 AM, kbesig wrote:
Sorry for the spam in advance..
Install of tor-arm went well enough, no error msg's.
~$ sudo -u debian-tor arm
Any ideas??
On 04/19/2014 08:16 AM, irregulator@riseup.net wrote:
On 04/19/2014 05:42 PM, kbesig wrote:
My relay became one of the "rejected" since the heartbleed vulnerability surfaced so I reformatted my XP relay and did a fresh Ubuntu 14.04 LTS install. Built vidalia-0.2.21 from source using:
I would suggest completely avoiding (the burden of) Vidalia. You can just install Tor as standalone daemon : https://www.torproject.org/docs/debian.html.en
If you want an interface to inspect your relay's traffic (the reason you wanted Vidalia?), I suggest tor-arm (provided you've already added Tor's repositories):
apt-get install tor-arm
then run :
sudo -u debian-tor arm
Cheers, Alex _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Enable the ControlPort in your torrc file by uncommenting it, and setup authentication to the ControlPort in one of two ways: HashedControlPassword or CookieAuthentication.
To enable CookieAuthentication, simply remove the hash sign in front of that line. I can't remember how to do HashedControlPassword off the top of my head, but can find the answer should you like.
Arm isn't typically run with a config file, but can be with --config-path if I remember correctly.
Tor-arm's readme: https://gitweb.torproject.org/arm.git/blob/HEAD:/README On Apr 19, 2014 1:42 PM, "kbesig" kbesig@socal.rr.com wrote:
Getting closer: I can run tor arm as root, but get this error as <user>: ~$ sudo -u debian-tor arm [sudo] password for <user>: Connection refused. Is the ControlPort enabled?
Where is arm's config?
On 04/19/2014 09:19 AM, kbesig wrote:
Sorry for the spam in advance..
Install of tor-arm went well enough, no error msg's.
~$ sudo -u debian-tor arm
Any ideas??
On 04/19/2014 08:16 AM, irregulator@riseup.net wrote:
On 04/19/2014 05:42 PM, kbesig wrote:
My relay became one of the "rejected" since the heartbleed vulnerability surfaced so I reformatted my XP relay and did a fresh Ubuntu 14.04 LTS install. Built vidalia-0.2.21 from source using:
I would suggest completely avoiding (the burden of) Vidalia. You can
just install Tor as standalone daemon : https://www.torproject.org/docs/debian.html.en
If you want an interface to inspect your relay's traffic (the reason you wanted Vidalia?), I suggest tor-arm (provided you've already added Tor's repositories):
apt-get install tor-arm
then run :
sudo -u debian-tor arm
Cheers, Alex _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
kbesig:
Getting closer: I can run tor arm as root, but get this error as <user>: ~$ sudo -u debian-tor arm [sudo] password for <user>:
Urg… please never do that. You should not run applications with the same privileges as Tor.
What you want is to add your current user to the “debian-tor” group:
sudo adduser $USER debian-tor
Then arm should be able to connect to the system-wide Tor daemon unless you have changed the default Tor configuration.
On Sun, 20 Apr 2014 15:19:57 +0200 Lunar lunar@torproject.org allegedly wrote:
kbesig:
Getting closer: I can run tor arm as root, but get this error as <user>: ~$ sudo -u debian-tor arm [sudo] password for <user>:
Urg… please never do that. You should not run applications with the same privileges as Tor.
However...
when run as an uprivileged user (with that user a member of the debian-tor group), arm reports
"[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 connections 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"). "
Mick ---------------------------------------------------------------------
Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 http://baldric.net
---------------------------------------------------------------------
On Sat, Apr 19, 2014 at 09:19:26AM -0700, kbesig wrote:
Install of tor-arm went well enough, no error msg's.
~$ sudo -u debian-tor arm
You're using arm dangerously. See item #14 on https://www.torproject.org/docs/tor-relay-debian for the safer way to run arm with your Debian / Ubuntu relay.
And you'll want to follow the other instructions on that page too.
Also, I have no idea what all you might have messed up with your attempts to do things the wrong way, so you might need to back some of those changes out too.
Good luck, and thanks for running a relay! --Roger
On 4/19/2014 4:16 PM, Roger Dingledine wrote:
On Sat, Apr 19, 2014 at 09:19:26AM -0700, kbesig wrote:
Install of tor-arm went well enough, no error msg's.
~$ sudo -u debian-tor arm
You're using arm dangerously. See item #14 on https://www.torproject.org/docs/tor-relay-debian for the safer way to run arm with your Debian / Ubuntu relay.
<snip>
--Roger
Wow, I always thought that *was* the "safe" way to run arm. I wonder where we both got the advice to do it the dangerous way.
It's worth noting that, under Debian (Jessie, others?), arm will be unable to read tor's logs if you run it as your user. The default group for /var/log/tor is 'adm'. You'll have to:
$ sudo chgrp -R debian-tor /var/log/tor
This will make the logs readable to you (and arm), but unreadable to any system monitoring tools that use the adm group.
-- Mike
Thanks for pointing this 'unsafe' use of arm out guys - I just checked and it somehow snuck into my Pi relay tutorial docs also. I'll update them when I have had chance to do some testing early next week.
Best,
Chris On 19 Apr 2014 21:50, "Michael Wolf" mikewolf@riseup.net wrote:
On 4/19/2014 4:16 PM, Roger Dingledine wrote:
On Sat, Apr 19, 2014 at 09:19:26AM -0700, kbesig wrote:
Install of tor-arm went well enough, no error msg's.
~$ sudo -u debian-tor arm
You're using arm dangerously. See item #14 on https://www.torproject.org/docs/tor-relay-debian for the safer way to run arm with your Debian / Ubuntu relay.
<snip> > --Roger
Wow, I always thought that *was* the "safe" way to run arm. I wonder where we both got the advice to do it the dangerous way.
It's worth noting that, under Debian (Jessie, others?), arm will be unable to read tor's logs if you run it as your user. The default group for /var/log/tor is 'adm'. You'll have to:
$ sudo chgrp -R debian-tor /var/log/tor
This will make the logs readable to you (and arm), but unreadable to any system monitoring tools that use the adm group.
-- Mike _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Wow, I always thought that *was* the "safe" way to run arm. I wonder where we both got the advice to do it the dangerous way.
from ARM [ARM_NOTICE] Arm is currently running with root permissions. This is not a good idea, and will still work perfectly well if it's run with the same user as Tor (ie, starting with "sudo -u debian-tor arm").
~$ sudo -u debian-tor arm
You're using arm dangerously. See item #14 on https://www.torproject.org/docs/tor-relay-debian for the safer way to run arm with your Debian / Ubuntu relay.
<snip> > --Roger
On Sat, Apr 19, 2014 at 02:15:52PM -0800, I wrote:
Wow, I always thought that *was* the "safe" way to run arm. I wonder where we both got the advice to do it the dangerous way.
from ARM [ARM_NOTICE] Arm is currently running with root permissions. This is not a good idea, and will still work perfectly well if it's run with the same user as Tor (ie, starting with "sudo -u debian-tor arm").
Yep.
https://trac.torproject.org/projects/tor/ticket/10702
Damian is planning to revise arm at some point, but at least this part of it has been frozen without much development for a long time now.
If you want to help out, this might be a good opportunity. :)
--Roger
On 4/19/2014 4:50 PM, Michael Wolf wrote:
It's worth noting that, under Debian (Jessie, others?), arm will be unable to read tor's logs if you run it as your user. The default group for /var/log/tor is 'adm'. You'll have to:
$ sudo chgrp -R debian-tor /var/log/tor
This will make the logs readable to you (and arm), but unreadable to any system monitoring tools that use the adm group.
Apparently arm is also unable to read the bandwidth history, as /var/lib/tor has the setgid bit set, but not group read or execute. Is there any reason for setgid to be set on this directory? This is not something I would have done.
-- Mike
Roger Dingledine:
You're using arm dangerously. See item #14 on https://www.torproject.org/docs/tor-relay-debian for the safer way to run arm with your Debian / Ubuntu relay.
Followed item #14, but after logging out/in I get:
$ arm Connection refused. Is the ControlPort enabled?
'groups' shows the 'debian-tor' group. 'sudo -u debian-tor arm' still works. Anyone have an idea what I've missed?
Thanks, Delton
Roger Dingledine:
You're using arm dangerously. See item #14 on https://www.torproject.org/docs/tor-relay-debian for the safer way to run arm with your Debian / Ubuntu relay.
Followed item #14, but after logging out/in I get:
$ arm Connection refused. Is the ControlPort enabled?
'groups' shows the 'debian-tor' group. 'sudo -u debian-tor arm' still works. Anyone have an idea what I've missed?
Thanks, Delton
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 4/30/2014 11:38 AM, Delton Barnes wrote:
Roger Dingledine:
You're using arm dangerously. See item #14 on https://www.torproject.org/docs/tor-relay-debian for the safer way to run arm with your Debian / Ubuntu relay.
Followed item #14, but after logging out/in I get:
$ arm Connection refused. Is the ControlPort enabled?
'groups' shows the 'debian-tor' group. 'sudo -u debian-tor arm' still works. Anyone have an idea what I've missed?
Thanks, Delton _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
"14. You might like to use the arm relay monitor to watch your relay's activities from the command line. First, "sudo apt-get install tor-arm". Second, as the user that will be running arm, run "sudo adduser $USER debian-tor" to add your user to the debian-tor group so it can reach Tor's controlsocket. Then log out and log back in (so your user is actually in the group), and run "arm"."
This worked for me, just remember to logout/in and restart tor and arm. Also be sure to un-comment the ControlPort and assign an ip to it if different that default in your /etc/torrc.
--- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com
Kurt Besig:
Also be sure to un-comment the ControlPort and assign an ip to it if different that default in your /etc/torrc.
Alexander Dietrich:
Does the "debian-tor" group have access to the file "/var/run/tor/control.authcookie"?
Thanks, Kurt & Alexander. I had not enabled the ControlPort. That should have been obvious from the error, but I assumed since arm was working for user debian-tor that the ControlPort must already be enabled. After enabling it and giving the cookie file g+r, arm is working as my regular user.
On 2014-04-30 20:38, Delton Barnes wrote:
Followed item #14, but after logging out/in I get:
$ arm Connection refused. Is the ControlPort enabled?
'groups' shows the 'debian-tor' group. 'sudo -u debian-tor arm' still works. Anyone have an idea what I've missed?
Does the "debian-tor" group have access to the file "/var/run/tor/control.authcookie"?
Alexander
On Sat, 2014-04-19 at 07:42 -0700, kbesig wrote:
- As non-admin: /usr/bin/vidalia
(process:540): GConf-WARNING **: Client failed to connect to the D-BUS daemon: An AppArmor policy prevents this sender from sending this message to this recipient, 0 matched rules; type="method_call", sender="(null)" (inactive) interface="org.freedesktop.DBus" member="Hello" error name="(unset)" requested_reply="0" destination="org.freedesktop.DBus" (bus)
I agree with others who have said you should drop vidalia and use tor + arm. Nonetheless, I guess you have set an AppArmor policy which is blocking vidalia.
tor-relays@lists.torproject.org