A few days ago, George posted an invitation for obfsproxy operators to upgrade their Tor software to the latest version on the master branch in the Tor git repo. [1]
I'm running a low traffic obfsbridge on a raspberry pi, the whole thing is rather experimental in its nature already, so decided to try just that.
Presumably everyone for whom this might be relevant already knows these things much better than myself, but since they might be applicable to all/some Debian users (raspberrypi + raspbian/debian users for sure), i'm outlining a couple of snags that can maybe be avoided. Previously I ran 0.2.4.15-rc compiled from deb-src (http://deb.torproject.org/torproject.orgexperimental-wheezy main); I think it'd have been the same if a precompiled package had been used. I'd still like to be able to manage Tor via init scripts with as little change as possible, etc.
TL;DR:
- after make && make install, do a whereis tor; in all likelihood, your new version will be at /usr/local/bin/tor, old one at /usr/sbin/tor etc.; /etc/init.d/tor will be using /usr/sbin/tor, so need to change the DAEMON key there - torrc-defaults will have different values in different distro packages. cd /usr/local/etc/tor; if there's no torrc there: sudo ln -s /etc/tor/torrc (presumably that's where you kept your torrc before; ~/.torrc should work in any case)
$ git clone https://git.torproject.org/tor.git && cd tor $ ./autogen.sh if it complains about no aclocal (et al.): $ sudo apt-get install automake && ./autogen.sh $ ./configure $ make $ sudo make install # or, just use it like that (Tor binary is in src/or/)
If you're using service tor {start,stop,reload,etc}:
$ /usr/sbin/tor --version; /usr/local/bin/tor --version $ grep DAEMON= /etc/init.d/tor
The latter will likely point to /usr/sbin/tor, which might be outdated (check above). If that's the case, change that line in init.d/tor to point to the new Tor executable /usr/local/bin/tor - that's where it *should* be; if you don't like that, change BINDIR = /usr/local/bin in Tor's Makefile and make install again.
The Debian Tor packages seem to like to assume torrc will be placed in /etc/tor/torrc. If that's where your torrc resides, make a symlink to it from /usr/local/etc/tor, which is where the new Tor executable will look for it.
This is probably an insanely ugly way of dealing with these snags, but if anyone is reserved to upgrade because of things like that, maybe this'll help someone..
Kostas.
[1]: https://lists.torproject.org/pipermail/tor-relays/2013-August/002477.html
On Tue, 20 Aug 2013, Kostas Jakeliunas wrote:
Presumably everyone for whom this might be relevant already knows these things much better than myself, but since they might be applicable to all/some Debian users (raspberrypi + raspbian/debian users for sure), i'm outlining a couple of snags that can maybe be avoided. Previously I ran 0.2.4.15-rc compiled from deb-src (http://deb.torproject.org/torproject.orgexperimental-wheezy main); I think it'd have been the same if a precompiled package had been used. I'd still like to be able to manage Tor via init scripts with as little change as possible, etc.
- after make && make install, do a whereis tor; in all likelihood, your
Maybe you should build .deb package from these sources? https://www.torproject.org/docs/debian#source
On Wed, Aug 21, 2013 at 10:35 AM, Peter Palfrader weasel@torproject.orgwrote:
Maybe you should build .deb package from these sources? https://www.torproject.org/docs/debian#source
Ah! debuild && dpkg -i. Yes, that's the cleaner way to do it for sure, thanks. There's no reason why this shouldn't work with the latest branch, I guess.
tor-relays@lists.torproject.org