Testing DebianEdu with LXD

On the server (ubuntu:22.04) I have installed LXD with snap, like this:

Somehow, firewalld and docker interfere with the network communication in the virtual environment that we are creating, so that they cannot get an IP from DHCP, and cannot ping to the internet. The problem is that by default, an interface that is not added to any zone will be handled by the public zone of firewalld. This zone is meant for the interfaces that are connected to the internet, and is restricted by default. For example DHCP connections are not allowed.

We can fix this by adding the LXD interfaces to the zone trusted, which allows everything:

Besides this, forwarding from and to these interfaces needs to be enabled in the firewall, but sometimes it might be blocked (for example if you install Docker, it will set the policy of the FORWARD chain to DROP). This can be fixed by adding a direct rule with firewall-cmd, like this:

This will enable forwarding for all the interfaces, lxdbr0 and the ones that we will create later.

We need Xpra to access the graphical displays (VGA consoles) of the virtual machines remotely (for example from a laptop).

To start Xpra we run the script xpra-start.sh on the server:

To connect to it we run the script xpra-attach.sh from the client (laptop). We should get a tilix terminal by default, but if not, we can start it from the Xpra icon (click it and keep it pressed, then go to "Server", then to "Run a command" and release the mouse button, type "tilix" and press Enter). From this terminal we can type LXC commands, and when we try to access the display of a virtual machine it will be shown on the laptop.

All the containers and VMs are connected by default to a bridge (usually named lxdbr0), 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 LXC, 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: lxc 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 lxd-agent like this:

Now that we installed lxd-agent, we can access ws01 with the command lxc exec ws01 — bash.

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:

Here we are using the MAC address of the workstation, which we can find with a command 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 apply 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.

We can connect to the LXD from a local machine, for example a laptop, and manage it remotely.

We can use Xpra in order to access the VGA console of a virtual machine remotely. We need to install it both on the server and on the client (on the laptop):

On the server we also need to install the package virt-viewer (which provides remote-viewer) and some other required packages:

Then we can start Xpra on the server, like this:

From the client, we can attach to the Xpra server like this:

Now, from the tmux on the server we can start any GUI application, and it will be displayed on the local machine.

All the containers and VMs are connected by default to a bridge (usually named lxdbr0), 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 lxdbr0 (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 LXD infrastructure), it is faster and more convenient. One reason is that the base image already has the LXD 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: