Debian-Edu
Upgrading a preconfigured CDD

Some thoughts and observations from trying to upgrade debian-edu.

http://www.skolelinux.org/

Overview

Informal talk, questions are welcome at any time.

• What is seamless upgrades
• Upgrading with no local configuration
• Upgrade with user configuration
• Upgrade with server configuration
• Proposed solutions - preseeding and multilevel configuration
• Simple example

Seamless upgrades?

When I can install a package, add configuration to it and then upgrade it while keeping the configuration without any interactive fuzz, that is seamless upgrade.

If it was working before the upgrade, it should keep working after the upgrade.

Upgrading with no local configuration

Install a package, and upgrade it to sarge - does not always work!.

apt-get -y install xdvi
[...]
apt-get update && apt-get -y upgrade
[...]
Setting up tetex-base (2.0.2-6) ...

Configuration file `/etc/texmf/mktex.cnf'
 ==> File on system created by you or by a script.
 ==> File also in package provided by package maintainer.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : background this process to examine the situation
 The default action is to keep your current version.
*** mktex.cnf (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing \
tetex-base (--configure):
 EOF on stdin at conffile prompt

Upgrade with user configuration

Upgrading KDE from woody to sarge did not work very well.

• Users lost the login and lock button
• kpanel buttons broke
• Upgrading part of machines with shared home directories do not work well.

Upgrade with server configuration

Upgrading squid is painful. Simple configuration changes require a rewritten file - breaking seamless upgrade.

debian-edu example configuration:

maximum_object_size 20480 KB
refresh_pattern (Release|Package(.gz)*)$ 0 20% 2880
acl schoolnet src 10.0.2.0/255.255.254.0
acl ltspnet src 192.168.0.0/255.255.255.0
http_access allow schoolnet
http_access allow ltspnet

Proposed solution 1 - hidden debconf questions and preseeding

Fetch values from debconf at install time, and use this to set the configuration.

• debian/template:

  Template: foo/preseed/use_feature
  Type: boolean
  Default: false
  Description: Enable feature, preseed value
   This template is a hidden debconf question and should not be translated
  

• debian/config:

  if config_exist ; then
    get_feature_config ; db_set foo/preseed/use_feature "$RET"
  fi
  

• debian/postinst:

  if config_exist ; then get_feature_config ; CURRENT="$RET"; fi
  db_get foo/preseed/use_feature
  if [ "$CURRENT" = "$RET" ] ; then update_feature_config() ; fi
  

Proposed solution 2 - multilevel conf

• local configuration should be kept during upgrades
• do not change configuration file format
• easiest to do if the local configuration is separate from the package default
• several actors what to have a say in the service configuration. allow them to have their own files

Proposed solution 2 - multilevel conf (cont)

• Example: read config from /usr/share/foo/config, /site/share/foo/config, /etc/foo/config, ~/.foo/config, /etc/foo/config.fixed, /site/share/foo/config.fixed, /usr/share/foo/config.fixed.
• make it possible to provide package, site, host and user defaults, as well as locking down features on a host, site and package level.
• always well known where the admin made his changes

Squid example

Read config from /usr/share/doc/squid/squid.conf, and then read overrides from for example /site/etc/squid/squid.conf and final overrides from /etc/squid/squid.conf. Provide hidden debconf questions to fill in /etc/squid/squid.conf.

Allow simple common values to change using preseeding, for example maximum_object_size and allowed clients (acl)

CDD can provide a file in /site/etc/squid.conf with overrides, or use preseeding.

References

• Skolelinux web site
  — http://www.skolelinux.org/

Thank you very much

Questions?