system-hackers service agreement

[Jonas Oberg]

Hi Daniel,

> Maybe there are other things too, it would be good to see the
> system-hackers provide a list of what you would be willing to support
> and a separate list of what people think they need the system-hackers to
> support.

I imagine this will build over time and with experience. At the
moment, we're talking about one volunteer team (blog-hackers) and two
volunteer system administrators (system-hackers), and I would propose
to give some room to be flexible in the arrangements here before we
establish any formal procedures.

Ignoring the current configuration of the systems is not easily done
as it somehow rests on the idea that our two volunteer system
administrators would have the resources available to build something
new, different from the current configuration. This is not the case
and I worry that conducting such an excersise will be difficult on
both sides: it will raise the expectations from the other volunteer
teams, and it will be frustrating for the system administrators who
may not be able to deliver.

I would leave each team some time to work now before developing
things further. So as to the current state of things:

> - which OS/distribution?  E.g. Debian

Debian 8

> - will services run in virtual machines

Services run in isolated VMs on a Proxmox cluster. There is no lack of
IPv4 addresses to support this at the moment, but all new VMs have
IPv6 connectivity as well.

> - how fast can packaged security updates (e.g. from Debian) be deployed?

This is a best effort deployment. The individual teams can deploy
security packages quickly if they would like to, but otherwise it will
be anything from 1 hour to 1 month, completely dependant upon the
severity of the security update and the available time.

> In the latter case, are more volunteers needed in the system-hackers team?

As you may imagine, we do indeed need more volunteer also in the
system hackers team. I'm not "recruiting" for this at the moment
though, as giving someone this access also means giving them access to
a lot of (potentially) confidential and private information. The way I
see this is that the service level volunteer teams will be the future
recruitment ground for system-hackers.

> - how will major upgrades (e.g. from Debian 8.0 to 9.0) be deployed?

Again, this is best effort. Typically, at the moment, we do not do any
major upgrades unless changing the service at the same time.

> - which services must be supported by the system-hackers (I'd suggest
> backups, public web site, wiki, IP address allocation, SSL certificate
> creation, monitoring, Git, DNS, authentication/OpenID/LDAP, mail,
> mailing lists, SIP, XMPP and any services that the system-hackers may
> depend on in the course of their own activities)

At the moment, all services which are not explicitly delegated to any
other volunteer team.

> - are the system-hackers willing to support a database such as
> PostgreSQL for use by other teams?  Can they provide a convenient way
> for members of other teams to take snapshots of their databases for use
> in test servers?

No.

> - will the system-hackers allow members of other teams to use sudo?

Yes.

-- 
Jonas Öberg, Executive Director
Free Software Foundation Europe | jonas at fsfe.org
Your donation enables our work (fsfe.org/donate)