6.5 KiB
| title | description | created | updated | series | series_index | tags | ||
|---|---|---|---|---|---|---|---|---|
| Site tech stack | Learn about how osmarks.net works internally! Spoiler warning if you wanted to reverse-engineer it yourself. | 24/02/2022 | 08/04/2025 | stack | 1 |
|
::: epigraph attribution="Rupert Goodwins" If you can't stand the heat, get out of the server room. :::
As you may know, osmarks.net is a website, served from computers which are believed to exist. But have you ever wondered exactly how it's all set up? If not, you may turn elsewhere and live in ignorance. Otherwise, continue reading.
Many similar personal sites are hosted on free static site services or various cloud platforms, but mine runs on a physical server. This was originally done because of my general distrust of SaaS/cloud platforms, to learn about Linux administration, and desire to run some non-web things, but now it's necessary to run the full range of weird components which are now important to the website. The hardware has remained the same since early 2019, apart from the addition of more disk capacity and a spare GPU for occasional machine learning workloads - I am using an old HP ML110 G7 tower server. Despite limited RAM and CPU power compared to contemporary rackmount models, it was cheap, has continued to work amazingly reliably, and is much more power-efficient than those would have been. It mostly only runs at about 5% CPU load and 2GB of RAM in use anyway, so it's not been an issue. Due to the increasing compute demands of internal workloads, among other things, it has now been replaced with a custom build using a consumer Ryzen CPU. This has massively increased performance thanks to the CPU's much better IPC, clocks and core count, the 16x increase in RAM, and having an SSD1. The main server currently idles at ~5% across cores and 30GB of RAM in use due to extensive caching.
The main site itself, which you're currently reading, is primarily a simple static site, though it consumes several backend services and integrates several pieces of JavaScript (vanilla JS and Svelte) for controls and comments, as well as for individual experiments. Over the years the exact implementation has varied significantly, from the original not-very-static version using Caddy, some PHP scripts for Markdown and a few folders of HTML files to the later strange combination of Haskell (using Hakyll) and makefiles to the current somewhat cursed Node.js program. The modern implementation of the compiler does templating, dependency resolution, Markdown, search indexing and some optimization tasks in several hundred lines of very dependency-heavy and undocumented JavaScript.
Being static files, many, many different webservers could have been used for this site. In practice, it's alternated between caddy (a more recent, Go-based webserver with automatic LetsEncrypt integration) and nginx (an older and more powerful but slightly quirky program) - caddy generally had easier configuration, but I arbitrarily preferred nginx in some ways. After caddy v2 suddenly required me to rewrite my configuration and introduced several inconsistencies, I permanently switched over to nginx and haven't changed back. The configuration file is now 600 lines or so, even with inclusion of includes to shorten things, but it... works, at least. This is mostly to accommodate the many subdomains in use and their associated reverse proxy configuration for backend services. I also use a custom-compiled build of nginx with HTTP/3 (QUIC) support and some modules compiled in, though QUIC is not turned on due to systems limitations.
Some of these backend services are only for personal use, but a few are related to the site itself. For example, the comment server is a standalone Python program, isso, now part of RSAPI with corresponding JS embedded in each page. This works well overall, but has led to some exciting features such as each separate 404 page URL having its own list of comments. There's also the Random Stuff API, a custom assemblage of about 15 different Python libraries and external programs which, while technically not linked on the site, does interact with other projects like PotatOS, and internal services on the same infrastructure like my RSS reader. The images subdomain also uses used a PHP program to generate a nice searchable index; this has fortunately been purged along with DokuWiki. There has been an on-and-off services status page, which is currently "on" thanks to running on custom code more reliable than the old custom code; previously I had a public Prometheus/Grafana (and earlier Netdata) instance there, but this has now been cancelled because it leaks a worrying amount of information.
As for the underlying OS everything runs on, I currently use Arch Linux (as well as OpenWRT on some routing equipment - I used to use Alpine in some areas but these computers are no longer in service). Some form of Linux is inevitable - BSDs aren't compatible with much, and Windows is obviously unsuited for server duty - but I mostly use Arch for its stability (this sounds sarcastic, but I've found it to be very reliable with regular updates), wide range of packages (particularly from the AUR; as I don't run critical production infrastructure and have about two nines of uptime, I can generally afford to compile software from source), and better general ease-of-use than Alpine. As much as I vaguely dislike it, this is mostly down to systemd - despite it being a complex bloated monolith, journalctl is very convenient and unit files are pleasant and easy to write compared to the weird OpenRC scripts Alpine uses.
Having considered a redesign to make the site partly dynamically generated rather than a static site for many years, I'm in the process of implementing it now, with a custom Lua and Rust program which will serve as a more flexible frontend server and be able to composite pages from multiple backends. This will allow for exciting* features such as more frequently-updating blogroll tiles, better-integrated comments and cleaner personalization mechanisms and interactivity, as well as less reliance on client-side JavaScript.
-
Multiple SSDs now, in fact, due to ever-increasing storage demands. ↩︎