Newsletter/src/content/newsletters/server_update_two.md

---
title: Klankbord Digest February 2025
published: false
template: newsletter
---

# Klankbord Digest February 2025

## Recent Events

{{ events passed }}

## Upcoming Events

{{ events upcoming }}

## Server Update

*By Riviera*

Let's backtrack a bit to understand how the current circumstances
arose. The Klankschool server began as a prototype on a Mac Pro "Trash
Bin" computer which I borrowed. It had 16 GB of RAM and for this
reason, it was possible to run loads of software on the machine.  For
this purpose, I used Incus, which is a Linux Container Management
System.  It's a fork of LXD, which is made by Canonical. Canonical
decided to make LXD proprietary a while ago, and so Incus was the
natural alternative. I set up a bunch of system containers inside of
this machine and these were capable of communicating with each
other. There was an advantage to using Incus over using LXD. For
example, it was possible to launch operating systems other than Ubuntu
on top of the host operating system. And this was no longer easily
doable with LXD.

I thought it would be a good idea to install Arch Linux on the Trash
Bin as the host operating system. This was probably not a good idea,
because Arch Linux offers very up-to-date software and is constantly
changing. If software is not kept up-to-date, things break. And when
the software is updated, sometimes things break. In any case, I wanted
to be able to launch different operating systems because various
pieces of software that I wanted to run on the machine were packaged
for those operating systems and available in the repositories. For
example, I wanted to run an OpenProject instance for collaborative
project management. In the past I attempted to build this Ruby on the
Rails application from source inside a Ubuntu container. I found that
that simply didn't work in the long-run. The background jobs processor
wasn't working at all. Everything got clogged up, and it
crashed. Slowly. And that was the end of that, because the system was
simply unusable. Thus, running OpenProject in a Debian environment,
without running Debian on the machine itself, was the main reason why
I wanted to run Incus. At present, the OpenProject is offline,
however, and will not make a reappearance. Partly because it has been
replaced by
[Kanboard](https://todo.klank.school/public/board/fa03d54c293e0b2a65120c985ef070ad3e08e499b66a7c83c177e5b3488e),
partly because it used 1.6GB of memory. The latter was not an issue on
the Trashbin, but was an issue on the next server.

Which brings me to a discussion of the next machine: a second-hand
Supermicro, which I picked up from v2\_ in late December. This
machine, it turns out, used 90 watts of electricity per hour, which is
a lot.  For whatever reason, the fan was running at full blast all the
time.  Everyone who saw it said it shouldn't be doing that. But it was
doing that and it wasn't clear why. In any case, the task as I saw it,
before I understood how much electricity this thing was consuming, was
to transfer the containers from the Trashbin to the Supermicro
machine. There were many containers and I wasn't going to use all of
them. Using a laptop and a VPN and an Ethernet cable, I was able to
transfer the required containers to the Supermicro
server. Technically, when running different operating systems with
Incus it's better to use Kernel Virtual Machines. As I wasn't doing
that it was already suffering from mis-configuration issues.

Furthermore, I decided to install Arch Linux on the Supermicro machine
as well. There was a bit of complexity involved in booting the server,
because it needed to be network booted, and that was something I had
not previously encountered. It was quite the adventure but I set it up
hastily. When I installed the operating system, I used `fdisk` to
partition the hard drives. I set aside 8GB of swap space and a 120GB
root partition, which makes limited sense. No way was there going to
be 120GB worth of software on the machine. More likely: it was going
to run out of memory. At least things were up and running at this
point.  There was the OpenProject. There was a live coding system,
Flok.  There was a SFTP server.  There was a container for the
websites (why not just use `/var/www/`...?). There was a Gitea
instance and a Gitea runner.  There was a container for the PostgreSQL
databases. And, finally, one for the calendar also.  These were all
online at one point and using up a lot of memory. The Supermicro
server only had 4GB of memory. Unsurprisingly, it could not handle all
of this and crashed. Therefore migrating some of the data / processes
elsewhere was required. The primary reason for this was to reduce
memory consumption. Accordingly the
[calendar](https://calendar.klank.school) moved to a VPS in Graz,
Austria. This is now online and should stay online as long as the VPS
is going!

In any case, the supermicro server joined the Varia hub. Very
exciting. Everything was routed through a VPN, and I had to
reconfigure various web servers inside several containers in order to
make it work as expected. One advantage of using system containers on
a per-application basis is that a more granular picture of web
requests can be assembled. Each container had its own web server as
depicted in the following diagram.

```
    live.klank.school
            o
            |
            |  code.klank.school
            |         o
            |         |
+-----------+---------+-------------------------------------+
|           |         |                                     |
|   +-------+---------+-----+   +-------------------------+ |
|   | B     |         |     |   | B                       | |
|   | O +---+---------+--+  |   | O  +-------+  +-------+ | |
|   | X |   |         |  |  |   | X  | Nginx |  | Gitea | | |
| K |   |   o HAProxy o--+--+---+----+---o---+--+---o   | | |
| L | O |   |            |  |   | T  |       |  |       | | |
| A | N +---+------------+  |   | H  +-------+  +-------+ | |
| N | E     |               |   | R                       | |
| K +-------+---------------+   | E                       | |
|           |                   | E                       | |
| S         |                   +-------------------------+ |
| E +-------+------------------+                            |
| R | B     |                  | each BOX is a container    |
| V | O  +--+----+   +------+  |                            |
| E | X  |  |    |   | Flok |  | o---o is a web request     |
| R |    |  o----+---+-o    |  |                            |
|   | T  | Nginx |   |      |  |                            |
|   | W  +-------+   +------+  |                            |
|   | O                        |                            | 
|   +--------------------------+                            |
+-----------------------------------------------------------+

```

Despite the advantages of using containers, the decision was made to
stop using them. Some might say to use Docker instead, but I don't
think it makes a difference. There's no need to containerise all the
services on a machine. Excessive complexity and surprising
dependencies beytween containers are a downside of this
technology. Thus, I preferred to keep it simple because the overall
situation was becoming a messy labyrinth of proxy devices, system
containers and storage units. I understood what was going on but
no-one else did. I wanted to change this, but couldn't find quite the
right moment to do so. And didn't. So I simply pulled the plug on the
Supermicro server. To be honest, I was having a bit of a strange week
when I made this decision. However, it was the right decision to make,
along with changing the DNS provider. March 8th was a deadline which I
set for myself to change the DNS provider. This was insofar that, for
the past couple of years, March 8th has been a day of International
Trans*Feminist anti-colonial Counter-cloud action. Thus, in an effort
to move away from the cloud, there's a new DNS provider and a
continued emphasis on self hosting.

To that end, the Klankschool system administrators are gradually
getting services online again. For example, the
[Gitea](https://code.klank.school) is back online again. This time on
a computer running Debian, an HP Compaq with, at present, 6GB of
RAM. It's also an upgrade in terms of energy consumption because the
machine utilises 30 Watts per hour, which is three times more
efficient than the Supermicro machine. Moreover, the hard drive is
encrypted and uses Logical Volume Management rather than `fdisk`. This
method is more sustainable in the long run and is a gain in terms of
data security.

---

## FAQs

### Can I host my website on [klank.school](https://klank.school)?

Certainly, please send an email to
[computer@klank.school](mailto:computer@klank.school) to discuss your
needs.

### Can I get an account on [code.klank.school](https://code.klank.school)?

Also yes, send an email to
[computer@klank.school](mailto:computer@klank.school) if you're
looking for somewhere to publish your code.

### Does Klankschool have a collaborative live coding environment?

Much data was dropped in the process of switching from the Supermicro
machine to the HP Compaq. There was a [flok](https://flok.cc) at
[live.klank.school](https://live.klank.school). It's offline at the
moment and will make a re-appearance soon.

### Is Klankschool still becoming a datacenter? 

No

### Does Klankschool have a privacy policy?

It's in the works - watch this space.