diff --git a/src/content/newsletters/index.md b/src/content/newsletters/index.md index 228927f..aea301b 100644 --- a/src/content/newsletters/index.md +++ b/src/content/newsletters/index.md @@ -2,5 +2,6 @@ title: The newsletters published: false nested: 'newsletters' + --- Klank.school newsletters \ No newline at end of file diff --git a/src/content/newsletters/server_update_two.md b/src/content/newsletters/server_update_two.md index d24f3db..d98170d 100644 --- a/src/content/newsletters/server_update_two.md +++ b/src/content/newsletters/server_update_two.md @@ -1,22 +1,36 @@ --- -title: A title for my fun newsletter +title: Klankbord Digest February 2025 published: false template: newsletter --- -I'd like to begin this month's Klankbord Digest with a server update. +# 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 server began as a prototype on a Mac Pro Trash Bin computer -which I borrowed from a university. It had 16 GB of RAM and for this +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. So, I set up a bunch of 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 different operating systems on top of the host -operating system. And this was no longer easily doable with LXD. +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, @@ -24,56 +38,60 @@ 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 -well-suited to those operating systems. 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. However, the OpenProject instance will not make a -reappearance. Partly because it used 1.6 GB of memory. This was not an -issue on the Trashbin, but was an issue on the next server. +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_ around Christmas. 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 -it 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 +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 KVMs, or Kernel Virtual Machines. As I wasn't -doing that it was already suffering from mis-configuration issues. +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, it was an `fdisk` -situation. I set aside eight GB of SWAP space and a 120 GB root -partition, which makes limited sense. No way was there going to be 120 -GB worth of software on the machine. More likely: it was going to run -out of RAM. 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 four gigabytes 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! +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 @@ -88,7 +106,7 @@ depicted in the following diagram. o | | code.klank.school - | o + | o | | +-----------+---------+-------------------------------------+ | | | | @@ -120,17 +138,59 @@ 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 are a downside of containers. Thus, I preferred to keep -it simple because the environments were 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 +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 defund the cloud, there's a new DNS provider. +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.