Problems with starting managed Obfsproxy server when installed via debian package and with Tor as service

added component::archived/obfsproxy owner::asn priority::medium resolution::fixed status::closed type::defect version::tor 0.2.5.1-alpha labels

Trac:
log

short log file

Trac:
debug.log

log file when level is DEBUG

Trac:
tor

the original init file (that came with Tor 0.2.2.x?)

Trac:
tor.MULTIPLE

the init file to support multiple Tor processes

I can't reproduce this behavior with the same Ubuntu version and the Debian obfsproxy package. It might be something in your environment.

What happens if you try to run tor without the init script? Can you try: tor -f torrc where tor points to your tor binary, and torrc to your torrc file?

These probably aren't your issues, but:

Replying to linda:

SocksPort 0 RunAsDaemon 1 User debian-tor

RunAsDaemon and User are set by the deb and are redundant here: see /usr/share/tor/tor-service-defaults-torrc

ORPort 8888 Nickname sricslbridge2 ExitPolicy reject : # no exits allowed

ExitPolicy defaults to reject : when BridgeRelay is 1 (but it shouldn't hurt to say it here too).

BridgeRelay 1 ServerTransportPlugin obfs2 exec /usr/bin/obfsproxy --managed

Replying to linda:

$> sudo chown -R debian-tor:adm /var/tor $> sudo ls -la /var/tor

Here's a possible hint. I expect your /usr/share/tor/tor-service-defaults-torrc says

DataDirectory /var/lib/tor

So why are you messing with /var/tor? (and where did it come from anyway -- perhaps from the other init script.)

Replying to asn:

I can't reproduce this behavior with the same Ubuntu version and the Debian obfsproxy package. It might be something in your environment.

What happens if you try to run tor without the init script? Can you try: tor -f torrc where tor points to your tor binary, and torrc to your torrc file?

YES! It must be the init script:

linda@vm05:~$ tor -f /etc/tor/torrc
Oct 01 07:12:50.618 [notice] Tor v0.2.3.22-rc (git-4a0c70a817797420) running on Linux.
...
Oct 01 07:12:53.000 [notice] Registered server transport 'obfs2' at '0.0.0.0:8082'
Oct 01 07:13:02.000 [notice] Bootstrapped 100%: Done.
Oct 01 07:13:02.000 [notice] Now checking whether ORPort 128.18.9.70:8888 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Oct 01 07:13:05.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
^Z
[1]+  Stopped                 tor -f /etc/tor/torrc
linda@vm05:~$ bg
[1]+ tor -f /etc/tor/torrc &
linda@vm05:~$ sudo grep Transport /var/lib/tor/state
linda@vm05:~$ sudo grep Transport /var/tor/state
TransportProxy obfs2 0.0.0.0:8082
linda@vm05:~$ ps axu | grep obfs
linda    16315  0.0  0.0  19024  1824 pts/0    S    07:12   0:00 /usr/bin/obfsproxy --managed

Hmmmm. It uses the state under /var/tor/ (with a little hack to force it using our open port 8082). When using the init script, I think it wants to write to /var/lib/tor/state, which is why I had originally changes the permissions for those files (with no luck).

I haven't done anything to the init script since installing Tor for the first time on this machine in version 0.2.2.x (I think Dec. 2011).

Maybe you can share your init script since it seems to work? (I'm not really an expert on administrating Linux/Debian/Ubuntu, so not very familiar with the workings of /etc/init.d/ and sudo service XXX start|stop)

Now I'm trying to add all the options in /usr/share/tor/tor-service-defaults-torrc to the command line to see if it reproduces the error. It works if I leave out User debian-tor:

linda@vm05:~$ more /usr/share/tor/tor-service-defaults-torrc 
DataDirectory /var/lib/tor
PidFile /var/run/tor/tor.pid
RunAsDaemon 1
User debian-tor

ControlSocket /var/run/tor/control
ControlSocketsGroupWritable 1

CookieAuthentication 1
CookieAuthFileGroupReadable 1
CookieAuthFile /var/run/tor/control.authcookie

Log notice file /var/log/tor/log
linda@vm05:~$ sudo -u debian-tor tor -f /etc/tor/torrc DataDirectory /var/lib/tor RunAsDaemon 1 Log "notice file /var/log/tor/log" ControlSocket /var/run/tor/control ControlSocketsGroupWritable 1 PidFile /var/run/tor/tor.pid CookieAuthentication 1 CookieAuthFileGroupReadable 1 CookieAuthFile /var/run/tor/control.authcookie
Oct 01 07:44:16.272 [notice] Tor v0.2.3.22-rc (git-4a0c70a817797420) running on Linux.
Oct 01 07:44:16.272 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Oct 01 07:44:16.272 [notice] Read configuration file "/etc/tor/torrc".
Oct 01 07:44:16.274 [notice] Your ContactInfo config option is not set. Please consider setting it, so we can contact you if your server is misconfigured or something else goes wrong.
Oct 01 07:44:16.274 [notice] We were compiled with headers from version 2.0.16-stable of Libevent, but we're using a Libevent library that says it's version 2.0.19-stable.
Oct 01 07:44:16.275 [notice] Initialized libevent version 2.0.19-stable using method epoll (with changelist). Good.
Oct 01 07:44:16.275 [notice] Opening Control listener on /var/run/tor/control
Oct 01 07:44:16.275 [notice] Opening OR listener on 0.0.0.0:8888
linda@vm05:~$ sudo grep obfs /var/log/tor/log
Oct 01 07:44:19.000 [notice] Registered server transport 'obfs2' at '0.0.0.0:53224'
linda@vm05:~$ sudo grep Transport /var/lib/tor/state
TransportProxy obfs2 0.0.0.0:53224

However, if I add the user as an option, tor doesn't even come up. Nothing else gets printed into /var/log/tor/log:

linda@vm05:~$ sudo -u debian-tor tor -f /etc/tor/torrc DataDirectory /var/lib/tor RunAsDaemon 1 Log "notice file /var/log/tor/log" ControlSocket /var/run/tor/control ControlSocketsGroupWritable 1 PidFile /var/run/tor/tor.pid CookieAuthentication 1 CookieAuthFileGroupReadable 1 CookieAuthFile /var/run/tor/control.authcookie User debian-tor
Oct 01 07:47:37.331 [notice] Tor v0.2.3.22-rc (git-4a0c70a817797420) running on Linux.
Oct 01 07:47:37.331 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Oct 01 07:47:37.331 [notice] Read configuration file "/etc/tor/torrc".
Oct 01 07:47:37.334 [notice] Your ContactInfo config option is not set. Please consider setting it, so we can contact you if your server is misconfigured or something else goes wrong.
Oct 01 07:47:37.334 [notice] We were compiled with headers from version 2.0.16-stable of Libevent, but we're using a Libevent library that says it's version 2.0.19-stable.
Oct 01 07:47:37.334 [notice] Initialized libevent version 2.0.19-stable using method epoll (with changelist). Good.
Oct 01 07:47:37.335 [notice] Opening Control listener on /var/run/tor/control
Oct 01 07:47:37.335 [notice] Opening OR listener on 0.0.0.0:8888
Oct 01 07:47:37.335 [warn] Error setting groups to gid 115: "Operation not permitted".
Oct 01 07:47:37.335 [warn] Tor is already running as debian-tor.  You do not need the "User" option if you are already running as the user you want to be.  (If you did not set the User option in your torrc, check whether it was specified on the command line by a startup script.)
Oct 01 07:47:37.335 [warn] Failed to parse/validate config: Problem with User value. See logs for details.
Oct 01 07:47:37.335 [err] Reading config failed--see warnings above.

Does this give you any clues?

Thanks! Linda

Replying to linda:

Now I'm trying to add all the options in /usr/share/tor/tor-service-defaults-torrc to the command line to see if it reproduces the error. It works if I leave out User debian-tor:

linda@vm05:~$ sudo -u debian-tor tor -f /etc/tor/torrc DataDirectory /var/lib/tor RunAsDaemon 1 Log "notice file /var/log/tor/log" ControlSocket /var/run/tor/control ControlSocketsGroupWritable 1 PidFile /var/run/tor/tor.pid CookieAuthentication 1 CookieAuthFileGroupReadable 1 CookieAuthFile /var/run/tor/control.authcookie User debian-tor Oct 01 07:47:37.335 [warn] Error setting groups to gid 115: "Operation not permitted". Oct 01 07:47:37.335 [warn] Tor is already running as debian-tor. You do not need the "User" option if you are already running as the user you want to be. (If you did not set the User option in your torrc, check whether it was specified on the command line by a startup script.) Oct 01 07:47:37.335 [warn] Failed to parse/validate config: Problem with User value. See logs for details.

Does this give you any clues?

The init script starts Tor as root, and then Tor drops privs to the debian-tor user. If you start Tor as debian-tor, you shouldn't ask it to change user. Hopefully the above explanation by Tor makes sense?

Replying to arma:

Replying to linda:

Now I'm trying to add all the options in /usr/share/tor/tor-service-defaults-torrc to the command line to see if it reproduces the error. It works if I leave out User debian-tor:

linda@vm05:~$ sudo -u debian-tor tor -f /etc/tor/torrc DataDirectory /var/lib/tor RunAsDaemon 1 Log "notice file /var/log/tor/log" ControlSocket /var/run/tor/control ControlSocketsGroupWritable 1 PidFile /var/run/tor/tor.pid CookieAuthentication 1 CookieAuthFileGroupReadable 1 CookieAuthFile /var/run/tor/control.authcookie User debian-tor Oct 01 07:47:37.335 [warn] Error setting groups to gid 115: "Operation not permitted". Oct 01 07:47:37.335 [warn] Tor is already running as debian-tor. You do not need the "User" option if you are already running as the user you want to be. (If you did not set the User option in your torrc, check whether it was specified on the command line by a startup script.) Oct 01 07:47:37.335 [warn] Failed to parse/validate config: Problem with User value. See logs for details.

Does this give you any clues?

The init script starts Tor as root, and then Tor drops privs to the debian-tor user. If you start Tor as debian-tor, you shouldn't ask it to change user. Hopefully the above explanation by Tor makes sense?

Yes, it does. And from the log output, I understood that calling tor from the command line as user debian-tor made the option User moot. I was just trying to get as close as possible to what the (broken?) init script does. Unfortunately, it worked like a charm when I called tor from the command line with all the other options.

I wish there was a way to see what kind of permission is denied when I use the init script. Is it writing to a file? Which one? I guess the --managed is still a mystery to me... (although I like how it works when I send SIGTERM to tor and it also kills the obfsproxy process if running).

Replying to asn:

I can't reproduce this behavior with the same Ubuntu version and the Debian obfsproxy package. It might be something in your environment.

What happens if you try to run tor without the init script? Can you try: tor -f torrc where tor points to your tor binary, and torrc to your torrc file?

OK, another thing that works is:

$> sudo tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc
...
$> ps axu | grep tor
107      17474  0.8  1.7 396556 69412 ?        Sl   08:50   0:02 tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc
$> id debian-tor
uid=107(debian-tor) gid=115(debian-tor) groups=115(debian-tor)
$> sudo grep obfs /var/log/tor/log
Oct 01 08:50:34.000 [notice] Registered server transport 'obfs2' at '0.0.0.0:8082'
$> sudo grep Transport /var/lib/tor/state
TransportProxy obfs2 0.0.0.0:8082

but the init script still doesn't work. However, I can use the init script to stop the above started tor and obfsproxy. So using this method for now to have the bridge up and running. However, if you have any clues as to what the init script does differently to the above command line, maybe we can fix it for future use...

Are you certain you didn't modify the init script during all your mucking with alternate init scripts?

I would guess that whatever introduced /var/tor/ is what is causing the rest of your problems.

Replying to arma:

Are you certain you didn't modify the init script during all your mucking with alternate init scripts?

Not 100% certain... Where could I get a clean init script?

Replying to linda:

Replying to arma:

Replying to linda:

Now I'm trying to add all the options in /usr/share/tor/tor-service-defaults-torrc to the command line to see if it reproduces the error. It works if I leave out User debian-tor:

linda@vm05:~$ sudo -u debian-tor tor -f /etc/tor/torrc DataDirectory /var/lib/tor RunAsDaemon 1 Log "notice file /var/log/tor/log" ControlSocket /var/run/tor/control ControlSocketsGroupWritable 1 PidFile /var/run/tor/tor.pid CookieAuthentication 1 CookieAuthFileGroupReadable 1 CookieAuthFile /var/run/tor/control.authcookie User debian-tor Oct 01 07:47:37.335 [warn] Error setting groups to gid 115: "Operation not permitted". Oct 01 07:47:37.335 [warn] Tor is already running as debian-tor. You do not need the "User" option if you are already running as the user you want to be. (If you did not set the User option in your torrc, check whether it was specified on the command line by a startup script.) Oct 01 07:47:37.335 [warn] Failed to parse/validate config: Problem with User value. See logs for details.

Does this give you any clues?

The init script starts Tor as root, and then Tor drops privs to the debian-tor user. If you start Tor as debian-tor, you shouldn't ask it to change user. Hopefully the above explanation by Tor makes sense?

Yes, it does. And from the log output, I understood that calling tor from the command line as user debian-tor made the option User moot. I was just trying to get as close as possible to what the (broken?) init script does. Unfortunately, it worked like a charm when I called tor from the command line with all the other options.

I wish there was a way to see what kind of permission is denied when I use the init script. Is it writing to a file? Which one? I guess the --managed is still a mystery to me... (although I like how it works when I send SIGTERM to tor and it also kills the obfsproxy process if running).

The permission error happened when Tor tried to execute the file /usr/bin/obfsproxy. execve() (the function used to execute that file) says "Permission denied" when the following things happen:

       EACCES Search permission is denied on a component of the path prefix of filename or the name of a script interpreter.  (See also path_resolution(7).)

       EACCES The file or a script interpreter is not a regular file.

       EACCES Execute permission is denied for the file or a script or ELF interpreter.

       EACCES The file system is mounted noexec.

I'm not sure in which case you belong, and unfortunately there is no way for execve() to be more verbose.

I also tried using your /etc/tor/torrc with the default init script of tor in Ubuntu, and obfsproxy spawned fine.

If you feel playful, you can move the obfsproxy binary to a different place (like /tmp/obfsproxy or something) and see if you still get the Permission Denied error. Or you can replace /usr/bin/obfsproxy with a different binary and see if you still get the same error.

Replying to linda:

Replying to arma:

Are you certain you didn't modify the init script during all your mucking with alternate init scripts?

Not 100% certain... Where could I get a clean init script?

apt-get purge tor (then check to make sure the init script is gone) then apt-get install tor?

Be sure to back up your torrc and whatever else you want before doing.

In between purge and install, you might want to blow away /var/lib/tor, /var/tor/, etc too.

@linda, I think I have the same issue here:

When I start tor via the initscript, I get the same error:

  Could not launch managed proxy executable at '/usr/bin/obfsproxy' ('Permission denied')

When I start tor manually via the commandline, it works. I too am using Ubuntu 12.04.1 LTS and in the system log I just found:

type=1400 audit(1352141151.479:26): apparmor="DENIED" operation="exec" parent=21625 profile="system_tor" \
name="/usr/bin/obfsproxy" pid=21628 comm="tor" requested_mask="x" denied_mask="x" fsuid=106 ouid=0

So it's AppArmor playing games here and somehow we must alter the policy to allow obfsproxy be started by the init-script. I'm not AppArmor savvy (yet), but that's the way to go, I suppose. Maybe you see these AppArmor messages too in your logs?

Trac:
Username: Christian

This is because of the apparmor profile 'system_tor' that replaces old usr.sbin.tor and that has effect only over tor loaded as a system service.

IMHO the best thing to do here is to add a line to allow tor execing obfsproxy in the file /etc/apparmor.d/local/system_tor.

/path_to_obfsproxy/obfsproxy rx

Thanks! I've come accross an AppArmor profile, but this did not work. The line above did almost work, but AppArmor complained:

AppArmor parser error for /etc/apparmor.d/system_tor in /etc/apparmor.d/local/system_tor at line 4: \
 Invalid mode, 'x' must be preceded by exec qualifier 'i', 'p', 'c', or 'u'

So I replaced "rx" ("read", "execute") with "ix" ("inherit execute"):

$ cat /etc/apparmor.d/local/system_tor
        /usr/bin/obfsproxy ix,

$ apparmor_parser --version
AppArmor parser version 2.7.102
Copyright (C) 1999-2008 Novell Inc.
Copyright 2009-2012 Canonical Ltd.

Now tor can be started with the init script again and obfsproxy is started too. Yay! :)

Trac:
Username: Christian

Replying to Christian:

So it's AppArmor playing games here and somehow we must alter the policy to allow obfsproxy be started by the init-script.

Christian, is the apparmor profile enabled by default for your Ubuntu Tor? Or is that something you opted to do yourself?

Linda, when you fixed your other issues, did you experience this apparmor issue?

AFAICS is AppArmor enabled by default in Ubuntu (I'm using a Tor-enabled Amazon-EC2 image):

$ grep APPARMOR /boot/config-3.2.0-34-virtual CONFIG_SECURITY_APPARMOR=y CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=1 CONFIG_DEFAULT_SECURITY_APPARMOR=y

and /etc/apparmor.d/local/system_tor did exist, but was empty. After adding the line above to this file, Tor could be started via the init-script. The tor package (0.2.3.25-1~precise+1 from deb.torproject.org) already shipped /etc/apparmor.d/system_tor.

Trac:
Username: Christian

With obfsproxy-0.2.1-2~precise+1 from http://deb.torproject.org, we have an AppArmor issue again:

[warn] Our communication channel with the managed proxy '/usr/bin/obfsproxy' closed. Most probably application stopped running.

And the syslog has:

type=1400 audit(1366160396.398:13): apparmor="DENIED" operation="open" parent=21994 profile="system_tor" name="/usr/include/python2.7/pyconfig.h" pid=21996 comm="obfsproxy" requested_mask="r" denied_mask="r" fsuid=106 ouid=0

My /etc/apparmor.d/local/system_tor already has:

/usr/bin/obfsproxy ix,

With the new denied message above, I tried to extend this as:

        /usr/bin/obfsproxy ix,
        /usr/include/python2.7/pyconfig.h ixr,

But now even more messages are spewed out:

type=1400 audit(1366169189.559:36): apparmor="DENIED" operation="open" parent=31676 profile="system_tor" name="/usr/local/lib/python2.7/dist-packages/" pid=31680 comm="obfsproxy" requested_mask="r" denied_mask="r" fsuid=106 ouid=0

type=1400 audit(1366169189.559:37): apparmor="DENIED" operation="open" parent=31676 profile="system_tor" name="/usr/share/pyshared/zope.interface-3.6.1-nspkg.pth" pid=31680 comm="obfsproxy" requested_mask="r" denied_mask="r" fsuid=106 ouid=0

type=1400 audit(1366169189.559:38): apparmor="DENIED" operation="open" parent=31676 profile="system_tor" name="/etc/python2.7/sitecustomize.py" pid=31680 comm="obfsproxy" requested_mask="r" denied_mask="r" fsuid=106 ouid=0

type=1400 audit(1366169189.559:39): apparmor="DENIED" operation="open" parent=31676 profile="system_tor" name="/usr/bin/obfsproxy" pid=31680 comm="obfsproxy" requested_mask="r" denied_mask="r" fsuid=106 ouid=0

type=1400 audit(1366169189.559:40): apparmor="DENIED" operation="open" parent=31676 profile="system_tor" name="/usr/bin/obfsproxy" pid=31680 comm="obfsproxy" requested_mask="r" denied_mask="r" fsuid=106 ouid=0

I'll have to read up on AppArmor 101 and find out how to continue from here...

Trac:
Username: Christian

Hm, I don't know much about AppArmor configuration, but it seems that you should allow it to access Python modules (and weird scripts like sitecustomize.py). There is probably a standard way to whitelist Python applications in AppArmor, right?

You can run aa-genprof which will put apparmor in complain mode then will analyze kernel logs looking for apparmor syslog messages and finally generate a more or less accurate profile for the specific program

sudo aa-genprof /usr/bin/obfsproxy

Hm, this does generate a new policy in /etc/apparmor.d/usr.bin.obfsproxy (which did not exist before):

#include <tunables/global>
/usr/bin/obfsproxy {
  #include <abstractions/base>
  #include <abstractions/python>
  /usr/bin/obfsproxy r,
  /usr/bin/python2.7 ix,
}

And I still have my local/system_tor in place (which is included by /etc/apparmor.d):

        /usr/bin/obfsproxy ix,

Reload all profiles:

$ service apparmor reload

But obfsproxy is denied access again:

type=1400 audit(1366247818.957:57): apparmor="DENIED" operation="open" parent=28250 profile="system_tor" name="/usr/include/python2.7/pyconfig.h" pid=28252 comm="obfsproxy" requested_mask="r" denied_mask="r" fsuid=106 ouid=0

Interestingly it says "profile=system_tor", although I just generated /etc/apparmor.d/usr.bin.obfsproxy. Hm, for now I'll let obfsproxy run unconfined:

  /usr/bin/obfsproxy Uxr,

I'll have to ponder this a bit more. But maybe I should take this to the mailing list instead of spamming this ticket, sorry for this.

Trac:
Username: Christian

Bump. This is still an issue using nightly Tor, nightly obfsproxy with Ubuntu 13.10.

The apparmor profile needs to be fixed. What can I change to allow it to run?

Trac:
Username: funkstar

Replying to funkstar:

Bump. This is still an issue using nightly Tor, nightly obfsproxy with Ubuntu 13.10.

The apparmor profile needs to be fixed. What can I change to allow it to run?

Hey funkstar,

this ticket is about the old C-based obfsproxy. obfsproxy has been reimplemented in Python since then. See the installation instructions in https://www.torproject.org/projects/obfsproxy.html.en .

I will close this ticket as it's outdated. Please reopen if you don't think so.

Trac:
Resolution: N/A to wontfix
Status: new to closed

It doesn't make a difference what it's coded in. This is a permissions issue when auto launching at startup which starts with the "debian-t" profile.

Launching it via terminal there is no issues, but that launches as root. I don't know enough about apparmor to help debug it, but looking through the profiles, there are 0 entries for obfsproxy, making me think the profile was created before obfsproxy even existed.

Trac:
Username: funkstar
Status: closed to reopened
Version: Tor: 0.2.3.22-rc to Tor: 0.2.5.1-alpha
Resolution: wontfix to N/A

AFAIK, the Tor AppArmor profile is neither shipped in Tor nor obfsproxy tarballs. It is only shipped by the tor Debian package. So, the relevant place to report this bug is the Debian bug tracker.

Assuming this is done (and hopefully the problem is summarized, so that I can avoid reading 1.5 years of comments on this ticket), I've got great news for you: luckily, the person who wrote this profile, had it integrated into the Debian package, and is happy to maintain it (hint: that's me) is subscribed to the bugs affecting the tor package on the Debian bug tracker, and will then know about it... as opposed to learning about the problem 17 months after it has been submitted here.

Thanks in advance :)

I'm not using anything from Debian. I'm using the auto generated nightly PPA which is hosted on torproject.org and thus, created a ticket on the Tor ticket tracker. I will not be registering to the Debian tracker to report something that is already documented here, sorry.

The full error is below, feel free to ask any other questions, though I'm not sure what more can be said that I haven't already. There's no real need to read the other posts.

[warn] Could not launch managed proxy executable at '/usr/bin/obfsproxy' ('Permission denied')

Trac:
Username: funkstar

Reported as Debian bug 739279, with a patch attached.

Dear obfsproxy / Tor folks, I assume this is another occurrence of unclear scopes of responsibilities, that lead us to wait that long before the person responsible for these bits was made aware of the situation. In the future, please forward issues with the AppArmor profile shipped in the tor Debian package to me, or, even better, to the Debian bug tracker. Thanks in advance :)

Now, I'll let you handle this ticket the way you want, and won't monitor it.

I still don't understand what it has to do with Debian, but thank you anyway.

If they fix that, will it be pulled into the Tor PPA?

Trac:
Username: funkstar

Even though you included a patch, it seems like your report has been ignored on the Debian bug tracker. :/

Trac:
Username: funkstar

Replying to funkstar:

Even though you included a patch, it seems like your report has been ignored on the Debian bug tracker. :/

Feel free to ping the maintainer (weasel) about it. Reporting that the attached patch fixes the problem for you might help.

For completeness, here's the URL to the Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739279

Trac:
Cc: N/A to weasel

Fixed upstream.

Trac:
Username: funkstar
Resolution: N/A to fixed
Status: reopened to closed

closed

mentioned in issue #6997 (moved)

mentioned in issue #9460 (closed)

mentioned in issue tpo/core/tor#6997 (closed)

Problems with starting managed Obfsproxy server when installed via debian package and with Tor as service

Child items ...

Activity