|
|
|
|
|
== Brussels Items
|
|
|
|
|
|
We went over the Brussels items; we skipped many of the items already addressed. What we touched on, in short:
|
|
|
|
|
|
* host/account lifecycle: we still want that
|
|
|
* 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.
|
|
|
* 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)
|
|
|
* reconcile service lists of wiki/ldap/dns. not yet done, ACTION: anarcat to take that.
|
|
|
* dedicated sudo passwords. not yet flipped the switch, ACTION: anarcat to do that. help GR set up sudo passwords, or exclude those hosts
|
|
|
* loghost. not yet done, ACTION: weasel to do it
|
|
|
* 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
|
|
|
* cymru hw: ACTION: explicitly not a sysadmin thing: Linus to punt to isa and/or Sue
|
|
|
* search: hiro working on it, considering solr and python frontend, possibility of collaboration with tails people
|
|
|
* cdn: tb downloads via cdn or direct? ACTION: Linus to liaison with TB people
|
|
|
* fastly: ACTION: Linus (with isa) check status on contract
|
|
|
* media: train people other than hiro to add things to it
|
|
|
* survey: maybe bring gus in?
|
|
|
* nextcloud: eval still in progress
|
|
|
|
|
|
== email
|
|
|
|
|
|
running mail for other people is hard, much harder than just running it for yourself and two or three friends/family.
|
|
|
Therefore it's somewhat costly. Whether or not Tor wants to pay for that is a question for leadership.
|
|
|
|
|
|
Observation: if we offer outgoing SMTP to some, eventually everybody will have to use it or their email won't get accepted anymore.
|
|
|
|
|
|
== meetings
|
|
|
|
|
|
We discussed how to make our monthly IRC meetings more efficient. We have some ideas to try (like pre-prepared lists).
|
|
|
We're happy with the current frequency (monthly) and format (IRC).
|
|
|
|
|
|
== sysadmin vs. service admin
|
|
|
|
|
|
We end up with having to keep hosts and services running long after the initial people who wanted it left.
|
|
|
We also run some things directly as torproject-admin.
|
|
|
We should have some list of requirements for things we (and also others) run on our infra.
|
|
|
This list would include that sw needs to have proper releases and installation instructions and procedures,
|
|
|
a bug tracker, some means to contact upstream, and it needs to run in the lastest Debian stable (and when there is a new
|
|
|
Debian stable, it needs to run on that within a month or three.)
|
|
|
There needs to be some commitment of maintainership, not only by individuals but by the project/corp,
|
|
|
meaning a promise of recurring money to keep this service working. It's never just about setting up.
|
|
|
We really really want at least two people who know and maintain each service.
|
|
|
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.
|
|
|
|
|
|
== issue tracking
|
|
|
|
|
|
We have several channels for incoming requests: IRC, trac, email, and to some extend RT.
|
|
|
Trac will go away eventually, probably replaced by gitlab. anarcat would like to see email go away,
|
|
|
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.
|
|
|
|
|
|
== knowledge transfer
|
|
|
|
|
|
Anarcat mentioned that there are different types of documentation: tutorials, howto, API/Reference, and design rationales.
|
|
|
Documentation should be clear on what it wants to be. Anarcat is expanding documentation to make easier to onboard new sysadmins.
|
|
|
== budget & steering
|
|
|
|
|
|
open issues include cdn vs. own mirrors for TB,
|
|
|
cost of HW/VMs for services
|
|
|
come up with standardized HW/VM models and services will have to pick one |