Re: [tor-talk] Consensus Health Checker Check

[Karsten Loesing <karsten@xxxxxxxxxxxxxx>]

I *think* you meant to reply to tor-talk@, not just to me, so including
the list again.


On 7/6/13 12:05 PM, Sebastian G. <bastik.tor> wrote:
> 06.07.2013 11:21, schrieb Karsten Loesing:
>> On 7/6/13 9:47 AM, Sebastian G. <bastik.tor> wrote:
>>> Hi,
>>>
>>> How do I know that the Consensus Health Checker checked a consensus?
>>> (How do I check the Consensus Health Checker?)
>>>
>>> Background:
>>> I get emails like
>>> 'WARNING: $warning_text $authority1' for the consensuses 00:00, 01:00,
>>> 03:00, 04:00, 07:00 (pulled out of my head)
>>>
>>> Since I got no mails for 02:00, 05:00 and 06:00, the warning does not
>>> seem to have occurred then, while it *could* be the case that it did
>>> occur but the checker did not check. Dannenberg made me think that this
>>> could be the case since, according to Atlas, powered by data from
>>> Onionoo, it was not running and would be unable to respond to requests.
>>>
>>> Supposed the checker worked and there won't be any problem with the
>>> consensus for, let's say, a month.... How to see if there's actually no
>>> problem with the consensus(es) or if the checker is down? (How to check
>>> the checker?)
>>
>> The consensus-health checker rate-limits warnings to reduce the noise.
> 
> OK.
> 
>> Ideally, I'd want to reduce volume of consensus-health messages even
>> more, for example, using #9103.
> 
> Alright.
> 
>> So, the idea behind consensus-health messages is to get a notification
>> of *current* problems, not at all to investigate problems in the *past*.
> 
> The above answers are so short, because of a misunderstanding what
> consensus health notifications are there for.

These notifications are mostly meant for directory authority operators
to notice when they should look at their directory authorities and fix
them.  Of course, it's perfectly fine for others to watch notifications
to learn about problems with the consensus process.

>>  You'll want to use Atlas or relay-search or the descriptor archives for
>> that.
> 
> Depending on the use-case either method seems appropriate.
> 
> 
>> So, how to check the checker?  Fine question!  One solution might be to
>> run a second checker.  Want to do that and report problems that the
>> first checker overlooked?
> 
> I don't think it would spot anything additional problems.

Well, we rely a lot on yatei.  I wouldn't mind knowing that there's
another machine and person paying attention to the consensus process.

>> In theory,
> 
> In theory. :)
> 
>> setting up DocTor is easy:
>>
>> https://gitweb.torproject.org/doctor.git/blob/HEAD:/README
> 
> Thanks.
> 
> My system is not up 24/7, otherwise a VM with Java would be reasonable.
> 
> Some other host contributing to the network is up 24/7 but lacks Java,
> and running Java and something else like DocTor might make it react
> slower to my input than it does already.
> 
> In the case I change the type of contribution DocTor would mostly likely
> need to disappear anyway.
> 
> At the current point I don't consider it.

Okay.  If you reconsider and need help setting it up, let me know.

Best,
Karsten


> Thank you again for your input.
> 
>> Best,
>> Karsten
> 
> Best,
> Sebastian (aka bastik)
> 
> 

_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk