Testing DebianEdu with Incus

All the containers and VMs are connected by default to a bridge (usually named incusbr0), which provides them with DHCP and allows them to connect to the internet (acting like a gateway). However we need a gateway that does not provide DHCP, since the DHCP is going to be provided by the main server. This requirement is discussed in the docs.

In INCUS, a switch can be implemented by a virtual network. However we should make sure that this virtual network does not provide DHCP and has IP 10.0.0.1/8. We can do it like this:

Add it also to the trusted zone of firewalld:

According to the topology of the network, the main server is connected to an internal switch as well, which is used for the LTSP clients. So, let’s create another switch:

This network (switch1) should not provide DHCP, because it should be provided by the main server itself, so we have disabled it.

Let’s add it also to the trusted zone of firewalld:

In order to upgrade packages, first of all we need to modify /etc/apt/sources.list. Because we installed from a CD, it contains a source like this:

We should comment it out and make sure that it contains source lines like these:

Then, according to these instructions, we can do:

We can also do these things (optionally):

Let’s create a diskless VM, connected to switch1, that boots from the network interface:

The last command should give an output like this:

Now let’s start it.

It should start booting from the main server, through PXE, until we get the boot menu. Leave the default selection (diskless workstation) and press enter.

Stop it with: incus stop -f ltsp01

According to the network architecture diagram, we should be able to start a diskless client even if it is connected to switch0. Let’s test it:

On a diskless workstation, programs and applications run on the RAM of the client. For example when we start Firefox, it is loaded on the RAM of the client. Only the home directory is on the server (mounted with NFS).

On a thin client, on the other hand, everything runs on the server, only the display is shown to the client. For this reason we don’t need much RAM for a VM that simulates a thin client.

It would still work with -c limits.memory=256MB. By the way, the default value for this option is 1GB.

Let’s create an empty VM, with 25GB disk, connected to the main switch (switch0), which boots from the network:

On the iPXE boot menu select the first option (Install Debian Edu/amd64b). Then follow the installation steps and select the Workstation profile (which is selected by default).

After installation is done, shut it down, remove the boot priority from the network interface, and start it again:

We can login as user root, get a terminal, and install incus-agent like this:

Now that we installed incus-agent, we can access ws01 with the command incus shell ws01.

The DHCP of the main server can assign a hostname and a fixed IP to this workstation, but we need to register it first on GOsa. We can open the web interface of GOsa, go to "Systems" and add a workstation manually, but a more convenient way is to use the tool sitesummary2ldapdhcp from the server, like this:

The command sitesummary2ldapdhcp is going to ask for the root password, and it will add a workstation entry on LDAP. However this entry needs to be modified/customized. So, open it on GOsa and modify it as shown in the figure.

Now you can reboot the workstation and it will take the IP and hostname specified in GOsa.

However we can still login only as root, not as any user that is registed in Gosa. To enable this, we need to run this command on the workstation:

It is going to ask for the root password of the server, in order to copy the keytab file from the server to the workstation.

Now we can reboot the workstation and test that we are able to login as any user that is registered in GOsa. The home directory of the user is also mounted from the server.

If we want, for example, to remove the i386 installation option from the boot menu, we can edit /srv/tftp/ltsp/ltsp.ipxe on the main server and comment out this line:

If we want to change the desktop that is installed on the workstations, for example to LXQT, we can edit this part:

Other kernel options can be changed here as well, like the locale, keyboard keymap, etc.

The preseeding file that is used for installing workstations is /etc/debian-edu/www/debian-edu-install.dat. However the changes made there will be lost if we use debian-edu-pxeinstall. In order to make persistent changes we should add additional debconf values to the file /etc/debian-edu/www/debian-edu-install.dat.local.

Let’s try to add another thin client type:

This will create a chroot and SquashFS image for 32bit clients. The type of the thin client will be a minimal desktop with Mozilla and X2Go client. The iPXE menu will also be updated with a couple of new menu items.

For more details see:

Epoptes is a computer lab management and monitoring tool. We can install it on the main-server like this

The configuration of epoptes-client (SERVER=tjener) tells the clients to connect to the main-server, which means that we can access the Epoptes application only on the main-server.

We need to propagate these changes to the image of the diskless clients:

We also need to add to the group "epoptes" all the teachers that should be able to access the Epoptes application. We can do this from the GOsa interface, first by creating a new group named epoptes, with a fixed gid, and by adding to this group all the teachers.

It can be done from https://www/slbackup-php, but there is a catch: you cannot login without enabling root login on SSH:

I would recommend not to use the web interface at all. Instead, try to edit directly: /etc/slbackup/slbackup.conf. Also, try to learn how to use rdiff-backup, since this is the tool that is being used under the hood: man rdiff-backup.

If we check monitoring tools (from the first user account), https://www/munin/ and https://www/icingaweb2/, we will notice that some partitions are low on free disk space. By default, the installation does not use all of the available disk space, leaving some unused disk space, which can be later used to enlarge/resize the partitions that are low on disk space. This resize is done automatically for all the systems that are added to the netgroup fsautoresize-hosts. There is an hourly cron job that runs the command debian-edu-fsautoresize -n, which applies the rules on /usr/share/debian-edu-config/fsautoresizetab.

However the virtual machines that we use for testing have a minimal disk space, so there is not much backup space on them. Let’s try to enlarge them manually, and then see how to resize a partition.

All the containers and VMs are connected by default to a bridge (usually named incusbr0), which provides them with DHCP, DNS, and allows them to connect to the internet (acting like a gateway). However we need a gateway that does not provide DHCP, since the DHCP is going to be provided by the main server. This requirement is discussed in the docs. So, we are going to build a VM for the gateway, as shown in the network topology diagram.

This gateway needs to be connected to incusbr0 (which provides access to the internet) and to another switch, which connects it to the main server and to the LTSP servers. Let’s call it switch0.

When we start the installation from a base debian image (provided by the Incus infrastructure), it is faster and more convenient. One reason is that the base image already has the Incus agent installed by default, which makes its management easier. Another reason is that the installation process becomes scriptable (no manual intervention needed) and this is more suitable for testing purposes.

So, let’s see also how to install a main-server starting from a base debian image.

When you attach a removable device (USB, CDROM) to a diskless client, it will be automounted and be available on the client immediately, since the system is running on the client and has direct access to its hardware.

With an X2Go thin client it is not so easy because we are accessing the server remotely. There is already a configuration for the USB devices, which attaches them as network disks to the X2Go client, and makes them accessable via SSHFS. So, whenever a USB device is attached to a client machine, it will be automounted, and we can click the icon labeled "_usb0 (sshfs-disk)" on the desktop in order to access it. In this case we are actually accessing it remotely from the server, since everything on a thin client runs on the server.

If we want to do the same for a CDROM device, then we can follow the instructions described below.

We can test that it works like this: