As far as understand it is the flag HSdir given to nodes with a fast enough connection and a long enough uptime.
If I keep my tor relay version always up to the current stable version I sometimes do have to restart the process. So I get a drop in my uptime and loose the HSdir flag for several days. Other nodes who don't care about versions keep the flag, despite the fact they might use older/inefficient/insecure/buggy versions.
Wouldn't it be better to monitor the reason for a drop in uptime? In case at the same time a restart occurs the version increases it might be given the HSdir flag again?
someone understands what I mean?
On 2015-12-14 19:12, Dr. Who wrote:
Wouldn't it be better to monitor the reason for a drop in uptime? In case at the same time a restart occurs the version increases it might be given the HSdir flag again?
Can't see why, for example the Debian /etc/init.d/tor script, couldn't send tor a flag telling it that this is a restart, causing tor to save/restore its uptime information. Circuits auto-reconnect if the downtime is short enough, right?
restart) check_config
$0 stop -saveuptimeinfo $UPTIMEFILE sleep 1 $0 start -restoreuptimeinfo $UPTIMEFILE
Not losing my flags would at least make me upgrade tor more frequently.
On Mon, Dec 14, 2015 at 08:14:12PM +0100, Logforme wrote:
Can't see why, for example the Debian /etc/init.d/tor script, couldn't send tor a flag telling it that this is a restart, causing tor to save/restore its uptime information.
Yes, this would be possible.
Circuits auto-reconnect if the downtime is short enough, right?
No, Tor has a bunch of session key stuff in memory that goes away when it exits (which is a feature).
Not losing my flags would at least make me upgrade tor more frequently.
We should somehow teach everybody that losing their flags for a few days is totally fine and normal, and even something to be proud of because you took a useful step at keeping your Tor relay safe and secure and supporting the latest features. I recognize that complexifies the gamification. :)
--Roger
I'm not sure why operators care so much about the HSDir flag. It naturally comes and goes. Try not worry about it. :)
I've noticed that it can take 30+ minutes after a version upgrade before the directory service on my nodes is fully responsive again [1]. I'm not entirely sure what's happening in this timeframe, but it might be a good reason not to leave the HSDir flag in place.
----
1) To monitor the health of my relays I periodically query the directory service via a GET request to a URI. For example:
http://197.231.221.211:1080/tor/server/authority
(That's not my relay. I picked a top relay from Globe).
The monitoring software looks for a 200 response and validates the fingerprint.
After the upgrade to 0.2.7.6 all my relays returned a 404 on that URI for at least 30 minutes.
Roger Dingledine:
We should somehow teach everybody that losing their flags for a few days is totally fine and normal, and even something to be proud of because you took a useful step at keeping your Tor relay safe and secure
Maybe we should introduce a new flag for the relays that are running the cutting edge version of Tor?
And another one for long-time relays. say, if a relay has been in the consensus, it would get an special flag of some sort...
On 15 Dec 2015, at 13:12, Nima Fatemi nima@riseup.net wrote:
Roger Dingledine:
We should somehow teach everybody that losing their flags for a few days is totally fine and normal, and even something to be proud of because you took a useful step at keeping your Tor relay safe and secure
Maybe we should introduce a new flag for the relays that are running the cutting edge version of Tor?
There's a startup warning for this: it says your relay version is "too new".
And another one for long-time relays. say, if a relay has been in the consensus, it would get an special flag of some sort…
At some point, we'd like to make long-term relays fallback directory mirrors. That's not a flag, but it is a special kind of status.
Also, isn't this the kind of thing that tor-roster does? I think these kinds of features would be better there, rather than cluttering up the consensus.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
tor-relays@lists.torproject.org
-
Dr. Who -
Green Dream -
Logforme -
Nima Fatemi -
Roger Dingledine -
Tim Wilson-Brown - teor