In my latest blog post “Nginx HTTP/3 proxy server displays content from the wrong virtual host,” I included a diagram from Diagrams.net / Drawio, which is an SVG file.
When you export your diagram from Draw.io, you can choose whether you want to apply a light or dark color theme to the exported graphic. I usually choose the light one here so that the diagram fits well with the light default theme of thomas-leister.de. But how do I deal with this in the dark version of my blog? Users automatically see the dark theme if they have set their operating system accordingly. I wondered if there was an easy way to convert the light SVG graphics to dark versions if necessary. After all, CSS now supports filter, right?
At the end of May 2025, I published the metalhead.club song via a Faircamp website at music.metalhead.club. However, not all users were able to follow my links to the Faircamp site without problems. In a few cases, users reported at least one of the following errors to me:
- When users accessed the album page: Error 404 - not found
- When users accessed the main page: The watch.metalhead.club globe was displayed
After a few attempts, I was able to reproduce the error sporadically myself. In the access logs of the Nginx proxy, I noticed that all erroneous requests were made with HTTP/3.
Since the big Twitter wave that flooded the Mastodon network and, more broadly, the Fediverse in the fall and winter of 2022, international users have been playing a bigger role for metalhead.club. The service is hosted entirely in Germany, and that was still the case until recently. However, with the increasing number of international members come new challenges: for example, the rapid delivery of content.
As long as users are mainly located in Germany and Europe, latency times to the “Full Metal Server” in Frankfurt are low. However, the situation is different for users from Canada, the US, and Australia, for example, of whom there are a significant number on metalhead.club. For these users, using metalhead.club was sometimes a bit of a test of patience, as videos and larger images in particular appeared on the website with a slight delay. I can only simulate the situation in the browser, but even a ping of more than 200 ms spoils the fun of scrolling through the timeline in some places.
Since I have been using Icinga DB (instead of just PostgreSQL) as the backend for my Icinga2 instance, it has happened to me twice that Icinga no longer worked correctly after an update of the Icinga DB package. On closer inspection, it also becomes clear why:
× icingadb.service - Icinga DB
Loaded: loaded (/lib/systemd/system/icingadb.service; enabled; preset: enabled)
Active: failed (Result: exit-code) since Wed 2025-01-22 21:42:50 CET; 27s ago
Duration: 13ms
Main PID: 1853805 (code=exited, status=1/FAILURE)
CPU: 13ms
Jan 22 21:42:50 monitor systemd[1]: Starting icingadb.service - Icinga DB…
Jan 22 21:42:50 monitor systemd[1]: Started icingadb.service - Icinga DB.
Jan 22 21:42:50 monitor icingadb[1853805]: Starting Icinga DB daemon (v1.2.1)
Jan 22 21:42:50 monitor icingadb[1853805]: Connecting to database at 'pgsql://icingadb@localhost:5432/icingadb'
Jan 22 21:42:50 monitor icingadb[1853805]: unexpected database schema version: v3 (expected v4), please make sure you have applied all database migrations after upgrading Icinga DB
Jan 22 21:42:50 monitor systemd[1]: icingadb.service: Main process exited, code=exited, status=1/FAILURE
Jan 22 21:42:50 monitor systemd[1]: icingadb.service: Failed with result 'exit-code'.
shred tool in a Fedora Live environment for secure deletion. However, it works just as well with any other Linux distribution.Two things are usually in short supply when you run a Mastodon instance: Funding and public attention. But both are important so that the instance can continue to operate and - if desired - achieve growth or reach.
My goal with metalhead.club is to offer a professionally hosted platform for everyone who feels at home in the metal music genre. In order for such a theme-based instance to be viable and its users to benefit from it to the greatest extent, it must achieve a certain level of popularity. Nevertheless, the usual advertising media are only of limited use - either because they do not implement my idea of data protection or because they are currently not readily financially viable. Precious donations have to be used sparingly.
Recently I can into an issue with acme.sh / Let’s Encrypt and a failing ACME validation
Error 404 when running acme.sh --renew -d mydomain.tld
[Wed May 3 15:31:45 UTC 2023] Pending, The CA is processing your order, please just wait. (1/30)
[Wed May 3 15:31:49 UTC 2023] mydomain.tld:Verify error:<ipaddress> Invalid response from https://mydomain.tld/.well-known/acme-challenge/5GmSwd0P0ukTtX302yHHhAuZMCEDJx7MmAaBBoPIKtk: 404
[Wed May 3 15:31:49 UTC 2023] Please add '--debug' or '--log' to check more details.
[Wed May 3 15:31:49 UTC 2023] See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh
My Mastodon instance metalhead.club exists since summer 2016 and seen several waves of new users - but never as many new users as in early November 2022. This has not only led to heavy CPU work on the servers (see my post about scaling up Mastodon’s Sidekiq Workers), but also to greater load on storage space. Mastodon uses a media cache that not only stores copies of preview images for posts containing links - but also copies of all media files that the server knows of. Before the user wave of late 2020 metalhead.club’s media cache was about 350 GB in size with a cache retention time of 60 days. Quickly the numbers escalated and after a few days we were already at 400 GB - and after about 3 weeks we had more than 550 GB of cached media files. Not with 60 days retention time - but with 30 only.
Despite I added hundreds of GB of new storage space, the cache showed no signs of shrinking in the near future, so decided to offload the storage to an S3 storage provider. The local disks would have been full a few days later.