After discussing the basic scheme of a telecentre, let’s do a brief overview of the major developments we have made to the Linux distribution that runs in our telecentres. It is a derivative of the distro used in the Guadalinfo centers, and based on Ubuntu / Debian. Again, my appreciation to Alfredo Matas, Javier Hernandez, David Teyssiere, Enrique Jimenez, Jose Ignacio Alvarez and Roberto C. Morano, developers of this project with whom I had the great pleasure of working and the privilege of learning from them. Here we go!
For the clients in the telecentres we have developed an Ubuntu derivative based on the current distribution running at the Guadalinfo centres, together with a series of improvements made to adapt it to the new requisites. These changes consists in the elimination of legacy configurations from Guadalinfo, and the application of specific settings for this project.
The first change that stands out is obviously the graphic branding. The distribution usplash, GDM theme, desktop theme and, of course, the wallpaper, has been changed.
We have included the logos of the various agencies involved in the project, but overall the system has remained running with the Guadalinfo general aesthetics.
All these changes are contained in a single Debian package (I’ll explain the metapackage structure of the distro in a future post).
The system is distributed as a live system with a custom installer. This installer includes the preseeds needed so the installation does not need any user intervention, beyond launching the installation process.
In addition, it performs the tasks needed to prepare the restoration system – generate a partimage image of the system partition, specifically – and creates the essential users.
Our first approach to the restoration of the system consisted in enabling storage in the router of the centre and perform a fully automated Debian Installer booting with PXE. But not being possible to use wired ethernet at the centres, network boot was discarded. We have therefore opted for a system that, while not covering the corruption of disk partitions or the partition table itself, it does help in resolving certain disk errors.
Notice that the only event covered are the file system errors: corruption of the system by its continued use is not possible when users have no administrative rights and the home directories are regenerated with each session.
Well, what we have implemented consists of a 4 partitions partitioning scheme:
- The first partition contains the installed system, nothing else.
- The second partition is mounted at /var/cache/apt, so the updates are stored in an independent partition.
- The third partition contains a partimage image of the system partition.
- The fourth partition contains the Linux swap.
The third partition contains everything needed to start a restoration process. This process dumps the image of the system partition to the first partition, and performs an integrity check on the partition that hosts the updates. This partition is not mounted in the normal operation of the system, to minimize the potential of being damaged, for example during an improper shutdown.
The system includes a grub boot option that starts the process of restoration. Once restored, the system — having already downloaded the updates in a different partition — updates quickly with little bandwidth consumption.
The generation of the system partition image is performed during the final step of the installation process.
GDM with bulletin board
Other telecentres have staff dedicated to management, training, informing users and so on. This dedicated staff is also the main communication channel between users and the project team: they notify the users in case of updates that can affect the behavior of the system, the installation of new software or the appearance of a bug. Therefore, in other telecentres there is no need for a communication system between the project team and the users.
However, the network of telecentres that we are dealing with has no dedicated staff in the centres. Whether installing a new application, or a significant bug is detected, the operating system must have the means to transmit such information in a clear and visible way. For this purpose, we have developed a “bulletin board” shown in GDM, to the left of the login window.
This panel is implemented in Python + GTK, and contains a browser widget that loads a flat html file hosted at our central server. It can be folded and unfolded (always starts in the latter state) and is launched through a .desktop file in /usr/share/gdm/autostart/LoginWindow/
In the case of user registration, we have encountered the same problem as with the bulletin board: a feature that, having no staff on site, users should be able to perform independently. Although I will discuss the users management in more detail in a future post, I will briefly say that users are created in a remote service, not locally in the system, and their sociodemographic data (if the user decides to provide it) is stored anonymized for statistical treatment by the project direction.
Again, the registration tool has been made in Python + GTK, and is launched through a button in the GDM screen. This causes the application to acquire the GDM theme, which is why it takes the dark colors you can see in the screenshot. Of the entire process of developing this application, its integration with GDM has been the hardest, having to make changes even in GDM code .
However, we consider that the most innovative development has been the implementation of the authentication system. Through a PAM module and a dbus service, the system authenticates using a webservice, and creates the local user if the login is correct (as I indicated before, I shall discuss this in more detail in future posts). The users are created without administrative privileges.
Deletion of user home directory
Lacking a central server at the centre, which allows a central storage of the user data (as in Guadalinfo), and for reasons of privacy and the prevention of disk space exhaustion, a deletion of the user home directory is performed both at login and logout, restoring the home directory from /etc/skel.
Why two and not just one deletion?
Imagine we just delete the home directory at login time. A user logs in, download 10 GB of data and logs out. These 10 GB disk remain until the user logs in again, but what if the user does not return to the center? Those 10 GB are taking up space. Now imagine the same thing with 30 or 40 users, and you will realize we have a problem.
Consider the opposite case: we perform the deletion just at logout time. A user arrives, download 10 GB and for some reason there is an improper logout, for example a power outage, common in small populations. We face the same problem as in the previous case.
Therefore, and since it is neither difficult to implement nor a heavy task for the hardware, we decided to perform the deletion both at the beginning and the end of the session.
To manage network connections, instead of using the classic /etc/network/interfaces we have chosen to make use of the NetworkManager’ “system connections” functionality. So, two files has been created in /etc/NetworkManager/system-connections.d/ that configures two system connections: the official WiFi network of the telecentres, and a wired one. Important to note that this files permissions must be 600, being root the owner user: this gave us the odd headache.
The use of NetworkManager allows for multiple connection options (several configurations for multiple WiFi networks, for example, or a WiFi connection profile together with a wired one), and the system switches automatically to one or the other depending on the availability of it. In addition, the connection applet provides information to the user facilitating the diagnosis of connectivity issues (specifically those in which we can not access remotely!).
Cutting of NetworkManager
Although we use NetworkManager, the network connections should not be managed by users. To do so we have proceeded to “cut off” certain features of NetworkManager.
The ability to create new connections have been disabled through PolicyKit. However, the connections management does not support PolicyKit and had to be disabled via DBus, cutting off access to certain methods from the NetworkManager applet to the NetworkManager service. The applet is not ready to run this way, so sometimes it crashes: it is an open bug still not fixed.
With regard to the selection of applications there is nothing special to note, with the exception of accessibility support. We have included Guadalinfo developments, which consists of a serie of accessibility tools that are not usually included in a “standard” Linux distribution. Javier Hernandez, member of our team and Orca and Gnome developer, has been responsible for the system accessibility support.
So, any questions? 🙂