add a few pages

introduction.md

@@ -6,6 +6,12 @@ This repository contains documentation for my homelab setup, which spans numerou
 
 My thought process and how different components of my homelab is setup are documented in the subfolder "principles". Each component has its own folder which contains why I've chosen to use it and how I'm using it.
 
+## Workloads
+
+All this thought and hardware has to run something for it to make sense. It would be ridiculous to only use it only to host a static webpage.
+
+Details on what I'm actually running and what I use it for can be found under the subfolder "workloads".
+
 ## Locations
 
 My homelab setup spans two locations: London and Copenhagen. Each location has its own set of servers, which are documented in the "locations" folder.

locations/copenhagen.md

@@ -6,6 +6,8 @@ I've set up a stack of servers at my Dad's place to work as an off-site location
 
 At this location I have 3 servers setup, A, B and C. A and B are Lenovo "tiny" desktop computers. I really like these boxes. They're very compact at about the size of a lunchbox and power is provided via a normal ThinkPad charging brick. The last server is a Raspberry Pi 4.
 
+I have some more thoughts about the hostname detailed in my principal page for [hostnames](../principles/hostnames)
+
 ## Networking
 
 There's not much to talk about here. Since it's not my house I'm not really at liberty to install a balls-to-the-wall networking setup. So I'm using the ISP provided router with each of the 3 servers connected directly to the built in switch in the router.

principles/hostnames/README.md

@@ -0,0 +1,22 @@
+# Hostnames
+
+## History
+
+For my setups in my locations, I decided to use a simple "A, B, C" approach since the amount of servers I have in posession is quite small compared to setups that are running in private clouds such as AWS or GCP.
+
+I'm _unlikely_ to have more than 26 servers in one location. (and if I do I should probably go touch some grass).
+
+## Problem
+
+This "ABC" scheme had served me well for over a year but it felt very clinical to SSH into "{location}-a".
+
+I realized that I missed the fun of actually naming a server. When a server has a real human names, suddenly they take on a personality.
+If a server is being difficult when rolling out a deployment, it's fun to think "Oh that's good ol' Betsy having a moment".
+
+## Solution
+
+What I ended up with is to still use names such as "copenhagen-a" as a primary hostname with services such as prometheus and tailscale referencing that name to keep configs simple and readable.
+
+However, I set the actual hostname on the machines to include a name starting with the letter of the server that is local to the geographical location. In copenhagen-a's case that would be "copenhagen-aksel".
+
+This makes them way more fun to play around with. The names being local to the geographical area make them feel unique.

principles/ubuntu/README.md

@@ -4,9 +4,28 @@
 
 The path to choosing Ubuntu as my primary OS was a long journey.
 
-First, I was running Proxmox but that was kind of a mess to configure and the overhead of virtualizing everything was surprisingly high.
+### Proxmox
 
-Then, I moved on to Alpine Linux. This was quite good, very memory efficient and no extra processes. However, I ran into issues when I started setting up Ansible.
+Originally when my homelab was just getting started I wanted to run everything as a VM or a container.
+I found out eventually that Proxmox just didn't fit me, it's a long story that I won't go into in this section but long story short - I found Proxmox to be sluggish, resource inefficient, infuriating and hard to maintain.
 
-So I chose the most generic OS I could think of, Ubuntu.
+On my Proxmox I used a bunch of different distros, primarily a very slim version of Debian 12 since I wanted the OS to be super lightweight.
+
+This lead me to instead use Alpine Linux on my VMs and containers instead of Debian and I chose Alpine when I eventually torched my Proxmox installation and went bare metal.
+
+### Alpine Linux
+
+I still love Alpine, it's blazing fast and uses minimal resources on the machine.
+
+I timed myself how fast I could run through the installer for Alpine from boot to fully configured machine and I clocked in at just under 5 minutes. 
+
+There's something about Alpine that makes everything feel instantaneous.
+
+### Ubuntu (current setup)
+
+As much as I love Alpine, I setup Ansible on my servers and I kept getting issues with Alpine since it's a _special_ distribution.
+
+The lack of GNU binaries and systemd eventually got to me enough that I switched to Ubuntu.
+
+I don't really like Ubuntu, install process takes at least 15 minutes, updates take forever to install and it keeps wanting me to reboot my servers but it's well supported by Ansible and the various roles I'm using.