Manual for Debian Edu Etch 3.0 Codename "Terra"

/!\ Etch is not supported anymore, please upgrade to Lenny!

This is the (still incomplete) manual for the Debian Edu Etch 3.0 release.

This document was put into the debian-edu-doc package on $DEBIAN_EDU_DOC_BUILDDATE.

The version at is a wiki and updated frequently.

Translations are part of the debian-edu-doc package, which can be installed on a webserver.

About Debian Edu and Skolelinux

Skolelinux is a Linux distribution made by the Debian Edu project. Being a Custom Debian Distribution (CDD) it is part of Debian.

What this means is that Skolelinux is a version of Debian providing an out-of-the box environment of a completely configured school-network.

In Norway, where Skolelinux was started, the main target group is schools serving the 6-16 years age bracket. Today the system is in use in several countries around the world, with most installations in Norway, Germany and France.



This section of the document describes the network architecture and services provided by a Skolelinux installation.



(The debian-edu-doc source package contains this image as a dia file.)

The figure is a sketch of the assumed network topology. The default setup of a Skolelinux network assumes that there is one (and only one) main-server, while allowing the inclusion of both normal workstations and thin-client-servers (with associated thin-clients). The number of workstations can be as large or small as you want (starting from none to a lot). The same goes for the thin-client servers, each of which is on a separate network so that the traffic between the thin-clients and the thin-client server doesn't affect the rest of the network services.

The reason that there can only be one main server in each school network is that the main server provides DHCP, and there can be only one machine doing so in each network. It is possible to move services from the main server to other machines by setting up the service on another machine, and subsequently updating the DNS-configuration, pointing the DNS alias for that service to the right computer.

In order to simplify the standard setup of Skolelinux, the Internet connection runs over a separate router. It is possible to set up Debian with both a modem and an ISDN connection, however no attempt is made to make such a setup work out of the box for Skolelinux (the setup needed to adjust the default situation to this should be documented separately).


With the exception of the control of the thin-clients, all services are initially set up on one central computer (the main server). For performance reasons, the thin-client-server should be a separate machine (though it is possible to install both the main server and thin-client server profiles on the same machine). All services are allocated a dedicated DNS-name and are offered exclusively over IPv4. The allocated DNS name makes it easy to move individual services from the main-server to a different machine, by simply stopping the service on the main-server, and changing the DNS configuration to point to the new location of the service (which should be setup on that machine first of course).

To ensure security all connections where passwords are transmitted over the network are encrypted, so no passwords are send over the network as plain text.

Below is a list of the services that are set up by default in a Skolelinux network, with the DNS name of each service given in square brackets. Where possible the DNS name correspond to the service name in /etc/services, where this is not possible the common name of the service is used as the DNS name. All configuration files will, if possible, refer to the service by name (without the domain name) thus making it easy for schools to change either their domain (if they have an own DNS domain), or their IP address.

  • Centralized Logging [syslog]
  • DNS (Bind) [domain]
  • Automatic Network Configuration of Machines (DHCP) [bootps]
  • Clock Synchronization (NTP) [ntp]
  • Home Directories via Network File System (SMB/NFS) [homes]
  • Electronic Post Office [postoffice]
  • Directory Service (OpenLDAP) [ldap]
  • User Administration (lwat)
  • Web Server (Apache/PHP) [www]
  • Central Backup (sl-backup, slbackup-php) [backup]
  • Web Cache / Proxy (Squid) [webcache]
  • Printing (CUPS) [ipp]
  • Remote Login (OpenSSH) [ssh]
  • Automatic Configuration [cfengine]
  • Thin Client Server/s (LTSP) [ltspserver\#]
  • Machine and Service Surveillance with Error Reporting, plus Status and History on the Web. Error Reporting by E-mail (munin,nagios and site-summary)

Each user stores his personal files in his home folder which is made available by the server. Home folders are accessible from all machines, giving users access to the same files regardless of which machine they are using. The server is operating system agnostic in offering access using NFS for Unix Clients, SMB for Windows and Macintosh clients.

By default e-mail is set up for local delivery (i.e. within the school) only, though e-mail delivery to the wider Internet may be set up if the school has a fixed Internet-connection. Mailing lists are set up based on the user database, giving each class their own mailing list. Clients are set up to deliver mail to the server (using 'smarthost'), and users can access their personal mail through either POP3 or IMAP.

All services are accessible using the same username and password, thanks to the central user database for authentication and authorization.

To increase performance on frequently accessed sites a web proxy that caches files locally (Squid) is used. In conjunction with blocking web-traffic in the router this also enables control of Internet access on individual machines.

Network configuration on the clients is done automatically using DHCP. Normal clients are allocated IP addresses in the private subnet, while thin clients are connected to the corresponding thin-client-server via the seperate subnet (this to ensure that the network traffic of the thin clients doesn't interfere with the rest of the network services).

Centralized logging is set up so that all machines send their syslog messages to the server. The syslog service is set up so that it only accepts incoming messages from the local network.

By default the DNS server is set up with a domain for internal use only (*.intern), until a real ("external") DNS domain can be set up. The DNS server is set up as caching DNS server so that all machines on the network can use it as the main DNS Server.

Pupils and teachers have the possibility to publish websites. The web server provides mechanisms for authenticating users, and for limiting access to individual pages and subdiretories to certain users and groups. Users will have the possibility to create dynamic web pages, as the web server will be programmable on the server side.

Information on users and machines can be changed in one central location, and is made accessible to all computers on the network automatically. To achieve this a centralized directory server is set up. The directory will have information on users, user groups, machines, and groups of machines. To avoid user confusion there won't be any difference between file groups, mailing lists, and network groups. This implies that groups of machines which have to be network groups, have the same namespace as user groups and mailing lists.

Administration of services and users will by and large be via web, and follow established standards, functioning well in the web browsers which are part of Skolelinux. The delegation of certain tasks to individual users or user groups will be made possible by the administration systems.

In order to avoid certain problems with NFS, and to make it simpler to debug problems, time needs to be synchronized on the different machines. To achieve this the Skolelinux server is set up as a local Network Time Protocol (NTP) server, and all workstations and clients are set up to synchronize their clock with the server. The server itself should synchronize its clock via NTP against machines on the Internet, thus ensuring the whole network has the correct time.

Printers are connected where convenient, either directly onto the network, or connected to a server, workstation or thin-client-server. Access to printers can be controlled for individual users according to the groups they belong to, this will be achieved by using quota and access control for printers.

Thin clients

A thin client setup enables a ordinary PC to function as an (X-)terminal. This means that this machine boots from a diskette or directly from the server using network-PROM (or PXE) without using the local client hard drive. The thin client setup used is that of the Linux Terminal Server Project (LTSP).

Thin clients are a good way to make use of older, weaker machines as they effectively run all programs on the LTSP-Server. This works as follows: The service uses DHCP and TFTP to connect to the network and boot from the network. Next, the file system is mounted via NFS from the LTSP-server, and finally X11 is started and connected to the same LTSP-server by XDMCP, thus ensuring that all programs are run on the LTSP-server.

The thin client server is set up to receive syslog from the thin clients, and forward these messages to the central syslog recipient.

Diskless workstations

For diskless workstations the terms stateless workstations, lowfat clients or half-thick clients are also used.

A diskless workstation runs all software on the PC without a locally installed operating system. This means that client machines boot direcly from the servers hard drive without running software installed on a local hard drive.

Diskless workstations are an exellent way of reusing newer hardware with the same low maintanence cost as with thin clients. Software is administered and maintained on the server with no need for local installed software on the clients. Home directories and system settings are stored on the server too.

Diskless workstations were introduced as part of the Linux Terminal Server Project (LTSP) with version 5.0.

Networked clients

The term "networked clients" is used in this manual to refer to both thin clients and diskless workstations as well as computers running MacOS or Windows.


All the linux machines that are installed by means of a Skolelinux CD or DVD will be administrable from a central computer, most likely the server. It will be possible to login to all machines by ssh, and thereby have full access to the machines

We use cfengine to edit configuration files. These files are updated from the server to the clients. In order to change the client configuration, it suffices to edit the server configuration and let the automatation distribute the changes.

All user information is kept in an LDAP directory. Updates of user accounts are made against this database and is used by the clients for user authentication.


Installation is possible either from a CD or DVD.

The aim is to be able to install a server from CD/DVD, and install clients over the network by booting all other machines from the network. The DVD installation works without access to the Internet.

The installation should not ask any questions, with the exception of desired language (e.g. Norwegian Bokmal, Nynorsk, Sami) and machine profile (server, workstation, thin client server). All other configuration will be set up automatically with reasonable values, to be changed from a centrally location by the system administrator subsequent to the installation.

File system access configuration

Each Skolelinux user account is assigned a section of the file system on the file server. This section (home directory) contains the user's configuration files, documents, email and web pages. Some of the files should be set to have read access for other users on the system, some should be readable by everyone on the internet, and some should not be accessible for reading by anyone but the user.

To ensure that all disks that are used for user directories or shared directories can be uniquely named across all the computers in the installation, they can be mounted as /skole/host/directory/. Initially, one directory is created on the file server, /skole/tjener/home0/, in which all the user accounts are created. More directories may then be created when needed, to accomodate particular user groups or particular patterns of usage.

To enable shared file access control using the file groups, each user must be assigned a primary group with no other members. The name of this private group should be identical to the username. (More info on private groups is available from Redhat.) This allows for all new files created by the user to be set with full access for the file's group. Together with set-gid bit on directories and inheritance of rights, this enables controlled file sharing between the members of a file group. Therefore, the users' umask should be 00X. (If all users initially should be able to read newly created files, then X=2. If only the relevant group should be given initial read access then X=7.)

The initial access settings for newly created files is a matter of policy. They may either be set to give read access to everybody, which can later be removed by explicit user action, or they may be initially blocked, necessitating user action to make them accessible. The first approach encourages knowledge sharing, and makes the system more transparent, whereas the second method decreases the risk of unwanted spreading of sensitive information. The problem with the first solution is that it is not apparent to the users that the material they create will be accessible to all other users. This is detectable only upon inspection of other users' directories, where one can see that the files are readable. The problem with the second solution is that few people are likely to make their files accessible, even if they do not contain sensitive information and the content would be helpful to inquisitive users who want to learn how others have solved particular problems (typically configuration issues).

Suggestion: The files are initially set to be readable by all, but particular directories are created in which the content is initially blocked. This will simplify deciding whether the file should be made readable or not. Concretely, umask should be set to 002, and ~/ created with privileges 0775, ~/priv/ given 0750,and ~/pub/ given 0775. Files that should not be readable by others should be put in ~/priv/, whereas public files will be put in ~/pub/. Other files will initially be accessible, but may be blocked as needed.

ssh requires that the home directory can only be written to by the owner, thus the maximum access privilege for ~/ is 755.

  • - access to home directories (*~/.)? - home directories - shared directories?

random notes

These are random notes concerning things which should be included in this document.

  • Centralized user database with grouping and the ability to control which groups have access to which machines.
  • Grouping of machines and ability to control access to network services for these groups (access blocking to Internet via squid)
  • Should consider using a DNS name from RFC 2606.

This chapter was copied and pasted from ( at that time it was Copyright © 2001, 2002, 2003, 2004 Petter Reinholdtsen < >, released under the GPL) - note to translators: there are translations for this document already, which you can also copy and paste. But keep those copyright notes as well.



New features in the "3.0r1 Terra" release 2007-12-05

  • much improved documentation with updated translations to German, Norwegian Bokmal and Italian
  • includes more than 40 bug fixes, improvements and security updates that came to our attentention after the 3.0r0 release

New features in the "3.0r0 Terra" release 2007-07-22

  • Based on Debian 4.0 Etch released 2007-04-08.
  • Graphical installer with mouse support
  • Boot splash with usplash
  • LSB 3.1 compatible
  • Linux kernel version 2.6.18
    • Support for SATA controllers and hard disks
  • version 7.1.
  • KDE desktop environment version 3.5.5
  • version 2.0.

  • LTSP5 (version 0.99debian12)
  • Automatic tracking of installed machines using Sitesummary.
  • Automatic configuration of munin using data from Sitesummary.
  • Automatic version control of configuration files in /etc/ using svk.
  • File systems sizes can be extended while the file system is mounted.
    • Support automatically extending file system based on predefined rules.
  • Local Device Support on thin clients.
  • New processor architectures: amd64 (fully supported) and powerpc (experimental support, installation media only boots on the newworld subarchitecture)
  • Multi-architecture DVD for i386, amd64 and powerpc
  • Regression: the CD-install requires Internet access during installation. Previous versions could be installed from one CD without Internet access.
  • Regression: webmin is now removed from Debian because of problems supporting it. We've added a new web based user administration tool named lwat, which doesn't has the same functionality as wlus, the old user administration tool. But wlus requires webmin.

  • Regression: swi-prolog is not part of etch, but was part of sarge. The HowTo teach and learn Chapter describes how to install swi-prolog on etch.

Features in 2.0 release 2006-03-14

  • Based on Debian 3.1 Sarge released 2005-06-06.
  • Linux kernel version 2.6.8.
  • XFree86 version 4.3.
  • KDE version 3.3.
  • 1.1.

Features in "1.0 Venus" release 2004-06-20

  • Based on Debian 3.0 Woody released 2002-07-19.
  • Linux kernel version 2.4.26.
  • XFree86 version 4.1.
  • KDE version 2.2.

More information on older releases

More information on the older releases can be found at



There are different ways of set up a Skolelinux solution. It can be installed on just one standalone PC or a regional wide solution at many schools operated centrally. This variety of configurations makes a huge difference on how things are set up regarding network components, servers and client machines.

Hardware requirements

  • the computers running Debian Edu / Skolelinux must have either i386, amd64 or powerpc processors.
    • On powerpc, the installation media will only boot on machines of the newworld sub-architecture, which are the systems from apple with a translucent case
  • thin client (LTSP) servers need two network cards when using the default network architecture:
    • eth0 connected to the main network (
    • eth1 ( serving the thin-clients
  • disk space requirements depend on profiles used, but any disk from 8 GiB will be sufficient. As usual, the bigger the better.
  • for the thin clients 32 MB RAM and 133 MHz is recommended as minimum. Swap is required
  • for workstations or standalone PCs 450 MHz, 256 MiB RAM and 8 GiB disc space are recommended minimum requirements
  • for diskless workstations (also known as stateless workstations, lowfat clients or half-thick clients) 256 MB RAM and 800 MHz or more is recommended minimum requirements. Swapping over the network is automatically enabled, the swap size is 32mb, if you need more you can tune this by editing /etc/ltsp/nbdswapd.conf on tjener to set the SIZE variable.
  • for Laptops 256 MB RAM and 450 MHz are minimum requirements

Hardware known to work

A list of tested hardware is provided from . This list is not nearly complete :)

Requirements for a network setup

  • a router/gateway (IP providing access to the internet (when using the default network architecture)
  • for the main server ( this is the one single computer in the network which get's the tjener-profile installed

  • workstation(s) and/or thin client (LTSP) server(s)
  • thin clients clients

Internet router

A router/gateway, connected to the internet on the external interface and running on the IP address on the internal interface, is needed to connect to the internet.

The router should not run a DHCP server, it can run a DNS server, though this is not needed and will not be used. (If the router runs a DHCP server you must disable the DHCP server on the main server and you will loose some features and certain documented procedures will work differently. So better disable the DHCP server on the router.)

If you are looking for a i386 based solution (so that you can reuse an old PC), we recommend IPCop or floppyfw.

If you need something for an embedded router or accesspoint we recommend using OpenWRT, though of course you can also use the original firmware. Using the original firmware is easier, using OpenWRT gives you more choices and control. Check the OpenWRT webpages for a list of supported hardware.

It is possible to use a different network setup, this is the documented procedure to do this. If you are not forced to do this by an existing network infrastructure, we recommend against doing so and recommend you stay with the default network architecture.



Where to find more information

We recommend to read or at least take a look at the release notes for Debian Etch before you start installing a system for production use. If you just want to give Debian Edu/Skolelinux a try, you don't have to though, it should just work :-)

Even more information about the Debian Etch release is available in its installation manual.

Download an installation media for Debian Edu Etch 3.0r1

DVDs for i386, amd64 and powerpc

The multiarch dvd ISO image is 4.4 GiB large. To download it, use either of these methods:



or for the netinstall cd you can download for i386






and powerpc (suited for the newworld sub-architecture)



The powerpc port has not been tested as much as the other architectures, though it should work just fine and has been reported to work. Still, we consider the port an experimental release of Debian Edu, which we might not be able to support as the other archs.

The source code for this release is available on a DVD image



Request a CD/DVD by mail

For those without a fast internet connection, we offer to send you a CD or DVD for the cost of the CD or DVD and shipping. Just send an email to and we will discuss the payment details (for shipping and media) :) Remember to include the address you want the CD or DVD to be sent to in the email.

Installation from CD

The netinst installation will fetch some packages from the CD and the rest from the net. The amount of packages fetched from the net varies from profile to profile:

  • Main server: 8 of 115 MiB downloaded.
  • Main server and Thin client server: 618 of 1082 MiB downloaded.
  • Main server and Workstation: 618 of 1081 MiB downloaded.
  • Thin client server: 618 of 1052 MiB downloaded.
  • Workstation: 618 of 1051 MiB downloaded.
  • Standalone: 618 of 1020 MiB downloaded.
  • Barebone: 12 of 83 MiB downloaded.

The profiles are explained below.

Installation options

When you do an Debian Edu installation you have a few options to choose. But don't be afraid, there aren't many. We have done a good job hiding the complexity of Debian during the installation and beyond. However, Debian Edu is Debian, and if you want there are more than 15000 packages to choose from and a billion configuration options. But for the majority of our users, our defaults should be fine.

  • Normal graphical installation is the default on i386 and amd64. The powerpc installer does not support graphical installation. Enter install at the boot prompt to do an i386 text-mode install.

    • The debian-edu-expert boot-option adds the barebone profile to the profile options, and switches to manual partitioning. Enter installgui debian-edu-expert or install debian-edu-expert at the syslinux/yaboot prompt to enter expert mode.

    • If you want to boot the amd64 text mode with the multiarch DVD it would be amd64-install. Likewise you can choose amd64-expertgui to get the GUI version on amd64.

    • If you want to boot the i386 mode with the multiarch DVD on an amd64 machine you need to manually select install (text mode) or expertgui (graphical mode). The multiarch DVD defaults to use amd64-installgui on x86 64-bits machines, and installgui on x86 32-bits machines.

    • If you have already installed the mainserver profile on a machine, you can use its http proxy service to speed up the following installations from CD. Add d-i mirror/http/proxy string as additional boot-option.

  • Choose a language (for the installation and the installed system)
  • Choose a time-zone
  • Choose a keyboard keymap (usually the countrys default is fine)
  • Choose a profile:

    • server
      • This is the main server (tjener) for your school providing the following services: file, print, intranet, proxy, DNS, DHCP, LDAP, backup, nagios, simesummary, munin. All services are pre-configured and working out of the box. You must only install one main server per school!
    • workstation
      • A computer booting from its local hard drive, and running all software and devices locally like an ordinary computer, but the user login is authenticated by the main server, where the user's files and desktop profile are stored.
    • thin client server
      • Thin client (and diskless workstation) server. Clients with no hard drive boot and run software from this server. This computer needs two network cards, a lot of memory, and ideally more than one processor or core. Out of the box, this profile installs a thin client server. To turn it into a diskless workstation server you need to follow this HowTo. (Fixme: integrate this HowTo into this chapter of the manual.)

    • standalone
      • An ordinary computer that can function without a main server, ie. doesn't need to be on the network. Includes laptops.
    • barebone
      • This profile is only available when using the 'debian-edu-expert' boot option. It will install the base packages and configure the machine to integrate into the Debian Edu network, but without any services and applications. It is useful as a platform for single services manually moved out from the main-server.
    The first 3 profiles can all be installed on the same machine. That means the main server can also be a thin client server and can be used as a workstation.
  • say yes to automatic partioning, it will destroy the data on the harddrives!
  • say yes to partman
  • please say yes to submit information to - though you dont have to :)

  • wait
  • be happy

A note on manual partitioning

If you decide to do manual partitioning for the main-server, you need to make sure that the directory /skole/tjener/home0 exists, probably by mounting a partition there. If you don't create that directory you will only be able to login as root. The reason is that the user creation system require this directory to exist to be able to create users home directories, and without a users home directory the user can not log in.

A note on notebooks

In principal it makes sense to either install notebooks with the workstation or with the standalone profile. But keep in mind, that the workstation profile uses LDAP for the user accounts and NFS for the home directories, so those workstations will only work while in the network where they can access the server. If you plan to use your laptop at home or on the road, choose the standalone profile.

It is possible to reconfigure workstations to cache authentication information and sync the home directories to local disk (and resync to the server when in the network) with unison, but there is currently no howto available for this.

A note on DVD installs

If you install from a DVD /etc/apt/sources.list will only contain sources from the DVD. If you have an internet connection we strongly suggest to add the following lines to it, so that available (security) updates can be installed:

deb etch main 
deb etch/updates main 
deb etch local

Custom CD/DVDs

Creating custom CDs or DVDs is quite easily possible, since we use the debian installer, which has a modular design and other nice features. [ Preseeding] allows to define answers to the questions normally asked.

So all you need to do is to create a preseeding file with your answers (this is described in the appendix of the debian installer manual) and remaster the CD/DVD.

Screenshot tour through an i386 main-server + thin-client-server installation















The KDM login screen was manually adjusted to reduce the resolution for this screen shot.



Getting started

This chapter describes the first steps you need to do after the installation to get started. The minimum you need to do is:

  • adding workstations to host netgroups (for exporting home-directories via NFS)
  • adding users
  • it's advised to add the workstations to the dhcpd-config - LTSP-servers must be added.

This is described below.

The HowTo chapter describes more tips and tricks and frequently asked questions, while this chapter describes the stuff everybody needs to do.


Services running on the main server

There are several services running on the main server which can be managed via a web management interface. We'll describe each service here.

Web based management, using lwat

Lwat is a web based management tool, that will help you manage some important parts of your Debian Edu setup. You can manage this four main groups (add, modify, delete):

  • User Administration
  • Group Administration
  • Automount informations
  • Machine Administration

To access lwat point your webbrowser to https://www/lwat. You will get an error message, because of atleast 2 facts:

  • the certificate is self-signed
  • The certificate is generated for tjener.intern
  • you may also get an error if the installation is more than one month old, since the certificate is only valid for one month.

When you have neglected the warnings (or fixed them...), you will see the page below with the menu fixed to the left part and the varying main part on the right. First you'll see a login screen where you can login with your admin account. If you visit this site the first time after installation, the loginname there is:


and the password is the password you entered during the installation for the root account.


After login the loginarea will disappear and you can choose a task in the menu.

User Management with lwat

In Debian Edu account informations are stored in a LDAP directory and get used from there not only from the main server itself, but also from the workstations and thinclient server in the network. This way the information about students, pupils, teachers, ... only need to be entered once and are then available on all systems of the network.

To get the work done efficiently lwat will assist you on getting your users data entered to the LDAP directory.

You can add users, group them in usergroups (for example to refer the members of a class more easily), update them and remove them again. The menu entries for this are the four topmost entries (in the two topmost groups).

Adding users

To add users you only have to choose "Add" in the "Users" section of the menu. After choosing this entry you will see a form where you can enter the data of the user you want to add. The most important thing to add is the full name of your user (point one in the image). As you enter you will see, that lwat will generate a username automatically based on the realname. If you don't like the generated username you can change it later. Second you need to choose the role of your account, which is used by lwat to determine the privileges the user has for systemadministration. Currently lwat knows the following roles:


granted privileges


Login and use the system


Same as Students


Same as Teachers, but can also change other user passwords (besides the ones of Admins)


Admins have ultimate privileges. They can add/modify/delete users/groups/machines/automounts and let windows systems join the Skolelinux domain

After choosing a suitable role you can hit the "Save" button and the user is added.

You may miss the option to set a password, that has been deactivated, but you can set a own password by modifying the user added.


If all went well, you will see a short notice at the end of page with the data added to the ldap directory (also the form gets reset):

Added user: Demo User
username: demuse
password: somethingsecret

Search and delete users

To modify or delete a user you need to first find her using the search menu entry. You will find a form (searcharea in the screenshot) where you can enter either the realname or the username of the user. The results will show up below the form (marked as resultarea in the image). On the left of every result line there is a checkbox you can use to delete or disable on or more user with the two buttons below. If you want to modify a user, just click on it, all result lines are links to the modify page.


A new page will show up where you can modify information directly belonging to a user, change the password of the user and modify the list of groups the user belongs to.


Advanced user management

It possible to mass-create users with lwat by using a .csv file, which can be created with any good spreadsheet software (for example oocalc).

The import script expects a file formated with all data for one user on one row, with each field separated with a semicolon. The minimum information needed is the full name of the user. If fullname is not given, the script expects to have both Firstname and lastname. The maximum information it expects is "User template; Fullname; Username; Password; Additional group membership".

If a password column is missing, an easy to remember, pronounceble password will be created.

If users are put into groups, these groups have to exist, so you need to create them manually (with lwat, see below) before importing the users.

It's a good idea to do some tests first, best with a .csv file with a few fictional users, which can be deleted later.

Group Management with lwat

The mangement of groups is very similarly to the management of users. You can enter a name and a description per group. When be searching for groups you can also delete or disable all users of the groups found. From the modification page you can access all the users of that group.

The groups entered in the group management are also regular unix groups, so you can use them for file permissions too.

Advanced group management

Using lwat it's easy to put users in a specifig group (for example named after the year they enter or finish school) and to create all their home directories in a dedicated directory.

To achieve that, add a stanza like the following to the file /etc/lwat/admin.ini:

ou = "ou=People,%base%"
objectClass = top posixAccount shadowAccount imapUser sambaSamAccount
homeDirectory = /skole/tjener/home0/2009/%username%
groups = none students 2009
loginShell = /bin/bash
mailMessageStore = /var/lib/maildirs/%username%

To make this work the 2009 group has to be created before adding these users.

The above stanza simply adds then on top off home0, if you want them somewhere else, using another automount, then you use lwat to add that automount, and change the homeDirectory string in admini.ini corespondingly.

Machine Management with lwat

With the machine management you can basically manage all IP based devices in your Debian Edu network. Every machine added to the LDAP directory using lwat has a Hostname, an IP-address, an MAC-address and a domain name which usually is "intern". For a more verbose description about the Debian Edu architecture see the architecture chapter of this manual.

If you add a machine, you can use an ip/hostname from the preconfigured address space. The following ip ranges are predefined:

First address

Last address





The addresses from till and till are reserved for dhcp and are assigned dynamically.

To assign a host with the MAC-address 00:40:05:AF:4E:C6 a static IP-address you only have to enter the MAC-address and the hostname static00, the remaining fields will be filled automatically according to the predefined configuration.


/!\ This will not configure the dhcp server. You need to configure the host statically or edit the configuration of the dhcp server by hand as shown directly below.

Assign static ip addresses with dhcp

To assign a static ip address to a host which you added to the ldap tree via lwat, you need to edit /etc/dhcp3/dhcpd.conf and run /etc/init.d/dhcp3-server restart as root.

For our example above you would, after open /etc/dhcpd3/dhcpd.conf in your favourite editor, search for the configuration section of the host static00. You should find something exactly like this:

host static00 {
  hardware ethernet 00:00:00:00:00:00;
  fixed-address static00;

You need to replace the all-zero MAC-address with the correct one of your static host. For our example host it will look like this:

host static00 {
  hardware ethernet 00:40:05:AF:4E:C6;
  fixed-address static00;

/!\ Don't forget to restart the dhcpd as described above whenever you have changed the configuration.

Search and delete machines

Searching for and deleting machines is quite similar to searching and deleting users, so that information is not repeated here.

Modify existing machines / Netgroup management

After adding a machine to the ldap tree using lwat, you can modify its properties using the search functionality and clicking on the right entry (as you would with users).


The form that is behind this machine links is in one way similar to the one you already know from modifying user entries, but in an other way the informations do mean different things in this context.

For example, adding a machine to a NetGroup does not modify the permissions one machine (or the users logged into that machine) has on accessing files or programs on the server. It is more that it restricts the services a machine can use on your main-server.

The default installation provides the four NetGroups printer-hosts, workstation-hosts, ltsp-server-hosts and server-hosts. Currently the NetGroup functionality is used only for NFS. The homedirs are exported by the main-server to be mounted by the workstations and the ltsp-servers. Because of security reasons only hosts within the workstation-hosts, ltsp-server-hosts and server-hosts NetGroups can mount the exported NFS shares. So it is rather important to remember to configure this kinds of machines properly in the ldap tree using lwat and configuring them to use the static IPs from ldap.

/!\ Remember to configure workstations and ldap-servers properly with lwat, or you users can't access their homedirs.

Another important part of the machine configuration is the 'Samba host' flag (in the 'Host information' area). If you plan to add existing Windows systems to the Skolelinux Samba domain, you have to add the Windows host to the ldap tree and set this flag to be able to join the Windows host to the domain.

More lwat documentation

The full documentation for lwat can be found at /usr/share/doc/lwat/ on the main server or online.

Printer Managment

For Printer Management point your webbrowser to https://www:631 This is the normal cups management site where you can add/delete/modfiy your printers and can clean up the printing queue. For changes where you have to login as root with your root password, you will be forced to use ssl encryption.

If you connect the printer for the first time, we suggest to run printconf as root.

Clock synchronization

The default configuraiton in Debian Edu is to keep the clocks on all machines synchronous but not necessarily correct. NTP is used to update the time. The clocks will not be synchronized with an external source by default, to make sure the machines to not use external network connections active all the time. This was configured like this after a school discovered their ISDN network was up all the time, giving them a nasty extra phone bill.

To enable synchronization with an external clock, the file /etc/ntp.conf on the main-server need to be modified. The comments in front of the server entries need to be removed. After this, the ntp server need to be restarted by running /etc/init.d/ntp restart as root. To test if the server is using the external clock sources, run ntpq -c lpeer.

Extend full partitions

Because of a bug in the automatic partition, some partitions might be too full after installation. To extend the full partitions, run debian-edu-fsautoresize -n as root. See the "Resize Partitions" HowTo in the administration howto chapter for more information.



Updating the software

This section explains how to use aptitude upgrade and kde-update-notifier.

Using aptitude is really simply. To update a system you need to execute two commands on the command line as root: aptitude update (updates the lists of available packages) and aptitude upgrade (upgrades the packages for which an upgrade is available).

Instead of using the command line you can also use kde-update-notifier.

It is also a good idea to install cron-apt and apt-listchanges and configure them to send mail to an address you are reading.

cron-apt will notify you once a day via email, which packages need an update. It does not install these updates, but downloads them (usually in the night), so you don't have to wait for the download, when you do aptitude upgrade.

apt-listchanges can send new changelog entries to you.

Backup Management

For the backup management point your browser to https://www/slbackup-php. Please note that you have to access this site via ssl, since you have to enter the root password there. If you try to access this site without using ssl it will fail.

Per default the tjener will backup /skole/tjener/home0, /etc/, /root/.svk and the ldap to /skole/backup which is in the lvm. If you only want to have things twice (if you delete something) this setup should be fine for you.

/!\ Be aware that this backup doesn't protect you from failing harddrives.

If you want to backup your data to an external server, a tape device or another harddrive you'll have to modify the existing configuration a bit.

If you want to restore a complete folder, your best option is to use the command-line:

$ sudo rdiff-backup -r <date>  \
   /skole/backup/tjener/skole/tjener/home0/user \

this will leave the content from /skole/tjener/home0/user from <date> in the folder /skole/tjener/home0/user_<date>

If you want to restore a single file, then you should be able to select the file (and the version) from the web-interface, and download only that file.

Server Monitoring


Munin trend reporting system is available from https://www/munin/. It provides system status measurement graphis on a daily, weekly, monthly and yearly basis, and allow the system administrator help when looking for bottlenecks and the source of system problems.

The list of machines being monitored using munin is generated automatically based on the list of hosts reporting to sitesummary. All hosts with the package munin-node installed is registered for munin monitoring. It will normally take two days from a machine is installed until munin monitoring start, because of the order the cron jobs are executed. To speed up the process, run /etc/cron.daily/sitesummary-client as root on the freshly installed machine, and /etc/cron.daily/sitesummary as root on the sitesummary server (normally the main-server).

Information about the munin system is available from .


Nagios system and service monitoring is available from https://www/nagios2/.

The username is nagiosadmin and the password is undefined, you must set your own password before you can login and use nagios. For security reasons, avoid using the samme password as root. To change the password you can run the following command as root:

htpasswd /etc/nagios2/htpasswd.users nagiosadmin

By default from Debian-Edu 3.0r1 Nagios does not send email. This can be changed by replacing notify-by-nothing with host-notify-by-email and notify-by-email in the file /etc/nagios2/debian-edu/contacts.cfg.

Information about the nagios system is available from or in the nagios2-doc package.


A simple report from sitesummary is available from https://www/sitesummary/.

Some documentation on sitesummary is available from



Before explaining how to upgrade, please note, that you do this update on your productive server on your own risk. Debian Edu/Skolelinux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Please read this chapter completly before attempting to upgrade.

More information about the Debian etch release is available in its installation manual.

If you want to be sure that after the upgrade everything works like before , you should test the upgrade on a test server, which is configured the same way as your production server. There you can test the upgrade without risk and see if everything works as it should.

Also it might be wise to wait a bit and keep running sarge for some more weeks, so that others can test the upgrade, experience problems and document them here. Debian Edu sarge will receive continued support for some time in the future, but when Debian ceases support for sarge, Debian Edu will (have to) do that too. This is expected to happen in April 2008.

Upgrades from Debian Edu sarge

Please read this chapter completly before you start upgrading your systems.

In case of problems you could also read the releasenotes for Debian etch. (Debian Edu/Skolelinux "2.0 Terra" installed a 2.6 kernel as default, but if you are running a 2.4 kernel, you should read the notes on upgrading from kernel 2.4 to 2.6 before you upgrade!)

Partioning scheme changed

The main problem upgrading from the sarge-based Release to Terra is that the Partition Scheme changed completly. The sarge-based Release has two volume Groups:

  • vg_data which holds the Data Partition as /skole/tjener/home0, ...
  • vg_system contains System Partitions as /var, /usr /var/spool/squid

But the etch based release has only 1 Volume Group due to internal changes of the Installer.

The main problem is that the vg_system volumegroup is quite small since the data in this partition is mostly static. When trying the upgrade on a virtual machine with an 8GB harddrive, the upgrade failed since it was not possible to free more space on the vg_sytem. Please note that you should have about 1,5GB free space on /var and about 600MB free space on /usr. If this is not the case the upgrade will fail because of too little free space on the device.

Prepare the system

If you have enough space in the vg_system volumegroup but not in the lv_var partition, you have to resize this partition:

  • 1.) Umount the /var partition, you 'll have to umount the /var/spool/squid partition for this to work, too:

    • /etc/init.d/squid stop
      umount /var/spool/squid
      umount -fl /var 
    2.) fsck the partition:
    • e2fsck -f /dev/vg_system/lv_data 
    3.) resize the partition:
    • lvextend -L +1GB /dev/vg_system/lv_data 
    4.) resize the filesystem:
    • resize2fs /dev/vg_system/lv_data
    5.) mount the partitions again:
    • mount /var
      mount /var/spool/squid
      /etc/init.d/squid start 

Now modify /etc/apt/sources.list to contain these lines

  • deb etch main
    deb etch/updates main 
    deb etch local

And start the upgrade with:

  • aptitude update
    aptitude dist-upgrade 

Answers to debconf questions raising during upgrade

Here we can give you some hints, what you should answer to the debconf question during the upgrade. But please note: This upgrade HowTo is based on a very plain fresh installation of an mainserver + terminalserver.

Which questions exactly raise up in addition to the ones described here depends on what is additionally installed on your system. (Additionally to what is installed as default in the sarge based Debian Edu release). So if there are any questions which you don't know how to answer, don't hesitate to ask us at the mailinglist ( or at IRC ( #debian-edu.

* Configure nagios-common.

  • Here you have to enter a password for the nagiosadmin user.

* Configure console-data

  • Choose "Don't change keyboard layout"

* Configure openssh-server

  • Don't deactivate challenge-response Auth.

* Configure systat

  • Choose the default (yes) here.

* Configure popularity-contest

  • If you choose "yes", this will help us improve Debian Edu. (We'll get an weekly report which programs are how often used). The data is gathered anonymously and you have the option to say "no".

* Configure libnss-ldap

  1. Change the prompt to: ldaps://ldap/

  2. Change the prompt to: dc=skole,dc=skolelinux,dc=no

  3. Use ldapversion 3 here
  4. Which account should root use for ldap lookups
  5. Which password should root use here

* Upgrade glibc now. Answer "yes".

* Restart Services. Answer "yes".

These are the debconf questions you will see if you have no additional packages installed.

Now the upgrade process will start to upgrade the packages.

Please note: You will be asked several times if you want to keep your old modified version of a configfile or if you want to get the latest. The default is to keep your modified one. Unless you really have modified something, please always choose: "Install the latest one".

The upgrade will fail with this error message:

Errors were encountered while processing:
E: Sub-process /usr/bin/dpkg returned an error code (1)

To fix this you have to edit these two files: /var/lib/dpkg/info/mozilla-firefox-locale-it.postrm and /var/lib/dpkg/info/mozilla-firefox-local-el.postrm and comment out in both the line containing: update-mozilla-firefox-chrome. Then restart the upgrade process with:

apt-get -f install

Now the upgrade continues:

* Several Modified configuration files (nagios)

  • You should always keep your installed one (default) and hit enter

Then the installation failes another time:

Errors were encountered while processing:
E: Sub-process /usr/bin/dpkg returned an error code (1)

In order to fix this, rename this directory: /var/backups/dc=skole,dc=skolelinux,dc=no-2.2.23-8.ldapdb and since openldap now runs as user openldap (instead of as root) the permissions of the configuration files have to be changed:

chown -R openldap:openldap /etc/ldap/
apt-get -f install

Then the installation should finish without an error. Since now many packages are not upgrades please restart the dist-upgrade process again with:

aptitude dist-upgrade

The next error raising up is this one:

Errors were encountered while processing:
E: Sub-process /usr/bin/dpkg returned an error code (1)

Please remove the package: courier-ldap with

aptitude remove courier-ldap

and wait until it is finished.Then restart the dist-upgrade process again.

If you have only the default packages installed the upgrade process should now finish without raising more errors.

Problem upgrading bind

The only remaining upgrade issue is that the user of bind9 has changed, so you'll have to chown all bind-configuration files.

chown bind:root -R /etc/bind 

See 386791 for more information.

Samba groupmaps handeling changed

There has been a change in how samba handles groupmaps between sarge and etch. Samba in sarge handled groupmaps internally, so a unix group was also a samba group. In etch samba keeps groupmap information in the LDAP database. Unfortunatly this issue was discovered too late for our LDAP admin tool "lwat" to be aware of the situation.

When you upgrade your LDAP from a sarge installation, you must make sure to create the Domain Admins account, neccessary for correct samba domain operation. Create the Domain Admins account with the command:

/usr/bin/net groupmap add rid=512 unixgroup=admins \
             type=domain ntgroup="Domain Admins" \
             comment="All system administrators in the school"

If you want your Windows computers to be aware of what groups users are in, you must create the groupmaps in LDAP manually, this is explained in more detail in the HowTo/NetworkClients chapter of this manual.

Upgrades from older Debian Edu / Skolelinux installations

Upgrades from the woody based Debian Edu / Skolelinux installation are not supported. Upgrade to the sarge based version first, a howto can be found at ?DebianEdu/HowTo/UpgradeFrom1.0. Then upgrade to Terrra (etch-based Release).


HowTos for general administration

The Getting Started and DebianEdu/Documentation/Etch/Maintainance chapters describe how to get started with Debian Edu and how to do the basic maintainance work. The howtos in this chapter are already "advanced" tips and tricks.

Installing single service machines for spreading the load from main-server

  • barebone install using debian-edu-expert
  • install the packages for the service
  • configure the service
  • disable the service on main-server
  • update dns on main-server

Tracking /etc/ using the svk version control system

With the introduction of the debian-edu-etc-svk script in Debian Edu, all files in /etc/ are tracked using svk as a version control system. This make it possible to see when a file added, changed and removed, as well as what was changed if the file is a text file. The svk repository is stored in ~root/.svk/.

This feature is activated automatically in the Etch based version of Debian Edu, and all changes done during installation are registered. Changes in /etc/ are committed every hour.

List of useful commands:

 debian-edu-etc-svk diff
 debian-edu-etc-svk log
 debian-edu-etc-svk status
 debian-edu-etc-svk commit
 debian-edu-etc-svk ignore

Usage examples

In a freshly installed system try this to see all changes done since the system was installed:

debian-edu-etc-svk diff -r6 | less

To see the list of changes done in /etc/, use this command:

debian-edu-etc-svk log | less

Here check revision numbers by date and time, Then to see all changes done since revision N say:

debian-edu-etc-svk diff -rN | less

To see the changes done to a specific file between specific revisions, specify the file and both revisions:

debian-edu-etc-svk diff -r46 -r64 /etc/resolv.conf | less

To revert a change, use the diff command to look at the change, and edit the file to undo the change, or use a command like this to do it automatically:

( cd /etc && debian-edu-etc-svk diff -r6 /etc/resolv.conf | patch -p1 -R )

To manually commit a file, because you don't want to wait up to an hour:

debian-edu-etc-svk commit /etc/resolv.conf

If you don't want a specific file to be tracked in svk, you can tell to ignore it. But this is rarely useful :)

debian-edu-etc-svk ignore /etc/path/to/file/to/be/ignored

For those who upgraded from sarge/woody

/etc in svk was introduced with the etch based release of Debian Edu. If you installed your system prior to this, you need to initialize svk once with the following command run as root:

debian-edu-etc-svk init

This adds all files in /etc to svk and also activates the hourly commit cronjob.

Resize Partitions

Most partitions in Debian Edu are logical LVM volumes. Only the /boot/ partition is not. With the Debian/Etch release of Debian Edu, it is possible to extend partitions while they are mounted. This is a feature of the Linux kernel since version 2.6.10. Shrinking partitions still need to happen while the partition is unmounted.

It is a good idea to avoid creating very large partitions, as large partitions will take a long time to restore from backup if the need should arise, and file system check take a very long time for large partitions. A good limit can be 20 GiB. It is better, if possible, to create several smaller partitions than one very large one.

To make it easier to extend full partitions, the debian-edu-fsautoresize script is provided. When invoked, it reads the configuration from /usr/share/debian-edu-config/fsautoresizetab, /site/etc/fsautoresizetab and /etc/fsautoresizetab, and based on the rules provided in these files propose to extend partitions with too little free space. Without any arguments, it will only write the commands needed to extend the file system, and the argument -n is needed to actually extend the file systems.

Logical Volume Management

Logical Volume Management (LVM) enables resizing the partitions while they are mounted and in use. You can learn more about LVM in the LVM HowTo.

To extend a logical volume manually you simply tell the lvextend command how large you want it to grow to.

For example, to extend home0 to 30GB you use the following commands:

lvextend -L30G /dev/vg_system/skole+tjener+home0
resize2fs /dev/vg_system/skole+tjener+home0


Since is a relatively new service, introduced with Debian Etch, it's not enabled on default installations.

What is debian-volatile?

Quoting from the webpage:

  • Some packages aim at fast moving targets, such as spam filtering and virus scanning, and even when using updated data patterns, they do not really work for the full time of a stable release. The main goal of volatile is allowing system administrators to update their systems in a nice, consistent way, without getting the drawbacks of using unstable, even without getting the drawbacks for the selected packages. So debian-volatile will only contain changes to stable programs that are necessary to keep them functional.

How to use volatile

Since the volatile archive key is included in the debian-archive-keyring package, which is installed by default, you do not have to add this key manually to roots keyring anymore. Just add the following line to /etc/apt/sources.list:

deb etch/volatile main

And run aptitude update && aptitude upgrade.

Using backports

You are running Debian Edu, because you prefer the stability of Debian Edu. It runs great, there is just one problem: sometimes software is a little bit more outdated as you like. This is where backports step in.

Backports are recompiled packages from Debian testing (mostly) and Debian unstable (in a few cases only, e.g. security updates), so they will run without new libraries (wherever it is possible) on a stable Debian distribution like Debian Edu. We recommend you to pick out single backports which fit your needs, and not to use all backports available there. Please follow the instructions on Backports to use these backports.

You can either use aptitude -t etch-backports install <packagename> to install or update packages once, or you can configure a package to be always installed from backports though /etc/apt/preferences which is described in the instructions.

The second variant has the advantage, that updates to backports are installed automatically when they are available. With the first variant you need to update manually.


apt-get install sun-java5-plugin sun-java5-jre sun-java5-fonts

Access to skolelinux server from outside a firewall

A boot script open-backdoor is provided in the debian-edu-config package to "break out" from behind a firewall. It is useful for system administrators responsible for several Debian Edu installations. It set up an SSH tunnel to another machine, allowing ssh login from the outside of the firewall.

To enable it, create a ssh key without a password, create a user on a remote host to use for ssh login, copy the public key into ~/.ssh/authorized_keys for the remote user used for and specify the login information in /etc/default/backdoor.

Content of /etc/default/backdoor should be similar to this:

Creating a folder in all users home directory

With this script the administrator can create a folder in each users home directory and set access permissions and Ownership.

In the example shown below with group=teachers and permissions=2770 a user can hand in an assignment by saving the file to the folder "assignments" where teachers are given write access to be able to make comments.

        for home in $(ls $home_path);do
        . if [ ! -d "$home_path/$home/$shared_folder" ]; then
        . mkdir $home_path/$home/$shared_folder
        chmod $permissions $home_path/$home/$shared_folder
. #set the right owner and group
  #"username" = "group name" = "folder name"
        chown $user:$group $home_path/$home/$shared_folder
  . echo -e "the folder $home_path/$home/$shared_folder already exists.\n"
 . fi
echo "$created_dir folders has been created"

Easy access to USB and CDROM

When users insert a usb or cdrom into a ?ThinClient there is no popup window like they are used to from their usual Desktop. Instead they have to browse to the /media/$user folder. This is too difficult for non experienced users.

With the following script the symlink "Media" is created for all users in the home folder for easy access to USB-keys, CDROM or whatever media is connected to the thin client.

home_path="/skole/tjener/home0"; shared_folder="Media"; permissions="775"; created_dir=0;
for home in $(ls $home_path); do
  if [ ! -d "$home_path/$home/$shared_folder" ]; then
    ln -s /media/$home $home_path/$home/$shared_folder ((created_dir+=1))
    echo -e "the folder $home_path/$home/$shared_folder already exists.\n"
echo "$created_dir folders has been created"

HowTos from

The HowTos from are either user- or developer-specific. Let's move the user-specific HowTos over here (and delete them over there)! (But first ask the authors (see the history of those pages to find them) if they are fine with moving the howto and putting it under the GPL.)


HowTos for the desktop

KDE Kiosk mode

Two default profiles are included:

debian_edu_pupils (enabled for members of the students file group)

  • customized set of icons appears on student desktops
  • makes sure that the programs behind the desktop icons also show up in the kde panel
  • adept is not started
  • makes sure that students cannot start another kde session
  • disables possibility to gain root access for students

debian_edu_root (enabled for the root user and members of the admins file group)

  • adds a desktop icon to connect to the local webserver on tjener to provide easy access to all the administration programs

Note:: modifications to the profiles can be done using kiosktool. However, unless you follow the step below, your changes will be overwritten by upgrades.

If you want to modify the kiosk profiles, you can either copy the existing ones and modify them, or create new kiosk profiles in (for example) /etc/kde3/kioskprofiles/ and enable them in /etc/kde-user-profile. The kiosk tool will do this for you if you click "profile properties" and browse to a new folder.

Changing kioskmode on diskless workstations

After you have made changes to the kioskmode settings with kiosktool like described above, you will have to copy some files inside the chroot used by the diskless workstation.

Assuming the diskless workstations are running i386, the following commands must be executed on the workstation server(s):

export LTSPCHROOT=/opt/ltsp/i386/
cp -rv /etc/kde-profile/ $LTSPCHROOT/etc/
cp -v /etc/kderc $LTSPCHROOT/etc/
cp -v /etc/kde-user-profile $LTSPCHROOT/etc/
cp -rv /usr/share/debian-edu/students  $LTSPCHROOT/usr/share/debian-edu/
cp -rv /usr/share/applications/  $LTSPCHROOT/usr/share/

Else replace i386 with amd64 or powerpc as applicable.

Disabling kioskmode

If you don't want to use kioskmode, either just remove the file /etc/kderc. Or, if you just want to temporarily disable kioskmode, comment out all entries in there.

Modifying the kdm login screen

In Debian/Etch, the way to customize the kdm login screen was changed. Now, it is done by adding a file in /etc/default/kdm.d/ specifying variables to override the default.

Here is one example used to activate the theme in the desktop-base package:


See the code in /etc/init.d/kdm for information on how these variables are used.


To install the Adobe Flash Player web browser plugin, install the flashplugin-nonfree debian package from

There are three requirements to do so:

  • add to /etc/apt/sources.list as decribed in the general adminstration howtos

  • add the following lines to /etc/apt/preferences (the file probably does not exist, so you might have to create it):

Package: flashplugin-nonfree
Pin: release a=etch-backports
Pin-priority: 999
  • as the flashplugin-nonfree package is only an installer-package (and does not contain the flashplugin itself, for legal reasons), it also requires a working internet connection as it will download the precompiled binary from Adobes website.

Sound with Flash in thin clients

You need to install this as root:

and make one change in /etc/apt/sources.list

deb etch-test local

And that followed by aptitude update and aptitude install flashplayer-nonfree-extrasound

remeber to remove deb etch-test local from source list after that and run aptitude update again.

To get the sound working, you also need the latest flashplugin-nonfree package installed (23st of Jan:

Other useful plugins

After adding the multimedia repository (see below):

apt-get install mozilla-mplayer mozilla-acroread acroread-plugins

Playing DVDs

libdvdcss is needed for playing most commercial! DVDs. For legal reasons it's not included in Debian (Edu). If you are legally allowed to use it, you can use the packages from Add the multimedia repository and install multimedia and dvd libraries:

apt-get install libdvdcss2 w32codecs

Using the multimedia repository

To use do the following:

# install the debian-keyring securily:
aptitude install debian-keyring
# fetch the deb-multimedia key insecurily:
gpg --keyserver --recv-keys 1F41B907
# check securily if the key is correct and add it to the keyring used by apt if it is:
gpg --keyring /usr/share/keyrings/debian-keyring.gpg --check-sigs 1F41B907 && gpg --export 1F41B907 | apt-key add -
# add repository to sources.list - please check the homepages for mirrors!
echo "deb etch main" >> /etc/apt/sources.list
# update the list of available packages:
aptitude update


HowTos for networked clients

Thin Clients vs Diskless workstations

Instructions on how to enable diskless workstations / stateless workstations / lowfat clients / half-thick clients are available from

LTSP in detail


To make special adaptations and configurations for specific thinclients, you can edit the file /opt/ltsp/i386/etc/lts.conf. Have a look at /opt/ltsp/i386/usr/share/doc/ltsp-client/examples/lts.conf to see examples and what parameters you can specify.

The default values is defined under [default], to configure one client, specify which client using the client mac adress or ipadress like this [].

Example: To make the thinclient ltsp010 use 1280x1024 resolution, add something like this:

X_MODE_0 = 1280x1024
X_HORZSYNC = "60-70"

somewhere below the default settings.

Depending on what changes you make, it may be necessary to restart X on the client (by pressing alt+ctrl+backspace) or restart the client.

To use ipadresses in lts.conf you should add the client mac-address to your dhcp-server. Otherwise you should use the client mac-address directly in you lts.conf file.

Load balancing LTSP servers

/!\ This feature was new in ltsp version and is included in Skolelinux 3.0r1.

Part 1

It is possible to set up the clients to connect to one of several servers for load balancing. This is done by providing /opt/ltsp/i386/usr/lib/ltsp/get_hosts as a script printing one or more servers for LDM to connect to. In addition to this, each ltsp chroot need to include the ssh host key for each of the servers.

First of all, you must choose one LTSP server to be the loadbalancing server. All the clients will PXE-boot from this server and load the Skolelinux image. After the image is loaded, LDM chooses which server to connect to by using the "get_hosts" script. How this is done you decide later on.

Now you have to move your clients from the network to the network. This is because when you use loadbalancing, the clients should have direct access to the server LDM chooses. If you leave your clients on the network, all of the clients traffic will go through that server before it reaches the chosen LDM server.

To get the clients working on the network, you have to edit /etc/dhcp3/dhcpd.conf on the main-server (tjener). Where it says:

subnet netmask {

you have to add this under "range":

filename "/var/lib/tftpboot/ltsp/i386/pxelinux.0";
next-server xxx;
option root-path "/opt/ltsp/i386";
option log-servers ltspserver01;
use-host-decl-names on;

Next-server should be the IP-address or hostname of the server you chose to be the loadbalancing server. If you use hostname you must have a working DNS. Remember to restart the dhcp service.

Part 2

Now you have to make a "get_hosts" script that prints a server for LDM to connect to. The parameter LDM_SERVER overrides this script. In consequence, this parameter must not be defined if the get_hosts is going to be used. The get_hosts script writes on the standard output each server IP address or host names, in the random order.

Edit "/opt/ltsp/i386/etc/lts.conf" and add something like this:

MY_SERVER_LIST = "xxxx xxxx xxxx"

Replace xxxx with either the IP or hostname of the servers, list must be space separated. Then, put the following script in /opt/ltsp/i386/usr/lib/ltsp/get_hosts on the server you chose to be the loadbalancing server.

# Randomize the server list contained in MY_SERVER_LIST parameter
for i in $MY_SERVER_LIST; do
let "rank %= 100"
TMP_LIST=$(echo -e $TMP_LIST | sort)
for i in $TMP_LIST; do
SHUFFLED_LIST="$SHUFFLED_LIST $(echo $i | cut -d_ -f2)"

Part 3

Now that you've made the "get_hosts" script, it's time to make the ssh host key for the ltsp chroots. This can be done by making a file containing the content of /opt/ltsp/i386/etc/ssh/ssh_known_hosts from all the ltsp servers that will be loadbalanced. Save this file as /etc/ltsp/ssh_known_hosts.extra on all loadbalance servers. The last step is very important because ltsp-update-sshkeys runs every time a server is booted, and /etc/ltsp/ssh_known_hosts.extra is included if it exists.

/!\ If you save your new host file as /opt/ltsp/i386/etc/ssh/ssh_known_hosts, it will be erased when you reboot the server.

There is some obvious weaknesses with this setup. All clients get their image from the same server, this causes high loads on the server if many clients are booted at the same time. Also the clients require that server to always be available, without it they cannot boot or get a LDM server. Therefore this setup is very dependent on one server, which isn't very good.

Your clients should now be loadbalanced!

Sound with LTSP clients

If the client has sound hardware support and alsa is used (currently, this is the default sound system in Debian), module snd-pcm-oss should be loaded by the client hardware to assure esd can find /dev/dsp. If it's not done automatically, this line:

MODULE_01 = "snd-pcm-oss"

should be added to the server in the /opt/ltsp/i386/etc/lts.conf file.

Upgrading the LTSP environment

It is useful to upgrade the LTSP environment with new packages fairly often, to make sure security fixes and improvements are made available. To upgrade, run these commands as user root on each LTSP server:

chroot /opt/ltsp/i386
aptitude update
aptitude upgrade
aptitude dist-upgrade

/!\ Note that this is a slightly risky operation, if one of the upgraded packages break. To reduce the risk, it is a good idea to copy the content of /opt/ltsp/i386 to be able to revert to the original environment if the new one fail to work.

Replacing LDM with KDM

Skolelinux 3.0 is running LDM as a login manager. It uses a secure ssh tunnel to log in. When using KDM a switch to XDMCP is neccesary. XDMCP uses less CPU ressources on the clients and on the server.

/!\ Warning: XDMCP does not use encryption. Passwords will travel in cleartext over the network, as well as anything else.

/!\ Note: local devices with ltspfs will stop working without LDM.

To check if XDMCP is running, run this command from a workstation:

 X -query ltspserverXX

If you are on the thin client network, please run this command:

 X -query

The goal is to let your "real" thin client to contact the xdmcp-server on the net (given a standard Skolelinux configuration).

If by some reason xdmcp is accessible on your server which runs KDM , please add the following to /etc/kde3/kdm/Xaccess

 * # any host can get a login window

The star before the comment '#' is important, rest is a comment of course :)

Then turn on xdmcp in kdm with the command:

 sudo update-ini-file /etc/kde3/kdm/kdmrc Xdmcp Enable true

At the end please restart kdm by running:

 sudo invoke-rc.d kdm restart

(in courtesy of Finn-Arne Johansen)

Extending the static IP Range

1. Add entries for static hosts for DNS by editing these two files:


Example: You want to extend the range from 50 up to 100 clients (static00-static99). In db.intern you would define

$GENERATE 0-99 static${0,2}             A       10.0.2.${50}
$GENERATE 50-155 dhcp{100,3}            A       10.0.2.${150}

and accordingly in db.10

$GENERATE 0-99 ${50}.2                  PTR     static${0,2}.intern.
$GENERATE 50-155 ${150}.2               PTR     dhcp${100,3}.intern.

After changing the configuration bind needs to be restarted with /etc/init.d/bind9 restart.

2. Adapt the range of freely available hosts in /etc/dhcp3/dhcpd.conf

  subnet netmask {

Also check whether you have to delete some entries in /var/lib/dhcp3/dhcpd.leases to revoke offered leases in within your extended static range.

Finally restart the DHCP server as well with /etc/init.d/dhcp3-server restart.

Connecting Windows machines to the network / Windows integration

Joining the domain

For Windows clients the Windows domain "SKOLELINUX" is available to be joined. A special service called Samba, installed on the main-server tjener, enables Windows clients to store profiles and userdata and also authenticates the users during the login.

In order to make Windows clients join the domain some (few) steps are required:

1. Create a user with membership in the "admins" group (if not already existing)

  • In order to be able to join the "SKOLELINUX" domain a member of the admins group needs to authorize the process. If not yet existing, a user with that membership needs to be added (for more information see <link to lwat docu>). The user "root" will not work, because there is no password for root in Samba.

2. Configure the Windows client as static host

  • When joining a samba domain some special data is stored on the domain controller (tjener). This data is needed to recognize the Windows client later as being allowed to authenticate users. In order to enable Samba to store this data, Samba requires an static host configuration to be present. This could be added by using the LWAT web interface (see also <link to lwat>). When adding the static host configuration it is important to check the "Samba host" option, otherwise will lack the required data to be able to join the domain.

3. On the Windows client: Make sure the network and system configuration matches the data stored on tjener (hostname and ip configuration).

  • It's really important, that the Windows hosts have the same data, otherwise Samba will not find the host added in step 2.

4. Join the domain as usual using the user added in step 1.

  • Depending on the version and language of you Windows installation, you should find the configuration about the domain or workgroup of your system somewhere in the system properties. A freshly installed Windows system should belong to a default workgroup. You can join the domain by selecting "Domain" instead of "Workgroup" and entering SKOLELINUX as new domain. Pressing enter will then open a new window, where the login data of the user created in step 1. can be entered. After some time the Windows client opens a popup window with a welcome message. After the obligatory reboot the loginscreen offers a option to login into the domain.

Windows will sync the profile of domain users on every login and logout. Depending on how much data stored in the profile this could take some time. To minimize the time needed, one should deactivate things like local cache in browsers (you could use the squid proxycache installed on tjener instead) and save file into the H: volume instead of "Own files".

User groups in Windows

Groupmaps must also be added for any other user groups you add through lwat. If you want your user groups to be available in Windows, eg for netlogon scripts or other group dependant actions, you can add them using variations of the following command. Samba will function without these groupmaps, but Windows machines won't be group aware.

/usr/bin/net groupmap add unixgroup=students \
             type=domain ntgroup="students" \
             comment="All students in the school"

If you want to check user groups on Windows, you need to download the tool IFMEMBER.EXE from Microsoft. Then you can use this for example in the logon script which resides on tjener in /etc/samba/netlogon/LOGON.BAT.

XP home

Users bringing in their XP home laptop can still connect to Tjener using their skolelinux credentials, provided the workgroup is set to SKOLELINUX. However, they may need to disable the windows firewall before Tjener will appear in Network Neighbourhood (or whatever its called now).

Managing roaming profiles

Roaming profiles contain user work environments, which include the desktop items and settings. Some examples of these environments are personal files, desktop icons and menus, screen colors, mouse settings, window size and position, application configurations and network and printer connections. Roaming profiles are available wherever the user logs on, provided the server is available.

Since the profile is copied from the server to the machine during logon, and copied back to the server during logout, a large profile can make windows login/logout painfully slow. There can be many reasons for a large profile, but the most common problems is that users save their files on the windows desktop or in the My Documents folder instead of in their homedir. Also some badly designed programs use the profile for scratch space, and other data.

The educational approach: One way to deal with to large profiles is to explain the situation for the users. Tell them not to store huge files on the desktop and if they fail to listen it's their own fault when login is slow.

Tweaking the profile: A different way to deal with the problem is to remove parts of the profile, and redirect other parts to regular file storage. This moves the work load from the users to the administrator, while adding complexity to the installation. There are at least three ways to edit the parts that are removed from the roaming profile.

Using machine policies

Machine policies can be edited and copied to all the other computers.

  1. Pick a freshly installed Windows computer, and run gpedit.msc
  2. Under the selection User Configuration -> Administrative Templates -> System -> User Profiles -> Exclude directories in roaming profile, you can enter a semicolon separated string of directories to exclude from the profile, the directories are internationalized and must be written in your own language the way they are in the profile. Example of directories to exclude are

    • log
    • Locale settings
    • Temporary Internet Files
    • My Documents
    • Application Data
    • Temporary Internet Files
  3. Save your changes, and exit the editor.
  4. Copy c:\windows\system32\GroupPolicy to all other windows machines.

    • It's a good idea to copy it to your windows os deployment system to have it included at install time.

Using global policies

By using the legacy windows policy editor (poledit.exe), you can can create a Policy file (NTConfig.pol) file and put it in your netlogon share on tjener. This has the advantage of working almost instantly on all windows machines.

Since some time the policy editor standalone download has been removed from the Microsoft website, but it's still available as part of the ORK Tools.

With poledit.exe you can create .pol files. If you put such a file on tjener as /etc/samba/netlogon/NTLOGON.POL it will be read by the windows machine automatically and temporarily overwrite the registry, thus applying the changes.

To make sensible use of poledit.exe you also need to download appriate .adm files for your operating system and applications, otherwise you cannot define many settings in poledit.exe.

Be aware that the new group policy tools, gpedit.msc and gpmc.msc cannot create .pol files, they either only work for the local machine or need an active directory server.

If you understand german, is a very good website on this topic.

Editing Windows registry

You can edit the registry of the local computer, and copy this registry key to other computers

  1. Start the Registry Editor.
  2. Navigate to HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon

  3. Use the menu Edit menu->New->String Value.

  4. Call it ExcludeProfileDirs

  5. Enter a semicolon sepatated string of paths to exclude. (same way as machine policy)

Now you can choose to export this registry key as a .reg file, Mark a selection, right click and select export. Save the file and you can double click it, or add it to a script to spread it to other machines.


Redirecting parts of profile

Sometimes just removing the directory from the profile is not enough. You may experience that users loose files because they mistakenly save things into my documents, when this is not saved in the profiles. Also you may want to redirect the directories some badly programed applications use to normal network shares.

Using machine policies

Everything under Using machine policies above applies. You edit using gpedit.msc and copy the Policy to all machines The redirection should be available under User Configuration -> Windows Settings->Folder Redirection Things that can be nice to redirect are Desktop or My Documents.

One thing to remember is that if you enable folder redirection, those folders are automatically added to the syncroniced folders list. If you do not want this, you should also disable that in following

  • User Configuration -> Administrative Templates -> Network -> Offline Files

  • Computer Configuration -> Administrative Templates -> Network -> Offline Files

Avoiding roaming profiles

Using a local policy

Using local policies you can disable roaming profile on individual machines. This is often wanted on special machines, for instance on dedicated machines, or machines that have lower then usual bandwith.

You can use the machine policy method describe above, the key is in

  • Administrative Templates -> system -> User Profiles -> Only allow local profiles

altering samba config

By editing the samba config you can disable roaming profiles for the entire network. Perhaps everyone have their own dedicated machine? and nobody else is allowed to touch it. To disable the roaming profiles for the entire network you can alter the smb.conf file on tjener and unset the logon path and logon home variables, and restart samba.

logon path = ""
logon home = ""

Remote Desktops with RDP, VNC, NX or Citrix

Some municipalities provide a remote desktop solution so that students and teachers can access Skolelinux from their home computer running Windows, Mac or Linux.

  • RDP - the easiest way to access Windows terminal server. Just install the rdesktop package.

  • VNC client (Virtual Network Computer) gives access to Skolelinux remotely. Just install the xvncviewer package.

  • NX graphical client gives students and teachers access to Skolelinux remotely on Windows, Mac or Linux PC. One municipality in Norway has provided NX support to all their students since 2005. They report that the solution is stable.
  • Citrix ICA client HowTo to access Windows terminal server from Skolelinux.

HowTos from

The HowTos from are either user- or developer-specific. Let's move the user-specific HowTos over here (and delete them over there)! (But first ask the authors (see the history of those pages to find them) if they are fine with moving the howto and putting it under the GPL.)


HowTos for teaching and learning


Run aptitude install moodle as root to install moodle.

Moodle is a course management system (CMS) - a free, Open Source software package designed using sound pedagogical principles, to help educators create effective online learning communities. You can download and use it on any computer you have handy (including webhosts), yet it can scale from a single-teacher site to a University with 200,000 students. Some schools in France use moodle to keep track of students' facilities and credit points.

See for more information on Moodle.

Monitoring pupils

Some schools use control tools like Controlaula or Italc to supervise their students.

Take a look at their wiki:

apt-get install italc-client italc-master

/!\ Warning: monitoring humans might be unethical and illegal in your jurisdiction.

Restricting pupils network access

Some schools use squidguard or dansguardian to restrict internet access.

/!\ Warning: restricting access to information or freedom of speech might be unethical and illegal in your jurisdiction.

Installing swi-prolog on etch

swi-prolog was available in sarge, but was not part of etch. But you can just install the version from sarge on a etch system.

/!\ Warning: The software you install has no trust path. Software installed with apt-get is cryptographically signed to ensure a trust path.

# swi-prolog depends on libreadline4, also not in etch
dpkg -i libreadline4_4.3-11_i386.deb  

dpkg -i swi-prolog_5.2.13-1_i386.deb

swi-prolog-doc is part of etch :-)

HowTos from

The HowTos from are either user- or developer-specific. Let's move the user-specific HowTos over here (and delete them over there)! (But first ask the authors (see the history of those pages to find them) if they are fine with moving the howto and putting it under the GPL.)



Let us know you exist

There are Debian Edu users all over the world. A very easy form of contribution is to let us know you exist and use Debian Edu - this motivates us very much and therefore is already a valuable contribution. :-)

The Debian Edu projects provide a database of schools and users of the system to help the users find each other, and also to have an idea about where the users of the distribution are located. Please let us know about your installation, by registering in this database. To register your school, use this web form.

Contribute locally

Currently there are local teams in Norway, Germany, France and in the region of Extremadura in Spain. "Isolated" contributors and users exist in Greece, the Netherlands, Japan and elsewhere.

The support chapter explains and links to localized ressources, as contribute and support are two sides of the same coin.

Contribute globally

Internationally we are organized in different teams working on different subjects.

The developer mailing list is most of the time our main medium for communication, though we have monthly meetings on IRC on #debian-edu on and less frequently even real gatherings, where we meet each other in person.

A good way to learn what is happening in the development of Debian Edu is to subscribe to the commit mailinglist.

Documentation writers and translators

This document needs your help! First and foremost, it is not finished yet: If you read it, you will notice various FIXMEs within the text. If you happen to know (a bit of) what needs to be explained there, please consider sharing your knowledge with us.

The source of the text is a wiki and can be edited with a simple webbrowser. Just go to and you can contribute easily. Note: An user account is needed to edit the pages, you need to create a wiki user first.

Another very good way to contribute and to help users is by translating software and documentation. Information how to translate this document can be found in the translation chapter of this book. Please consider to help the translation effort of this book!



Volunteer based support

in English

in Norwegian

in German

in French

in Spanish

Professional support

Lists of companies providing professional support are available from


Copyright and authors

This document is written and copyrighted by Holger Levsen (2007, 2008, 2009), Petter Reinholdtsen (2007, 2008), Daniel Heß (2007), Patrick Winnertz (2007), Knut Yrvin (2007), Ralf Gesellensetter (2007), Ronny Aasen (2007), Morten Werner Forsbring (2007), Bjarne Nielsen (2007, 2008) Nigel Barker (2007), José L. Redrejo Rodríguez (2007), John Bildoy (2007), Joakim Seeberg (2008) and Jürgen Leibner (2009) and is released under the GPL2 or any later version. Enjoy!

If you add content to it, please only do so if you are the author of it and plan to release it under the same conditions! Then add your name here and release it under the GPL2 or later version.

Translation copyright and authors

The Spanish translation is copyrighted by José L. Redrejo Rodríguez (2007) and is released under the GPL2 or any later version.

The Bokmål translation is copyrighted by Petter Reinholdtsen (2007), Håvard Korsvoll (2007, 2008) and Tore Skogly (2008) and is released under the GPL2 or any later version.

The German translation is copyrighted by Holger Levsen (2007), Patrick Winnertz (2007), Ralf Gesellensetter (2007), Roland F. Teichert (2007, 2008), Jürgen Leibner (2007), Ludger Sicking (2008) and Kai Hatje (2008) and is released under the GPL2 or any later version.

The Italian translation is copyrighted by Claudio Carboncini (2007, 2008, 2009) and is released under the GPL2 or any later version.

The French translation is copyrighted by Christophe Masson (2008) and the French l10n team (2009) and is released under the GPL2 or any later version.


Translations of this document

Fully translated versions of this document are not yet available. Incomplete translations for Italian, German, Norwegian Bokmål, French and Spanish exist, take a look for your language here.

HowTo translate this document

Translations of this document are kept in .po files like in many free software projects, read usr/share/doc/debian-edu-doc/README.debian-edu-etch-manual-translations for more information on this. Please read also read this, if you want to start/help translating this document.

To commit your translations you need to be a member of the alioth project debian-edu. To translate, you just need to check out some files from from svn (which can be done anonymously), create patches and send those to

You can checkout the debian-edu-doc source anonymously with the following command (you need to have the subversion package installed for this to work):

  • svn co svn://

Then edit the documentation/debian-edu-etch/debian-edu-etch-manual.$CC.po (where you replace $CC with your language code). There are many tools for translating available, we suggest to use kbabel.

Then you either commit the file directly to svn (if you have the rights to do so) or send the file to the mailinglist.

To update your local copy of the repository use the following command inside the debian-edu-doc directory:

  • svn up

Read /usr/share/doc/debian-edu-doc/README.debian-edu-etch-manual-translations to find information how to create a new .po file for your language if there is none yet, and how to update translations. If you are new to SVN, look at the SVN book, it has a chapter on the basic workflow with SVN.

Please report any problems.


Appendix A - The GNU Public License

Note to translators: there is no need to translate the GPL license text. 

Manual for Debian Edu etch 3.0 Codename "Terra"

Copyright (C) 2007-2009 Holger Levsen < > and others, see the Copyright chapter for the full list of copyright owners.

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.


Version 2, June 1991

Copyright (C) 1989, 1991 Free Software Foundation, Inc. 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.


0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you".

Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.

1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program.

You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.

2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:

  • a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.

    b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

    c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.)

These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.

In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.

3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:

  • a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

    b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

    c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)

The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code.

4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it.

6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.

7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.

If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances.

It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.

This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.

8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.

9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.

Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.

10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.






Appendix B - about Debian Edu Live CD/DVDs

Features of the Standalone image

  • Almost all packages from the Standalone profile
  • All packages from the laptop task
  • The KDE desktop profile for students/pupils.

Activating translations and regional support

To activate a specific translation, boot using locale=ll_CC.UTF-8 as a boot option, where ll_CC.UTF-8 is the locale name you want. To aciviate a given keyboard layout, use the keyb=KB option where KB is the wanted keyboard layout. More information on this feature is available from the live cd build script documentation. Here is a list of commonly used locale codes:

Language (Region)

Locale value

Keyboard layout

Norwegian Bokmål



Norwegian Nynorsk






French (France)



Greek (Greece)






Northern Sami (Norway)



A complete list of locale codes is available in /usr/share/i18n/SUPPORTED, but only the UTF-8 locales are supported by the live images. Not all locales have translations installed, though. The keyboard layout names can be found in /usr/share/keymaps/i386/.

Stuff to know

  • the password for the user is "user", root has no passwd set.

Known issues with the image

  • none known yet.


The image is 1.2 GiB and available using FTP, HTTP or rsync from at cd-etch-live/.