The next level of Custom Debian Distributions
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
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
Reply to: