Currently running Debian's stable/wheezy version of tor which 0.2.3.25 on my first relay, gracemissionstor.
I discovered the torproject deb repository here (of course): https://www.torproject.org/docs/debian
The following google search: debian upgrade site:torproject.org didn't give much.
But the following search: "tor relay" upgrade site:torproject.org gave: https://blog.torproject.org/blog/lifecycle-of-a-new-relay
and the FAQ which includes: https://www.torproject.org/docs/faq.html.en#UpgradeOrMove which relates how to keep the same relay id when upgrading.
Is there a recommended procedure for upgrading tor relay?
Should I upgrade asap now that I've realised torproject has more recent (0.2.4) stable version of tor?
Or should I just wait until I have to reboot the server (don't know when that could be) or until a security alert comes around from tor developers?
Perhaps I should just rely on the debian package to do the right thing regardless (which for most services is to restart the service, but I guess could be 'do nothing until next reboot' if the packager decided that was wise).
Seeking some guidance on this issue thanks, Zenaan
You should probably use the Tor project's package repository.
See this page for details: https://www.torproject.org/docs/debian.html.en#ubuntu
Best regards, Alexander --- PGP Key: 0xC55A356B | https://dietrich.cx/pgp
On 2014-03-18 13:57, Zenaan Harkness wrote:
Currently running Debian's stable/wheezy version of tor which 0.2.3.25 on my first relay, gracemissionstor.
I discovered the torproject deb repository here (of course): https://www.torproject.org/docs/debian
The following google search: debian upgrade site:torproject.org didn't give much.
But the following search: "tor relay" upgrade site:torproject.org gave: https://blog.torproject.org/blog/lifecycle-of-a-new-relay
and the FAQ which includes: https://www.torproject.org/docs/faq.html.en#UpgradeOrMove which relates how to keep the same relay id when upgrading.
Is there a recommended procedure for upgrading tor relay?
Should I upgrade asap now that I've realised torproject has more recent (0.2.4) stable version of tor?
Or should I just wait until I have to reboot the server (don't know when that could be) or until a security alert comes around from tor developers?
Perhaps I should just rely on the debian package to do the right thing regardless (which for most services is to restart the service, but I guess could be 'do nothing until next reboot' if the packager decided that was wise).
Seeking some guidance on this issue thanks, Zenaan _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Hi Zenaan,
You should add the torproject repository, and then just let it upgrade whenever there is a new version. There's no need to reboot or wait, having the upgrade process restart the service is fine. Your relay will not lose its flags during short downtimes like that.
On 3/19/14, Moritz Bartl moritz@torservers.net wrote:
You should add the torproject repository, and then just let it upgrade whenever there is a new version. There's no need to reboot or wait, having the upgrade process restart the service is fine. Your relay will not lose its flags during short downtimes like that.
Thank you, I did that.
The Debian install script evidently gives tor 30 seconds to disconnect, since it did stop tor after 30 seconds.
Then it went through the normal upgrade process, I kept my existing config file and voi la - tor was no longer running! This bit does not seem quite optimal - surely tor ought to have been auto restarted.
Anyway a quick service tor restart started it again and yes, flags intact.
HOWEVER: killing tor in 30 seconds seems to me a little harsh on all those anonymous connections that were previously going through my exit relay. Can those clients (if they need) pick up their connections after about 3 minutes? It appeared that all connections were completely gone when I finally got tor restarted, which makes sense but:
Is there are a gentler way such as "don't take new connections, notify clients we are going down for an upgrade" but allow continuation for say up to 10 or 30 minutes?
Would that be better or could that be worse eg for privacy, correlation attacks etc?
Thanks again, Zenaan
On 3/19/14, Zenaan Harkness zen@freedbms.net wrote:
On 3/19/14, Moritz Bartl moritz@torservers.net wrote:
You should add the torproject repository, and then just let it upgrade whenever there is a new version. There's no need to reboot or wait, having the upgrade process restart the service is fine. Your relay will not lose its flags during short downtimes like that.
Anyway a quick service tor restart started it again and yes, flags intact.
Correction: HSDIR flag disappeared - was there straight away, but has since disappeared. I know it comes back in a day. Just wanted to clarify for the record.
Thanks Zenaan
On 3/19/14, Zenaan Harkness zen@freedbms.net wrote:
On 3/19/14, Moritz Bartl moritz@torservers.net wrote:
You should add the torproject repository, and then just let it upgrade whenever there is a new version. There's no need to reboot or wait, having the upgrade process restart the service is fine. Your relay will not lose its flags during short downtimes like that.
Thank you, I did that.
The Debian install script evidently gives tor 30 seconds to disconnect, since it did stop tor after 30 seconds.
Then it went through the normal upgrade process, I kept my existing config file and voi la - tor was no longer running! This bit does not seem quite optimal - surely tor ought to have been auto restarted.
Anyway a quick service tor restart started it again and yes, flags intact.
HOWEVER: killing tor in 30 seconds seems to me a little harsh on all those anonymous connections that were previously going through my exit relay. Can those clients (if they need) pick up their connections after about 3 minutes? It appeared that all connections were completely gone when I finally got tor restarted, which makes sense but:
Is there are a gentler way such as "don't take new connections, notify clients we are going down for an upgrade" but allow continuation for say up to 10 or 30 minutes?
There is of course MaxAdvertisedBandwidth - so ought this option be set to say zero for say 10 or 20 minutes, before stopping/upgrading the server (either manually by admin, me, or assuming admin config allows this)?
Would that be better or could that be worse eg for privacy, correlation attacks etc?
Should I forward this question (or rather, create a thread) "optimal tor relay upgrade protocol" on tor-talk?
TIA Zenaan
On Sun, Mar 30, 2014 at 11:21:02AM +1100, Zenaan Harkness wrote:
The Debian install script evidently gives tor 30 seconds to disconnect, since it did stop tor after 30 seconds.
This is actually Tor's behavior. From the man page:
ShutdownWaitLength NUM When we get a SIGINT and we're a server, we begin shutting down: we close listeners and start refusing new circuits. After NUM seconds, we exit. If we get a second SIGINT, we exit immediately. (Default: 30 seconds)
But you're right that the Debian init script has a bound on the time it will let Tor sit around before it gives up and declares that it has failed to do what you asked. See: WAITFORDAEMON=60 in /etc/init.d/tor
HOWEVER: killing tor in 30 seconds seems to me a little harsh on all those anonymous connections that were previously going through my exit relay. Can those clients (if they need) pick up their connections after about 3 minutes? It appeared that all connections were completely gone when I finally got tor restarted
As soon as your relay goes away the circuits will be cut, and the streams that clients had on those circuits will be cut too. Whether those clients will automatically reconnect those streams on new circuits depends on the application.
Is there are a gentler way such as "don't take new connections, notify clients we are going down for an upgrade" but allow continuation for say up to 10 or 30 minutes?
You could set ShutdownWaitLength to something much larger. You'd want to either do a controlled shutdown of Tor on your own, or modify the init script so it knows you raised the value of ShutdownWaitLength.
There is of course MaxAdvertisedBandwidth - so ought this option be set to say zero for say 10 or 20 minutes, before stopping/upgrading the server (either manually by admin, me, or assuming admin config allows this)?
No, a change to the advertised bandwidth of your relay will take hours to propagate to clients.
Would that be better or could that be worse eg for privacy, correlation attacks etc?
Should I forward this question (or rather, create a thread) "optimal tor relay upgrade protocol" on tor-talk?
This list is the better choice.
--Roger
HOWEVER: killing tor in 30 seconds seems to me a little harsh on all those anonymous connections that were previously going through my exit relay. Can those clients (if they need) pick up their connections after about 3 minutes? It appeared that all connections were completely gone when I finally got tor restarted
As soon as your relay goes away the circuits will be cut, and the streams that clients had on those circuits will be cut too. Whether those clients will automatically reconnect those streams on new circuits depends on the application.
Is there some longer term sense in having a SOCKS protocol enhancement to have the SOCKS/TOR server notify applications connecting through it, that it intends to shutdown the relay/socks facility at X minutes into the future?
In the tor relays itself, this would of course need some TOR control channel or protocol where the 'relay reboot in X minutes' gets propagated back to the end users of the channels through this relay/ exit node.
Although 'reconnect' is robust enough, prima facie, a little more niceness for the users would be a good thing, I'd think.
tor-relays@lists.torproject.org
-
Alexander Dietrich -
Moritz Bartl -
Roger Dingledine -
Zenaan Harkness