From: Luca Filipozzi To: Debian Project Subject: Report from DSA Sprint in Oslo Comrades! We just finished a very productive Debian System Administration team sprint in Oslo, Norway. Five of the six current DSA members were present. We would like to thank Varnish Software for hosting us and providing food and drink. In addition our thanks go to all who donated to Debian in the past that allowed the project to cover transportation and lodging. The goals of the meeting was to develop a long term plan for Debian's infrastructure, to review the current set of machines and services we provide and to formulate some policies and procedures around how we do account management. In addition we took the opportunity to coordinate issues which have been outstanding for a long time. This was the first time some of us met in person. Hardware ======== Historically, Debian got a large amount of its hardware sponsored, one machine at a time, and hosted all over the globe. At times we had hardware at more than 50 different hosting facilities. In recent years, we already have started cutting down on diversity to some degree, concentrating on a smaller number of locations that host more of our infrastructure. A lot of our existing machines are now very old and long out of warranty. They are sometimes quite constrained and/or starting to fail. We have developed a Five Year Plan[1] whereby all service-hosting hardware should be under warranty at any given time. As part of this, we are planning a five year refresh cycle and the goal is then for no hardware to be more than five years old. Please note that we are only talking about hardware hosting services such as ftp-master, lists, wiki and so on and not buildds and porter boxes. The DPL has asked to make a plan for those as well, but that is not currently part of the five year plan. [1]: http://en.wikipedia.org/wiki/Five-Year_Plans_for_the_National_Economy_of_the_Soviet_Union Virtualisation has come of age and we want to move most services into virtual machines, thus reducing the overall amount of physical machines. VMs are easier to move between physical hosts and give us service separation without too much administrative or computational overhead. Another advantage of virtualisation is it makes it easy to increase the availability of services. However, there are services that will need dedicated hardware due to resource requirements and as such we will not be able to move everything into VMs. Therefore, we will consolidate our hosting to 3-5 locations, where we want to have all service-hosting hardware. Some services have specific requirements as to where they are hosted and we will of course consider such requirements when making any plans or decisions. For instance ftp-master currently needs to be hosted in the US. An ongoing concern for DSA is our ability to source hardware for our various architectures. We want to work with the various teams to identify the commercial sources for hardware and also to work with those to define the supportability of the various architectures. This is not about XXX killing XXX any particular architectures, but to ensure that we, as a project can support the architectures we have committed to. Hardware has now become one of the biggest expense categories. In the past, we had more donations of physical hardware while today donations are more often given in the form of money. [XXX: improve this.] We would like to give more visibility to our hardware and hosting sponsors. We need to revamp our sponsorship and donations pages and would like to both have targetted campaigns toward parti*cular goals (either yearly or a particular piece of infrastructure) as well as something like the FreeBSD foundation's sponsorship page[2]. It might be a concern to make this not compete with the sponsorship of Debconf. [2]: http://freebsdfoundation.org/donate/sponsors.shtml Service changes =============== There are quite a few services which essentially provide static content, but which are currently not mirrored or mirrored on its own special mirror network. Examples include planet and www.d.o. We would like to consolidate this into what is essentially a Debian CDN where we have one central host those service push to and which is then replicated to a set of mirror nodes arount the world. The main archive is not going to be part of this mirror network. We have been working on deploying a web-based single-sign-on (SSO) solution. This will allow all users in the Debian LDAP to authenticate to various web services using a single password. It is already used by nm.debian.org and we are working with other teams to enable SSO for their respective services. There are still some technical issues outstanding as well as a lack of documentation. If you run a service which could benefit from this, please get in touch. Authorisation is currently out of scope for the SSO service and needs to be provided be service in question. It is not out of the question to extend this service to other authentication providers such as alioth in the future. All debian.org machines are backed up using a venerable solution called da-backup. It has certain limitations such as a lack of bare metal recovery and we have therefore decided to switch to bacula. XXX: change: Accounts & Security =================== debian.org has, approximately 50 000 shell accounts[3]. We believe most of those are unused and would therefore like to lock them. The goal is to reduce the exposure and not to take away any privileges. We will extend ud-ldap to easily (GPG-signed email) and quickly (< 2 minutes) allow users to re-enable their shell access. We will also monitor which accounts are active (think global lastlog) and only disable accounts which have been unused for a significant amount of time (months). We will keep you posted on our progress. [3] sum of accounts across all debian.org hosts. There is currently no mechanism which ensures that people only have the group memberships which they are using. We would like to implement a system where people have to regularly confirm their group memberships. The reason for this is, like the last paragraph, to reduce our exposure, not to take away anybody's privileges.