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