Re: [tor-relays] uptime "algorithm"

[Nima Fatemi]

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...

-- 
Nima
0XC009DB191C92A77B | @mrphs

"I disapprove of what you say, but I will defend to the death your right
to say it" --Evelyn Beatrice Hall



signature.asc
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] uptime "algorithm"

[Green Dream]

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.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor Relay Operators Meetup at 32c3: 28.12. 16:45

[Sam Lanning]

This will be my first C3 and tor meetup! Looking forward to meeting
everyone there! =)

Sam.
On 12 Dec 2015 2:58 p.m., "Moritz Bartl"  wrote:

> As usual: Let's all gather at 32c3 to discuss Tor relay operation!
>
> Monday, 28.12.2015
> 16:45-18:45
> Hall 13
>
> https://events.ccc.de/congress/2015/wiki/Session:Tor_Relay_Operators_Meetup
>
> See you there!
> --
> Moritz Bartl
> https://www.torservers.net/
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Handling abuse request about stopforumspam.com

[Eran Sandler]

Hi guys,

One of my tor server seems to be getting a lot of abuse reports from the
ISP from stopforumspam.com.

http://www.stopforumspam.com/ipcheck/212.47.246.21

Any idea how to reduce those to a minimum in a reasonable way?

Thanks,
Eran
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] uptime "algorithm"

[Dr. Who]

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?
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] uptime "algorithm"

[Logforme]

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.

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] uptime "algorithm"

[Roger Dingledine]

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

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays