On 19/05/16 11:33, Jonas Oberg wrote:
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.
I'm not suggesting this would automatically become a formal agreement. Nonetheless, as the system-hackers are volunteers, it is actually really useful for them to specify just what they are volunteering to provide and where the limits are.
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:
If there is a gap between current configuration and desired configuration and if there is long-term benefit to FSFE, additional volunteers may step forward to help the system-hackers team migrate/adapt the systems. I would certainly volunteer to help on a temporary basis if I felt the final solution would be easier for system-hackers to support.
- 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.
Security is about the weakest link in the chain. If some updates are not deployed for a month, that can let everybody else down.
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.
That is understandable. Even so, as more people volunteer, it will become even more important for everything to be standardized.
- 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.
Not doing the major upgrade within 1 year of the release means you may stop getting security updates. For any public-facing service that should be a major concern. That is why I suggested putting some targets in place, although the exact upgrade dates could be varied from one service to the next, especially if they are isolated by virtualization.
- 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.
Maybe some of this could go into a wiki page about developing a service agreement? It can have some disclaimer at the top to say it is work in progress.
Regards,
Daniel