About functional requirement for Skolelinux in large installations Petter Reinholdtsen invited to a meeting at the developer-gathering the 28-30th of January 2005. The goal was to outline what to expect when operating 50, 150 or more servers with Skolelinux in huge centralised operations. We also gathered some feedback from other organisations that operate and maintain many servers. Definition: Centralised operation means that the people work from a central place. In The educational department in Oslo the definition is like this: Centralised operation with an ICT-solution is more than to remote operate single components manually. It is about automating routines for many tasks, not only the ones that are done by a local staff. But also configuration, maintaining, and surveillance of servers and services. Change must be done at a huge amount of components at once. And it must take in account that the network connection could restricted (and sometimes down). Centralised operation require a high level of integration between different components in the solution. The purpose with centralised operation is to eliminate the need for both local competence and the local workload. The work tasks is done by professional technicians that gives reduced risk for miss-configuration and failure because of human errors. Top knowledge people can work together, and in that way it's possible to get advantages that the whole operation can use the more expensive resources. In the same manner it's also advantages to centralise services on dedicated hardware. Centralised and locally placed servers The headline is self explaining, but it's important not to confuse this with the centralised operation term. There is useful mechanisms to remotely operate serves in a way that their placement is independent of where the staff actually works. Suggestions: - serial support auto setup (with login, GRUB and console) - VPN-solution as in Kongsvinger - Delegated operation of WLUS without root access (to prevent that a teacher does something else with Webmin that make changes behind the operators back). - Status reporting the appropriate services in NAGIOS with sane threshold values http://hovedprosjekter.hig.no/v2005/data/gr8_nettverk/ - Routines for upgrading and security patching of software. It can be done with apt-get, System imager etc. as they already doing at Ulsrud secondary school (and a lot of other places). Report system that it's updated, upgraded etc. - Scripts that reports that the right software is installed - Scripts that reports that expected services are starting after reboot, and that the right services are in place. - Scripts that report about the status for kernel upgrades - Large scale backup - Large scale tracking - Reporting RAID-status - Have to document the routines with ITIL (IT Infrastructure Library) - Use of centralised shells as dsh (already in Skolelinux) - Centralised user management with single sign-on (FEIDE/Cerebrum) - getfiled / logfiled - Reboot when idle - Different level of dividing functionality so it's a bit easier to reuse solutions in other Custom Debian Distributions. Make the service oriented architecture with a combination of single configured services that are hidden in the installer, and can be selected in expert mode when installing, and reconfigured after the system are installed (debconf-thing etc.). http://wiki.debian.net/index.cgi?CustomDebian By Knut Yrvin 1th of February 2005