Proposal 164: Reporting the status of server votes
nickm at torproject.org
Thu Jun 18 19:26:18 UTC 2009
On Sun, Jun 14, 2009 at 02:40:05AM -0400, Roger Dingledine wrote:
> On Fri, May 22, 2009 at 03:00:42AM -0400, Nick Mathewson wrote:
> > - 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.
> Mere mortals can't do this step either. It involves fetching a secret
> only-mentioned-in-the-spec URL ("/tor/status-vote/current/authority")
> from a set of secret only-mentioned-in-the-code IP addresses.
> > - 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.
> In practice, it's sufficient to ask an authority operator to go look
> through the "v3-status-votes" file in their datadir that gets written
> every voting period, and see what the recent votes have said about
> your relay.
> > 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.
> > * 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.
> How does the 'omitted' line differ from the 'rejected' line?
An omitted router is one that we know a descriptor for but don't want
to include in our vote (usually because it isn't running). A rejected
descriptor is one that we refused to even store when it was uploaded
> Also, this reminds me of a wishlist item that Robert Hogan had a while
> back. He wants to know how many Tors are configured to be relays, but
> fail their self-reachability checks, so don't even try to publish. If
> it's hundreds or thousands, that means we should work harder to help
> users learn that they're not helping out in the way they think they are.
Sounds like something that could use a proposal, yeah.
> > 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.
> Sounds like a fine plan. I agree that this would be a helpful feature
> to have. But it's also not upgrade-path-critical in the way that a lot
> of the other pending proposals are -- we could do it in 0.2.2 or 0.2.3
> or later and nothing else would have to change to accommodate.
> Also, it can be done pretty well by a) teaching users to read their logs,
> which they're already not so bad at if they're the sort of users who know
> how to realize that this vote-info stuff exists, and b) teaching sites
> like torstatus to fetch the secret URLs from the secret IP addresses and
> crunch the vote data that's already available. This proposal only really
> adds help for folks who can't find their logs, and folks who want to
> know why they're not marked Stable (answer: "you're not stable enough;
> oh, and bug 969").
We can maybe also add some controller features to substitute for (a)
with people who use guis.
> So: if you are itching to do it (or somebody else is), by all means go
> for it. But if it seems like a big pile of hassle (and some of the ideas
> above are pretty invasive and tricky to do efficiently), feel free to
> put it off indefinitely.
> Here's an alternative proposal: I set up a cron job on moria to copy
> moria1's v3-status-votes file to someplace web-accessible, and then we
> tell the torstatus folks that they can fetch it and parse it if they
> want to?
Sounds like a good start. It would be even better to keep a
(rolling?) backlog of status votes, so that we can look into questions
like "why is this server only listed in 1/3 consensuses?"
I think I'll decide that I agree with you on the relative non-urgency
of this, and put it off until somebody feels like doing it.
More information about the tor-dev