system-hackers service agreement

[Daniel Pocock]

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