== 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
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.
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