This document is a result of talking to Jonas Smedegaard and Petter Renholdtsen about upgradring a Custom Debian Distributions (CDD) to a new version og Debian. I have based this on the issues that occurs when upgrading from Skolelinux based on Woody to the new one based on Sarge. It would be nice if this document could be regarded as an input to the developer gathering with CDD-developers in Spain next weekend (5-6th of May 2005). Any suggestions of wrong interpretation of what I'me told from my side, coorections and improvements could be committed directly to this document in the Skolelinux CVS, or I'll put it in for you: http://developer.skolelinux.no/artikler/2005-04-30-cdd-sarge.txt The next level of Custom Debian Distributions By Knut Yrvin April 30th 2005 * What we had to do Our goal -- Making a service oriented architecture ready for centralised management http://developer.skolelinux.no/arkitektur/arkitektur.html.en -- Making a collection of enduser applications suited for the schools. The applications shall be in our native language with support for the foreign languages that are taught in our schools. -- Everything should be easily installed and maintained http://developer.skolelinux.no/dokumentasjon/newdriftbok/newdriftbok.html.en -- Reuse of computers and code to support the interest for young people to inspect and learn about computer programs. In Norway it is an governmental initiative where different public offices collect reused computers, and sell them to schools for a small fee. 133 MHz processor, 32 MB RAM and 10 Mbit network card was that minimum requirement for a reused computer in the national specification from October 24th in 2001. The autumn 2003 the requirement was changed to minimum 200-266 MHz, 64 MB RAM and a 10/100 Mbit network card. Machines with 133 to 600 MHz processor is excellent as real thin client connected to the computer power provided by a server. Get rid of the harddrive, and use network card with PXE, and you have reduced power consumption, and doubled the lifetime to the client computer. You can use computers with > 450 MHz and 128 MB RAM as half thick client. Then you can reduce the computing power at the server, and run important applications on the client CPU. http://developer.skolelinux.no/driftskonsepter/2004-09-06-thin-clients.html The idea behind Skolelinux is to reduce the time with setup and maintenance with centralising as much as possible. We want to do that without giving the schools an unexpected extra cost with use of bandwidth, and big expenses with equipment. * Tradeoffs making Skolelinux 1.0 Our idea is that the system administrator, that could be a teacher, should not meet hundreds of question. When upgrading the installation, the teacher should not meet the question that were done for you when installing. The way to handle this when installing a Debian package was, and is not a straight through issue. - config-files not in the maintainer package When we made Skolelinux 1.0 we had to override configuration files when installing the system. It's around 20-30 files that has some changes to give the architecture out of the box with 15-20 services. - remove the choices When installing the system we also rewrote the Debian installer. The reason was to remove 128 questions, and let the teacher chose 3 (profile, language, and type the password -> go). The removal of choices should be the default option when updating or upgrading the serves, workstations, and thin [half thick] client servers. - ntp - service and high telephone bill We also had an opening to get a default configuration in some of the Debian packages. The ntp service was on example where the default setup is to connect to an external server to get the right time. For a school with a telephone connection with DIP, then the connection is set up every time when the ntp-server wants to adjust the clock. For one school this gave an extra telephone bill on 2,500 EURO in a month. This is expensive, so we got an other configuration as an alternative with the Debian package which just connected the local main server to adjust the time. * what we want to do Making the service oriented architecture fully reusable for every Custom Debian Distributions that are out there. Then the necessary config-files and choices in 20-30 packages needs to be in place from the package maintainer. It's also a goal to divide the service layer and the end-user applications. Andreas Tille has written an nice document about how to work together with Debian to make Custom Debian Distributions. http://people.debian.org/~tille/debian-med/talks/paper-cdd/debian-cdd.html * Sarge installation of Skolelinux from scratch Today it's possible to use, and maintain a Sarge based Skolelinux installed from scratch with some adjusting. Security patches is available. Follow his guide: http://developer.skolelinux.no/dokumentasjon/debian-edu_sarge_installation.txt http://lists.debian.org/debian-devel/2004/10/msg01231.html http://newraff.debian.org/~joeyh/testing-security.html * Upgrading from Woody-based installation Since we have some legacy configuration it's a lot of things to remember when making Skolelinux upgradeable from Woody to Sarge. 1. Some library upgrades don't replaced the old libraries When upgrading with apt-get, some libraries get kicked out and not replaced. This is solvable with using aptitude that includes the upgrades library-packages with the parameter "recommend". 2. Config-files in Debian packages is not ready for enterprise Since we want to use Skolelinux as an CDD enterprise solution, we had to do some changes in 20-30 config-files. Then this changed config-files has to "survive" and upgrade from Woody to Sarge. With a new upgraded package some of the config-files from Skolelinux Woody don't survive and upgrade. Many of them get deleted, and we have to place the right config-files on the servers, and on the workstations. This is mainly a three step issue. 2.1 To get enterprise selection of config-files into the package The CDD projects should do what they can to get their custom configurations into the Debian packages that is a part of the service-oriented architecture. When working together in the CDD community, it should be possible to persuade maintainers to take in some of the CDDs recommendations, just to make Debian even more enterprise friendly. 2.2 config-file with changed format and the old name Some of the config-file in upgraded libraries or servers has changed format from text to XML. This makes it hard to transform standardised settings from one older version of a CDD to an new and upgraded one. The config-file should change name when changing format from one Debian version to a newer one. Skolelinux now has to handle that in a semi proper way. 2.3 put new config-files on the new installation when the old ones are deleted This is the brute force approach. As we did with Skolelinux 1.0, it should be possible to do some pre- and post-installation adjustments to get the config-files in a recommended enterprise state. Unfortunately this will not help us when the next Debian comes out. So we have to work with two strategies. Both this one (2.3) and the "get the enterprise selection into the package" approach. 3. The solution for thin and half thick clients It has been some discussion how to make most of the hardware that are used in a Skolelinux network. It's a lot about money. This document shows the amount of serves, bandwidth and functionality you get in different configurations. http://developer.skolelinux.no/driftskonsepter/2004-12-23_thin-client-trade-offs.html We really want a half thick (stateless) solution hand in hand with real thin clients on Skolelinux and other CDDs. Finn-Arne, Jonas Smedegaard and Ragnar Wisloff has had many suggestions how to do thin and half thick clients in a maintainable way, inside Debian. The problem until now is that LTSP expect an almost "full distribution" to work with half thick clients. Therefore Lessdisks could be an replacement because it supports both thin and half thick clients, and it's a lightweight solution maintainable inside Debian. But also Ubuntu has done something interesting as Ragnar Wisloff pointed out the 29th of april 2005: http://udu.wiki.ubuntu.com/Edubuntu http://developer.skolelinux.no/driftskonsepter/2004-09-06-thin-clients.html * Some suggestions Making an upgrade script with documentation of: - Document of what to do before upgrading, under the upgrade, and after - Running a script to run that handle the backup of wanted directories, and the ldap-database - Upgrade from Woody based Skolelinux to Sarge-based Skolelinux - Running a post-install upgrade script handling, and set the installation straight Making a TODO-list from the CDD developers that makes upgrading easier in the future - Talking to the package maintainers to take in some enterprise readiness in a small collection of packages used in CDD. - Helping each other in the CDD communities to make the maintenance cost (in hours) with CDD as low as possible. - Common work with testing and bug-reports