[tor-bugs] #13125 [Tor]: Review the guardiness python script of #9321

[Tor Bug Tracker & Wiki]

#13125: Review the guardiness python script of #9321
------------------------+--------------------------------
     Reporter:  asn     |      Owner:
         Type:  defect  |     Status:  needs_review
     Priority:  normal  |  Milestone:  Tor: 0.2.7.x-final
    Component:  Tor     |    Version:
   Resolution:          |   Keywords:  tor-guard tor-auth
Actual Points:          |  Parent ID:  #9321
       Points:          |
------------------------+--------------------------------

Comment (by asn):

 Replying to [comment:9 Sebastian]:
 > Looks plausible, I could see myself trying it out. A couple of things:
 The cron script should never output a single thing in the case where no
 errors happened, but if an error happened it should always make sure that
 gets reported.

 Fixed that I think. Now it should be totally silent if everythin went
 well, but still cry if things went bad. I'm testing this right now on my
 system.

 > There probably wants to be a vacuum somewhere so the database file gets
 shrunk periodically.

 I didn't do this yet.

 > There should be a protection against parallel execution of the script,
 because that will happen eventually.

 Fixed with flock(1).

 > What is the deal with not importing a consensus if it isn't valid
 anymore? I don't understand the logic. The duplicate protection should
 prevent duplicates, so what's the issue?

 You are right. Now the date check happens only on guardfraction.py. The
 databaser script will just import whatever is found in the directory it
 was pointed to.

 > For the output format, I thought we had talked about giving a way to
 enumerate which consensuses were missing. Maybe that could at least be an
 optional command?

 Did this. It's now switch `-m` in guardfraction.py . Check it out!

 >Also, instead of
 > {{{
 > n-inputs <number of consesuses parsed> <number of months considered>
 > }}}
 >
 > maybe
 >
 > {{{
 > n-inputs <number of consensuses parsed> <number of all consensuses in
 voting period> <number of months considered>
 > }}}
 >
 > is more appropriate/easier to understand? Because otherwise "how many
 hours is a month" becomes an issue.
 >

 As discussed in IRC, I changed the period to be in days and not in months.
 This is much better. And I also output the ideal number of consensuses in
 the output file.

 > What happens with consensuses generated at the half-hour mark? Can they
 accidentally get added, and if they do, do they distort results?

 I think they can get added but they don't really distort results.

 They will definitely not be considered by the `list missing consensuses`
 functionality.

 Please check the new changes out!

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/13125#comment:10>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online