Hi,
a subset of the DSA team met last week in Paris for three days of work
and discussion. We covered a number of topics, from ongoing work to
plans for the next year or two, and review of our processes and pain
points.
We'd like to thank Mozilla for hosting us and Debian's sponsors for
covering travel and accommodation costs for the sprint.
Attendees: Aurélien Jarno, Héctor Orón Martínez, Julien Cristau,
Martin Zobel-Helas, Peter Palfrader, Tollef Fog Heen
== Team membership
It's been two years since the last update of DSA membership[DSADPL].
Of the delegated members, Stephen Gran is no longer active in the team.
We would like to thank him for his years of service and his great
contributions to shaping the team that we are, and we wish him the best
of luck in his current and future projects. We are working with the DPL
to update the delegation.
[DSADPL] https://lists.debian.org/debian-devel-announce/2016/05/msg6.html
== DebConf17 plan flashback
We reviewed items and plans we mentioned in our DebConf17 talk[DC17]
last year:
- integrating debconf.org services: in addition to DNS, static websites
and @debconf.org email, the mailing lists have now been moved to
lists.debian.org thanks to the DebConf team and listmasters. The
debconf18 website is being set up on Debian infrastructure from the
get go. Some of the websites (wiki, www, debconf8 to debconf15,
*.mini, ...), the git-annex service and maybe other things are still
running on DebConf infrastructure, we should figure out which of those
need to live on and work with existing DebConf admins on a migration
plan.
- Alioth transition: we're happy with the git/salsa progress, and the
continuation plan for lists. It looks like everything else will end
up going away.
- infrastructure refresh: We haven't made much progress on that front
since DebConf, though see below.
[DC17] https://debconf17.debconf.org/talks/11/
== Out of band management
We reviewed our plans to get out of band management devices in hosting
locations where we're lacking such capability. Since we drew up these
initial plans, the number of locations where we need serial console has
decreased, so most locations need a device with a few network ports and
VPN capability. We are planning on acquiring a number of such devices
in Europe and North America, either through donation or purchase. We
also agreed not to invest in OOB capability in locations where we only
maintain a single redundant mirror host.
== Core hardware refresh
We discussed hardware refresh plans for our locations in MAN-DA,
Bytemark and UTwente. We are discussing specifics with our hosting
partners and hardware providers/resellers.
We are thinking of moving away from blade centers and shared storage
towards individual rack-mount servers, and away from spinning rust
towards SSD. We also discussed the static.debian.org setup and whether
we could move that to a "caching proxy" setup, either by running our own
or relying on a partner CDN.
== security.debian.org
The traffic for security.debian.org currently peaks at around 25Gbps
globally for just the linux kernel in a single suite. The base load
(with nothing happening) is around 1 to 3Gbps (constantly. Yes.
Really). Our current mirrors cannot deal with that peak demand, so for
the last year and a half we have had to redirect some updates to the
security-cdn.debian.org service sponsored by Fastly[FASTLY].
We think it's time to make that permanent, and across the whole
security archive, so we will be:
- adding a SRV record for _http._tcp.security.debian.org pointing at the
Fastly service
- setting up a HTTP redirect on http://security.debian.org/
- setting up a separate rsync.security.debian.org name for folks who
want to keep mirroring that archive via rsync
- focusing on reliability of a couple of backends in Europe and the CDN
service so users get the quality level they expect from
security.debian.org
We also opted to end the BGP mirror experiment, as none of us can
currently drive that effort.
[FASTLY] https://www.fastly.com/open-source
== Service ownership
We would like to collect better information about which GIDs/teams are
responsible for services we host. The goal is that we would be
able to check with them every so often whether the service is still
relevant/needed. Also, it would enable us to more easily find the people
to talk to for for updating or changing hosts, and it would allow us
to more reliably identify hosts and services that can be shut down or that
have become unmaintained or unneeded.
In the same spirit, we would like to have users reaffirm their use of
and need for extra groups regularly.
== Architecture qualification
We reviewed the current candidate architectures for the upcoming buster
release, and their health from the DSA point of view. We have updated
the architecture qualification table[AQ] with current status (for the
porterbox, buildds, and DSA concern criteria).
In short, t
