Opened 8 years ago

Closed 8 years ago

#1989 closed defect (fixed)

Tor in OS X bundle uses wrong path for geoip file

Reported by: Tas Owned by: erinn
Priority: Medium Milestone: Tor: 0.2.2.x-final
Component: Applications/Tor bundles/installation Version: Tor: 0.2.2.15-alpha
Severity: Keywords: help
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Seems that Tor 0.2.2.16-alpha on OS X expects the geoip file in the wrong directory. When running as bridge I see in the log:

[Warning] Failed to open GEOIP file /Library/Tor/share/tor/geoip. We've been configured to see which countries can access us as a bridge, and we need GEOIP information to tell which countries clients are in.

But there is no /Library/Tor on my system. It seems the file woule be /Applications/Vidalia.app/Contents/Resources/geoip by default.

Child Tickets

TicketStatusOwnerSummaryComponent
#2102closederinnmac users missing 0.2.2.17-alphaApplications/Tor bundles/installation

Change History (23)

comment:1 Changed 8 years ago by Sebastian

We should find a solution that doesn't require us to hardcode the path, if that is possible.

comment:2 Changed 8 years ago by arma

Component: VidaliaTor bundles/installation
Milestone: Tor: post 0.2.2.xTor: 0.2.2.x-final
Owner: set to erinn
Status: newassigned

Calling this an 0.2.2.x bug since we'll want to sort it out soon.

Is it a bundle bug, insofar as we're building the Tor in the OS X bundle with misleading paths?

Or a Tor bug, if Tor on OS X is guessing the wrong default place to look for the geoip file?

comment:3 Changed 8 years ago by Sebastian

It is probably a combination of things. It's a bundle bug insofar that we build the tor in the bundle in a way so that it wants to look into /Applications/Vidalia.app/share/tor/geoip. Instead we should make it look for it in /Applications/Vidalia.app/Resources/geoip. But that means that Tor will fail to find the geoip file if we don't put Vidalia into /Applications, so the real fix is to make Vidalia pass the right path to Tor.

comment:4 Changed 8 years ago by arma

See also https://trac.vidalia-project.net/ticket/535

Same bug?

(If so, more urgent now that Vidalia has stopped doing its own geoip)

comment:5 Changed 8 years ago by arma

Summary: Flags missing in vidalia's network map on Mac IntelTor in OS X bundle uses wrong path for geoip file

comment:6 Changed 8 years ago by Sebastian

yes, same bug.

comment:7 Changed 8 years ago by erinn

Keywords: help added

I think this is a bug in Tor's configure. We special-case Windows and we might need to special-case OSX as well, at least now. in src/or/config.c (258) we have:

#ifdef WIN32
  V(GeoIPFile,                   FILENAME, "<default>"),
#else
  V(GeoIPFile,                   FILENAME,
    SHARE_DATADIR PATH_SEPARATOR "tor" PATH_SEPARATOR "geoip"),

Nick or Sebastian, could you comment on this? This seems like more than a simple packaging fix.

comment:8 Changed 8 years ago by Sebastian

I think there are two different issues at play here, but the Tor thing is the minor one: We should find something better than the <default> stuff for windows and a better solution than an absolute path for the geoipfile option in general. But that won't help in the Vidalia bundle case, because users might move the tbb around etc.

So the second and much more important fix is that Vidalia needs to figure out how to pass a path to the geoipdb file when it launches Tor, because the correct path needs to be determined at runtime.

comment:9 Changed 8 years ago by arma

One good solution would be to add a ShareDir variable to Vidalia's [Tor] section, and teach Vidalia how to tell Tor what its sharedir should be as a torrc option, and teach Tor how to use the dynamically chosen sharedir if it's non-default (with the default being null).

One cheap solution in the mean time would be to teach Tor how to be told by ./configure that its sharedir is its datadir, and change the bundle to put geoip into the datadir... but wait, the datadir is ~/.tor/ and the bundle doesn't know what ~ will be when you're installing it. Or does it? Ugh.

Another cheap solution would be to build the tor binary that goes in the os x vidalia bundle with a hard-coded sharedir which is the place where we put geoip, polipo.conf, etc. That would solve the immediate problem.

How does OS X TBB solve this? As Sebastian says, it needs to have its paths be relative to where you're running it from. Does OS X TBB still use a hard-coded polipo config file location?

comment:10 in reply to:  9 Changed 8 years ago by arma

Replying to arma:

One good solution would be to add a ShareDir variable to Vidalia's [Tor] section, and teach Vidalia how to tell Tor what its sharedir should be as a torrc option, and teach Tor how to use the dynamically chosen sharedir if it's non-default (with the default being null).

And by "as a torrc option", in practice I expect I will mean "as a command-line option".

comment:11 in reply to:  9 ; Changed 8 years ago by arma

Replying to arma:

Another cheap solution would be to build the tor binary that goes in the os x vidalia bundle with a hard-coded sharedir which is the place where we put geoip, polipo.conf, etc. That would solve the immediate problem.

I think this is the short-term hack that we should do. The OS X Vidalia bundle will already fail if they install it to anywhere other than the directory we expect them to install it to, because the polipo paths will be wrong. So why not assume just one more hard-coded path. :/

How does OS X TBB solve this? As Sebastian says, it needs to have its paths be relative to where you're running it from. Does OS X TBB still use a hard-coded polipo config file location?

The answer is that the paths specified in the vidalia.conf file are relative. So we should just make sure that the Tor built for the OS X TBB has a sharedir arg set during ./configure to point to the directory that we put the geoip file. Done.

(As a side note here, it means that on OS X, the Tor binary in the Vidalia bundle will differ from the Tor binary in the TBB. Steven was wondering earlier today (wrt Windows) why they would need to be different.

comment:12 in reply to:  11 ; Changed 8 years ago by Sebastian

Replying to arma:

Replying to arma:

Another cheap solution would be to build the tor binary that goes in the os x vidalia bundle with a hard-coded sharedir which is the place where we put geoip, polipo.conf, etc. That would solve the immediate problem.

I think this is the short-term hack that we should do. The OS X Vidalia bundle will already fail if they install it to anywhere other than the directory we expect them to install it to, because the polipo paths will be wrong. So why not assume just one more hard-coded path. :/

I believe this to be wrong for tbb (mac & linux) also. I believe we can't really fix it without the Vidalia fix.

How does OS X TBB solve this? As Sebastian says, it needs to have its paths be relative to where you're running it from. Does OS X TBB still use a hard-coded polipo config file location?

The answer is that the paths specified in the vidalia.conf file are relative. So we should just make sure that the Tor built for the OS X TBB has a sharedir arg set during ./configure to point to the directory that we put the geoip file. Done.

It's not that easy, that was my first thought. We can't pick relative paths:

configure: error: expected an absolute directory name for --datarootdir: test/bla

comment:13 Changed 8 years ago by Sebastian

Status: assignedneeds_review

so I grew tired of this bug and wrote a hack for Vidalia. Now it is possible to specify [Tor] GeoIpFile=path in vidalia.conf and Vidalia will use this path (if set) and pass it on to Tor when it starts up. I guess it might also be passed to Vidalia by commandline (if Vidalia supports that?) so that it can serve as a hack that works for tbb, too. Patch attached, I hope it's ok.

comment:14 Changed 8 years ago by arma

Shouldn't we be talking about sharedir, not geoipfile? After all, there are already two files we put in the sharedir (fallback-consensus being the other), and we might find a third at some point.

Then again, we don't actually ship a fallback-consensus file currently, and talking about geoipfile works without modifying Tor, so it's clearly the simpler hack.

But if we do it at the 'sharedir' level (i.e. letting Tor take in a torrc or command-line sharedir), does that let us relax our "<default>" hack inside Tor for the Windows side too?

comment:15 in reply to:  12 Changed 8 years ago by arma

Replying to Sebastian:

Replying to arma:

The answer is that the paths specified in the vidalia.conf file are relative. So we should just make sure that the Tor built for the OS X TBB has a sharedir arg set during ./configure to point to the directory that we put the geoip file. Done.

It's not that easy, that was my first thought. We can't pick relative paths:

configure: error: expected an absolute directory name for --datarootdir: test/bla

I suspect this is a Tor bug (well, lack of feature) that should get its own trac entry. I don't see any reason why our autoconf scripts should demand an absolute path here. (If there is a reason, it would be good to make it explicitly known to us.)

comment:16 Changed 8 years ago by nickm

I'm okay with giving Tor the ability to have some of its paths relative to other stuff. CWD is error-prone, but "the location of the Tor binary" and "home" and probably other stuff would be fine too.

comment:17 Changed 8 years ago by Sebastian

Ok. All of this sounds to me like we should do the Vidalia patch for now, because we're unlikely to have a fix for this in the 0.2.2.x timeframe in Tor. New version of the patch attached.

comment:18 Changed 8 years ago by erinn

Vidalia can't build with that patch:

[ 70%] Building CXX object src/vidalia/CMakeFiles/Vidalia.dir/config/TorSettings.o
/Users/hudson/osx-bundle/vidalia-0.2.10/src/vidalia/config/TorSettings.cpp: In member function ‘QString TorSettings::getGeoIPFile() const’:
/Users/hudson/osx-bundle/vidalia-0.2.10/src/vidalia/config/TorSettings.cpp:186: error: ‘SETTING_TOR_GEOIP_FILE’ was not declared in this scope
/Users/hudson/osx-bundle/vidalia-0.2.10/src/vidalia/config/TorSettings.cpp: In member function ‘void TorSettings::setGeoIPFile(const QString&)’:
/Users/hudson/osx-bundle/vidalia-0.2.10/src/vidalia/config/TorSettings.cpp:193: error: ‘SETTING_TOR_GEOIP_FILE’ was not declared in this scope
make[4]: *** [src/vidalia/CMakeFiles/Vidalia.dir/config/TorSettings.o] Error 1
make[3]: *** [src/vidalia/CMakeFiles/Vidalia.dir/all] Error 2
make[2]: *** [pkg/osx/CMakeFiles/dist-osx-bundle.dir/rule] Error 2
make[1]: *** [dist-osx-bundle] Error 2
make: *** [dist-osx-vidalia-bundle] Error 2

comment:19 Changed 8 years ago by Sebastian

bla I attached the wrong file :( Here's the next try

comment:20 Changed 8 years ago by Sebastian

Resolution: fixed
Status: needs_reviewclosed

So we're dropping the patch on the floor for now because that would be another broken update path for Vidalia users, which is not cool. Instead we did a hack to just put the geoip file in the path that Tor expects it in, and things will work. This means the bug is resolved, but we should still work on better Tor behaviour wrt paths and better Vidalia behaviour wrt configuration updates.

Note: See TracTickets for help on using tickets.