Re: The next level of Custom Debian Distributions

[Jonas Smedegaard <dr@jones.dk>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 30-04-2005 18:17, Knut Yrvin wrote:

> * 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".

Switching to "using aptitude" involves more than just starting the tool,
if you want it to also cleverly handle *existing* packages installed
prior to the switch.

- From the top of my head is here the steps needed:


1) apt-get update

2) apt-get upgrade (to get most current woody-based packages)

3) apt-get install aptitude

4) Switch back to old (possibly messy) /etc/apt/sources.list

5) aptitude update

6) Mark all packages as auto-installed

7) Mark relevant packages as manually installed

8) Backup /etc/apt/sources.list

9) Replace /etc/apt/sources.list with only sarge and skolelinux-sarge

10) aptitude update

11) aptitude upgrade

All steps except the last one should be sane to do non-interactively.
Last step is best done interactively to give the local admin a chance to
adjust (press "e" when shown the final list of pending tasks and asked
to acknowledge continuation).

I suggest providing a backport of the current sarge aptitude for woody,
as the upgrade resolving logic and configuration defaults has improved.


> 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.

What are the exact files?

Is the Skolelinux hacks in a single (stack of) cfengine script(s)
somewhere or scattered around in the CVS?


> 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.

That is a general rule of a well-designed CDD, not something special to
the upgrade to sarge. Actually, for the upgrade to sarge it is probably
too late in the game to make Debian developers do CDD-enhancements to
their packages.


> 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.

What are the concrete situations? Gconf? Others?

It is well known what tweaks was done to the woody package. For each
tweak write a cfengine script doing the similar tweak (if still needed)
for the sarge package. Write the script so that only the relevant
options are tweaked, NOT by replacing the whole config file. That way
other tweaks done locally at the school are preserved (to the extend the
Debian package handles upgrading the config files itself).


> 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.

Any concrete examples of places this is needed?


> 3. The solution for thin and half thick clients

> 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

It seems to me that what Ubuntu _has_ done is _structure_ for an
educational branch of their distribution, and _preparations_ for LTSP
handled with Debian. It does not at all look like LTSP will be part of
Debian sarge, and it is still possible that LTSP will be treated as an
isolated "system within the Debian system", and thus won't ever get into
Debian proper.


> http://developer.skolelinux.no/driftskonsepter/2004-09-06-thin-clients.html

Lessdisks is seen only as a tool only for half-thick clients. The
development costs of lessdisks is actually the development costs of
half-thick clients, it seems.

Lessdisks works out of the box for plain thin-client use. And it works
out of the box for thin clients through SSH (which improves security and
slightly lowers bandwidth at the expense of ram and computing power).
What is needed for Skolelinux is automated setup. Done right it needs
the current bleeding-edge lessdisks code to mature, but done similarly
to other tweaks of Skolelinux it probably need only cfengine scripts.

Lessdisks is packaged for Debian already (I wouldn't mind you paying me
for the estimated 700h hours for maintainance and packaging that I do
already, but it kind of distorts the comparison).

In "estimating maintainance" is mentioned the need for repackaging due
to security upgrades of kernels. Lessdisks would need no sucvh updates:
Plain standard Debian kernels are used (the nfsroot-in-initrd is my
contribution to lessdisks :-) )!

Sorry for not looking closer at that paper earlier on.


 - Jonas

- --
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCdjr0n7DbMsAkQLgRAmVVAKCFptbyVWKHqK2E27EQndDUquQkdwCdFPFi
GWiZC/td6pMqmSnunsI/VdU=
=R09Y
-----END PGP SIGNATURE-----