User:Riviera/Public moments/4 Nov 2024
Klankschool Landing page
Klankschool Funkwhale
Klankschool Calendar
Klankschool Gitea
Klankschool Webmail
Hello and welcome,
This talk is titled ‘The Klankschool Server in 15 minutes’. Over the next quarter of an hour, I will aim to give an overview of how the component parts of the server are pieced together. I will also speak about the wider context in which the server is situated alongside dispositions and attitudes informing my approach to system administration.
The machine itself is about a decade old, it’s a Mac Pro with an Intel Xeon CPU, 16 Gigabytes of RAM and a 512GB Hard Drive. Whilst it was made by Apple, it’s not running Mac OS. Instead, I have installed Arch Linux, a minimalist flavour of the GNU/Linux operating system on the machine. This distribution provides very new versions of software and receives frequent updates. In fact, every active piece of software on the server is Free / Libre or Open Source. I only use such software: It is integral to my research and practice both as subject matter and modus operandi.
One piece of software crucial to understanding the setup of the Klankschool server is called Incus. Incus makes it possible to run several different Linux operating systems on top of the main OS. These operating systems are containerised and there are currently ten of these running inside the Klankschool server. There are several practical reasons why I chose to use Incus. Firstly, unlike Docker containers, Incus containers can make use of systemd without requiring additional privileges. Systemd is a background task or daemon manager for many Linux distributions. Secondly, Incus can launch a variety of operating systems, such as Alpine, Arch, Debian, Ubuntu and others. Different pieces of software are easier, or more appropriate, to set up on particular operating systems. Gitea, for example, is simple to setup on Arch, whereas Funkwhale is simple to setup on Debian. Given that I’m containerising everything, other pieces of software, like HAProxy, are appropriate to run inside super lightweight distributions like Alpine. Third, in the event that someone hacks into the system, they would end up inside a container. The container is separated from other containers and the host operating system, which makes the setup more secure. Fourth, the klankschool server might not run on the Mac Pro forever, perhaps it will eventually move to an ethical data center somewhere, or another computer. Indeed, at some point, the Mac Pro will have to return to the studio, probably by the end of the academic year. Incus data can be migrated to another computer over the internet. This makes the server setup more robust as it becomes increasingly hardware independent. For all these reasons, containers make it simpler to change ones mind about how things might be set up, introducing additional flexibility into system administration.
So, what happens when you visit a website such as http://funk.klank.school? In short, the domain name is translated into an IP address through the Domain Name System (DNS). The IP address which funk.klank.school resolves to at the DNS level corresponds to the public IP of the router at my flat. The HTTP communication takes place on port 80, HTTPS goes via port 443. I have set up port forwarding on the router so that requests arriving on these ports get sent to the local IP address of the server. Thus, your request arrives at port 80 on the server. I have correspondingly mapped port 80 and port 443 on the server to ports 80 and 443 on the container running HAProxy. This software is a load-balancer and reverse proxy. It is one of many services running inside different containers on the server. The HAProxy service is configured to pass the incoming traffic for funk.klank.school to the funkwhale container. In the case of funk.klank.school the connection is redirected to HTTPS inside the haproxy container. Lastly, there’s a web server running inside the funkwhale container which picks up the secure traffic and returns an appropriate webpage.
Each container runs a specific service or set of related services. The services running inside each container are as follows:
- HAProxy: a load-balancer and reverse proxy
- Funkwhale: an audio sharing platform with Fediverse integration
- Gancio: A public facing calendar with a low threshold of participation and fediverse integration
- PostgreSQL: a database manager
- Gitea: a Git platform
- Codeberg Pages: a Gitea plugin which allows Klankschool members to host static websites on subdomains.
- Mail Services: such as postfix, dovecot and postfixadmin
- Roundcube: a webmail client
- pgadmin 4: a browser based interface for administrating postgres databases
- flok: A collaborative live coding environment
Some of these services are for members to make and share sounds or projects, others are for administrative, communicative or convenience purposes.
Linux containers are of key importance to the infrastructure of the Klankschool server. These containers are networked and can therefore connect to databases or direct traffic to websites stored in other containers. These pieces of technology are all linked together in various ways. I have endeavoured to illustrate these connections in a graph which I will explain. Orange nodes are containers, yellow nodes are databases and red nodes are websites. The yellow edges illustrate the connection between the container running postgresql and various databases. They show that this container is responsible for these databases. The green edges indicate which containers access which databases. I have omitted the connections between the pgadmin container and all the databases. Introducing these edges makes the graph unnecessarily complicated. The red edges connect websites and containers. Broadly speaking, these edges are sites enabled in a given web server, such as apache2 or nginx, in a given container. Yes, there are almost as many web servers as there are containers.
The klank.school website, which is hosted in a git repository on code.klank.school, is a borderline case. It should be noted that the pages container shares a pink edge with the haproxy container. The pink edges are indicative of HAProxy backends which operate in Transmission Control Protocol (TCP) mode. There is another pink edge between the haproxy and mailtwo container. In the long run, I may turn all the blue edges, which indicate HTTP HAProxy backends, into pink edges. This has to do with Secure Socket Layer (SSL) termination. SSL certificates on HTTP backends need to be concatenated in a specific way for HAProxy. The certificates for websites using an HTTP backend are stored in the HAProxy container. When those certificates expire, manual intervention will be required and this is likely to result in some downtime on those websites. By contrast, the SSL certificates for websites accessible via TCP backends are stored in the mailtwo and pages container respectively. They automatically renew without any problems.
So far, I have spoken about the inner workings of the Klankschool server and indicated towards some tasks on my to-do list. Other tasks on my to-do list include automating snapshots of containers and sorting out a backup system using BORG. I’d also like to reduce the number of Debian containers wherever possible. As I mentioned earlier, HAProxy could run effectively inside an Alpine Linux container, but it is currently running in a Debian machine.
I would also like to change the DNS provider. The domain name klank.school was registered with Cloudflare and this is a significant shortcoming. The wishlist for trans*feminist servers states that “Trans*feminist servers … will towards non-extractive relationships, but in the meantime, are accountable for the ones they are complicit with”. It may be that another strike against the cloud is called for in the near future. Suppose this were to happen whilst the Klankschool server is making use of Cloudflare’s DNS services. In that scenario, I would take the Klankschool server offline for the duration of the strike. To avoid this inconvenience, I will look into transferring the domain to another DNS service provider. Curiously enough, this may have an impact on the process of renewing SSL certificates, specifically those behind TCP backends. The process of obtaining these certificates made use of Cloudflare’s API. I don’t know how switching DNS providers may impact renewal requests.