197 lines
9.3 KiB
Markdown
197 lines
9.3 KiB
Markdown
---
|
|
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.
|