Changes between Initial Version and Version 1 of org/meetings/2019Stockholm/Notes/SysadminTeamRoadmapping

Jul 16, 2019, 9:11:31 AM (6 months ago)

add notes from the sysadmin team roadmapping session on day 1


  • org/meetings/2019Stockholm/Notes/SysadminTeamRoadmapping

    v1 v1  
     2== Brussels Items
     4We went over the Brussels items; we skipped many of the items already addressed.  What we touched on, in short:
     6  * host/account lifecycle: we still want that
     7  * trending/monitoring: still wip, but we have prometheus now.  It keeps data for a month.   We still want something that keeps data long-term, probably by sampling the primary prometheus from another prometheus server.  We also have a prom2 that is to monitor non-tpa things.
     8  * domain portfolio: we want to retire all the CC torproject.orgs.  We made some progress, but not complete yet.  ACTION: Linus to do t-shirt things for previous owners ACTION: weasel/anarcat to retire the domains from our nameservers (done during meeting)
     9  * reconcile service lists of wiki/ldap/dns.  not yet done, ACTION: anarcat to take that.
     10  * dedicated sudo passwords.  not yet flipped the switch, ACTION: anarcat to do that.  help GR set up sudo passwords, or exclude those hosts
     11  * loghost.  not yet done, ACTION: weasel to do it
     12  * DNS providers.  we have one, dnsnode, and it's nice.  we need more to migrate everything to 3rd party dns hosting.  ACTION: anarcat to ask greenhost Linus to scout
     13  * cymru hw: ACTION: explicitly not a sysadmin thing: Linus to punt to isa and/or Sue
     14  * search: hiro working on it, considering solr and python frontend, possibility of collaboration with tails people
     15  * cdn: tb downloads via cdn or direct?  ACTION: Linus to liaison with TB people
     16  * fastly: ACTION: Linus (with isa) check status on contract
     17  * media: train people other than hiro to add things to it
     18  * survey: maybe bring gus in?
     19  * nextcloud: eval still in progress
     21== email
     23  running mail for other people is hard, much harder than just running it for yourself and two or three friends/family.
     24  Therefore it's somewhat costly.  Whether or not Tor wants to pay for that is a question for leadership.
     26  Observation: if we offer outgoing SMTP to some, eventually everybody will have to use it or their email won't get accepted anymore.
     28== meetings
     30  We discussed how to make our monthly IRC meetings more efficient.  We have some ideas to try (like pre-prepared lists).
     31  We're happy with the current frequency (monthly) and format (IRC).
     33== sysadmin vs. service admin
     35  We end up with having to keep hosts and services running long after the initial people who wanted it left.
     36  We also run some things directly as torproject-admin.
     37  We should have some list of requirements for things we (and also others) run on our infra.
     38  This list would include that sw needs to have proper releases and installation instructions and procedures,
     39  a bug tracker, some means to contact upstream, and it needs to run in the lastest Debian stable (and when there is a new
     40  Debian stable, it needs to run on that within a month or three.)
     41  There needs to be some commitment of maintainership, not only by individuals but by the project/corp,
     42  meaning a promise of recurring money to keep this service working.  It's never just about setting up.
     43  We really really want at least two people who know and maintain each service.
     44  Also, this policy should apply not only to incoming services, but it should apply to all the things we run and we should regularly evaluate whether services meet them.
     46== issue tracking
     48  We have several channels for incoming requests: IRC, trac, email, and to some extend RT.
     49  Trac will go away eventually, probably replaced by gitlab.  anarcat would like to see email go away,
     50  at least all the root mail spam.  We agreed that at least all the root spam can be sent directly into RT to be mass deleted regularly.
     52== knowledge transfer
     54  Anarcat mentioned that there are different types of documentation: tutorials, howto, API/Reference, and design rationales.
     55  Documentation should be clear on what it wants to be. Anarcat is expanding documentation to make easier to onboard new sysadmins.
     56== budget & steering
     58  open issues include cdn vs. own mirrors for TB,
     59  cost of HW/VMs for services
     60  come up with standardized HW/VM models and services will have to pick one