mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-09-21 13:34:59 +02:00
92 lines
2.8 KiB
Plaintext
92 lines
2.8 KiB
Plaintext
|
Filename: 164-reporting-server-status.txt
|
||
|
|
Title: Reporting the status of server votes
|
||
|
|
Author: Nick Mathewson
|
||
|
|
Created: 22-May-2009
|
||
|
|
Target: 0.2.2
|
||
|
|
Status: Open
|
||
|
|
|
||
|
|
|
||
|
|
Overview:
|
||
|
|
|
||
|
|
When a given node isn't listed in the directory, it isn't always easy
|
||
|
|
to tell why. This proposal suggest a quick-and-dirty way for
|
||
|
|
authorities to export not only how they voted, but why, and a way to
|
||
|
|
collate the information.
|
||
|
|
|
||
|
|
Motivation:
|
||
|
|
|
||
|
|
Right now, if you want to know the reason why your server was listed
|
||
|
|
a certain way in the Tor directory, the following steps are
|
||
|
|
recommended:
|
||
|
|
|
||
|
|
- Look through your log for reports of what the authority said
|
||
|
|
when you tried to upload.
|
||
|
|
|
||
|
|
- Look at the consensus; see if you're listed.
|
||
|
|
|
||
|
|
- Wait a while, see if things get better.
|
||
|
|
|
||
|
|
- Download the votes from all the authorities, and see how they
|
||
|
|
voted. Try to figure out why.
|
||
|
|
|
||
|
|
- If you think they'll listen to you, ask some authority
|
||
|
|
operators to look you up in their mtbf files and logs to see
|
||
|
|
why they voted as they did.
|
||
|
|
|
||
|
|
This is far too hard.
|
||
|
|
|
||
|
|
Solution:
|
||
|
|
|
||
|
|
We should add a new vote-like information-only document that
|
||
|
|
authorities serve on request. Call it a "vote info". It is
|
||
|
|
generated at the same time as a vote, but used only for
|
||
|
|
determining why a server voted as it did. It is served from
|
||
|
|
/tor/status-vote-info/current/authority[.z]
|
||
|
|
|
||
|
|
It differs from a vote in that:
|
||
|
|
|
||
|
|
* Its vote-status field is 'vote-info'.
|
||
|
|
|
||
|
|
* It includes routers that the authority would not include
|
||
|
|
in its vote.
|
||
|
|
|
||
|
|
For these, it includes an "omitted" line with an English
|
||
|
|
message explaining why they were omitted.
|
||
|
|
|
||
|
|
* For each router, it includes a line describing its WFU and
|
||
|
|
MTBF. The format is:
|
||
|
|
|
||
|
|
"stability <mtbf> up-since='date'"
|
||
|
|
"uptime <wfu> down-since='date'"
|
||
|
|
|
||
|
|
* It describes the WFU and MTBF thresholds it requires to
|
||
|
|
vote for a given router in various roles in the header.
|
||
|
|
The format is:
|
||
|
|
|
||
|
|
"flag-requirement <flag-name> <field> <op> <value>"
|
||
|
|
|
||
|
|
e.g.
|
||
|
|
|
||
|
|
"flag-requirement Guard uptime > 80"
|
||
|
|
|
||
|
|
* It includes info on routers all of whose descriptors that
|
||
|
|
were uploaded but rejected over the past few hours. The
|
||
|
|
"r" lines for these are the same as for regular routers.
|
||
|
|
The other lines are omitted for these routers, and are
|
||
|
|
replaced with a single "rejected" line, explaining (in
|
||
|
|
English) why the router was rejected.
|
||
|
|
|
||
|
|
|
||
|
|
A status site (like Torweather or Torstatus or another
|
||
|
|
tool) can poll these files when they are generated, collate
|
||
|
|
the data, and make it available to server operators.
|
||
|
|
|
||
|
|
Risks:
|
||
|
|
|
||
|
|
This document makes no provisions for caching these "vote
|
||
|
|
info" documents. If many people wind up fetching them
|
||
|
|
aggressively from the authorities, that would be bad.
|
||
|
|
|
||
|
|
|
||
|
|
|