Jan Tuomi

Linux OCI containers as plain FreeBSD jails (without Podman)

2026-08-10T00:00:00+00:00

Abstract: Linux software distributed as OCI container images can be extracted into a FreeBSD jail with Linux compatibility enabled. With a couple of mounts set up to make the extracted root a valid Linux userland, the "container" can run like a regular jail without involving virtual machines or a separate control interface (podman</code>). Isolation is handled by the jail subsystem. </blockquote>
FreeBSD has a respectable library of ported software in the ports tree</a>. Getting ported software set up is usually just a pkg install</code> away. Sometimes you have to take a couple of extra steps and run a make install</code>. Some programs do not have a port but can be made to run anyway, by tweaking a Makefile, setting up an ad-hoc Python environment, or something to that effect.
Some programs, however, are designed to be run in a very particular, Dockerfile-specified, Linux-library-dependent environment.
My first encounter with this kind of challenge was Immich</a>: a self-hostable personal photo and video gallery.
Immich has an elaborate Dockerfile setup. I tried my darndest to reverse engineer the steps to install it into a fresh FreeBSD jail, free from any extra layers of administrative abstraction.
It's a NodeJS app, can't be that hard. I've done this a bunch of times.
Turns out, in contemporary NodeJS fashion, the build involved:
various Rust build steps for some kind of SDKs and plugin systems</li> binary blob direct downloads (Linux-only of course)</li> a flurry of bind mounts from earlier build stages</li> </ul> etc, etc. The absolute state of web software complexity in $current_year</code>. I gave up and started looking for an alternate approach. The classic solution (Linux VM)</a></h2> I booted up a bhyve</a> virtual machine running Alpine Linux</a>. I used the venerable vm-bhyve</a> wrapper. With the vm running, I just installed podman with apk add podman</code> and started the immich services with podman compose up</code>. Ok, not all services. I still ran PostgreSQL and Valkey in a FreeBSD jail, outside the vm. It would be wasteful to virtualize those, since they run without a hitch on FreeBSD. I just made sure to give the vm a local IP that's in the same subnet as my jails. </blockquote> The problem was immediately solved. It is trivial to run Linux containers when you have a Linux box. However, I was not content. The virtual machine was consuming more resources than all of my jails and natively running services combined. A fresh Alpine install has more background processes running than my production FreeBSD server. I have to run a full Linux kernel and a bunch of processes just to run this one Node.js app. Also, the vm sticks out like a sore thumb in my otherwise clean jail setup. It needs a bunch of purpose built machinery to provision and manage. I cannot keep it up to date with zfs clone</code>, freebsd-update</code> and pkg upgrade</code>. Monitoring needs to be set up separately. Logging needs to be set up separately. The cutting edge solution (Podman + Linux containers)</a></h2> The container runtime podman supports FreeBSD since 14.3-RELEASE</code></a>. In addition to being able to run OCI images built on a FreeBSD base image, podman is able to run Linux containers as well using the FreeBSD Linux compatibility layer. This is fantastic and probably the future of containers of FreeBSD. However, I do not want to set up podman on my server, at least not yet. Podman has an opinionated approach to networking and storage. Networking requires specific pf</code> firewall rules and storage is modelled in a way that is not compatible with how I manage my jail ZFS datasets. And maybe most importantly, container services would require using the podman</code> interface instead of the traditional service</code>/rc</code> interface, which I use to manage everything else on the box. Using podman for a single service would complicate things. Unnecessarily, in my opinion. I didn't set up podman to run Immich. Instead, I started designing a custom approach, that would still let me use the tools I use everywhere else and avoid needless performance overhead. My custom solution (Linux jail + extracted container file system)</a></h2> The core idea of my solution is to note a central fact: a container image is basically an archived Linux userland. What if I follow the FreeBSD Handbook's instructions on how to run a Linux jail</a> and adjust the steps to run in the container root filesystem instead? Through some trial and error, I got a setup working. I'll walk you through the main steps in a tutorial fashion, using the immich-server</code> container as an example. Preparing the host and starting an interim jail</a></h3> First things first: Enable Linux compatibility on the host. You don't want to mount any special filesystems on the host, so disable those separately: [host]$ sysrc linux_enable=YES [host]$ sysrc linux_mounts_enable=NO [host]$ service linux start</code></pre> Next, set up a jail filesystem. I used zfs clone</code> to clone my 15.1-RELEASE</code> template (which is based on the same release as my host) into a new jail root. Call it immich-server</code> because it matches the name of the container. My jail filesystems live under zroot/jails/containers/</code>: [host]$ zfs clone zroot/jails/templates/15.1-RELEASE@base zroot/jails/containers/immich-server</code></pre> Use a direct jail</code> command to set up basic networking and select the filesystem path. This isn't the final configuration: you just need it running to set up the immich container. # see that the IP and interface match your setup [host]$ jail -cm \ name="immich-server" \ host.hostname="immich-server" \ path="/usr/local/jails/containers/immich-server" \ exec.clean \ allow.raw_sockets \ interface="lan0" \ ip4.addr="192.168.4.1" \ exec.start="/bin/sh /etc/rc" \ exec.stop="/bin/sh /etc/rc.shutdown" [host]$ jexec immich-server /bin/sh [immich-server]$ </code></pre> You now have a shell in the jail. Extract the OCI image</a></h3> Next, you need to 1) download the image, and 2) extract the image filesystem into a jail. Luckily, the OCI ecosystem has suitable programs for these tasks: the umoci</a> and skopeo</a> command line tools. These tools are only needed during build time, i.e. while constructing the container jail. They are not needed during runtime. You might choose to install them in the jail, and perhaps uninstall them later. Or maybe install them on the host and operate on the jail filesystem from the host side, keeping the jail clean. Maybe one could even set up a temporary "build jail"? I went with the first option, and just installed the tools in the target jail, immich-server</code>. With skopeo</code>, you can download a Linux OCI image into a file in the filesystem: [immich-server]$ pkg install skopeo [immich-server]$ TAG="immich-server:v3.0.3" [immich-server]$ skopeo copy --override-os linux docker://ghcr.io/immich-app/$TAG oci:$TAG</code></pre> This creates a directory called immich-server</code> in the current directory. The directory contains the manifest and the layers. Then, use umoci</code> to extract the layers into a valid Linux userland. Just one problem: umoci</code> does not have a FreeBSD port or a FreeBSD binary build. Fear not! The Linux binary is statically linked and the jail has Linux compatibility, since you enabled it on the host. # Assuming amd64 arch here [immich-server]$ fetch https://github.com/opencontainers/umoci/releases/latest/download/umoci.linux.amd64 [immich-server]$ install -m 755 umoci.linux.amd64 /usr/local/bin/umoci [immich-server]$ umoci unpack --image $TAG unpacked</code></pre> The unpacked</code> directory contains the rootfs</code> as well as some metadata. unpacked/config.json</code> is worth checking out: it contains values that are defined in the Dockerfile, such as: env</code>, command</code>, user uid</code> and gid</code>, working directory path. Those can be used later, when we set up the service to start up the app. Let's move unpacked/rootfs</code> to an easy absolute path: /linux</code>. [immich-server]$ mv unpacked/rootfs /linux</code></pre> Chroot inside and see that it acts like a Linux system should: [immich-server]$ chroot /linux /bin/sh $ uname -s Linux</code></pre>Mounting special device nodes and defining the final jail</a></h3> Some containerized apps might work already, but most need specific device nodes to function. Let's exit the chroot and shell, and stop the jail. [host]$ jail -r immich-server immich-server: removed</code></pre> Now, define the jail properly with a jail.conf</code>, taking inspiration from the Handbook. You can also use bastille</code>, iocage</code> or any other jail manager/wrapper to do this. The goal here is to set up a normal Linux userland with the expected dev nodes as well as special filesystems like /proc</code> and /sys</code>. Mount also any directories that are used during runtime, i.e. those that are handled by volume or bind mounts when using OCI containers. Note that the jail does not need any of the allow.mount.*</code> directives, since the mount syscalls happen on the host side. Edit as needed: immich-server { # STARTUP/LOGGING exec.start = "/bin/sh /etc/rc"; exec.stop = "/bin/sh /etc/rc.shutdown"; exec.consolelog = "/var/log/jail_console_${name}.log"; # PERMISSIONS allow.raw_sockets; exec.clean; mount.devfs; devfs_ruleset = 4; # Ensure that you use a devfs ruleset that exposes all basic devices enforce_statfs = 1; # Allow the jail to see what's mounted # HOSTNAME/PATH host.hostname = "${name}"; path = "/usr/local/jails/containers/${name}"; # NETWORK ip4.addr = 192.168.4.1; interface = lan0; # LINUX SPECIAL MOUNTS mount += "devfs $path/linux/dev devfs rw 0 0"; mount += "tmpfs $path/linux/dev/shm tmpfs rw,size=1g,mode=1777 0 0"; mount += "fdescfs $path/linux/dev/fd fdescfs rw,linrdlnk 0 0"; mount += "linprocfs $path/linux/proc linprocfs rw 0 0"; mount += "linsysfs $path/linux/sys linsysfs rw 0 0"; # CONTAINER VOLUME MOUNTS mount += "/usr/local/jails/volumes/immich_server_data $path/linux/data nullfs rw 0 0"; }</code></pre> I actually use vnet networking and not simple networking. It's not relevant for this demo though. </blockquote> If you put the jail.conf</code> in its proper place, you can now control the jail with service</code>: [host]$ service jail start immich-server Starting jails: immich-server.</code></pre>Creating the rc</code> service</a></h3> Now, we need to configure the containerized app to start when the jail starts. We can use a simple rc</code> service for this! Let's jexec</code> into the jail and create a service file. [host]$ jexec immich-server /bin/sh [immich-server]$ vi /usr/local/etc/rc.d/immich_server</code></pre> My service looks like this. The idea is to run the application in a chroot</code>. The startup command is improvised based on the container image config.json</code> in the extracted unpacked</code> directory. #!/bin/sh # PROVIDE: immich_server # REQUIRE: NETWORKING # KEYWORD: shutdown . /etc/rc.subr name="immich_server" rcvar="${name}_enable" pidfile="/var/run/${name}.pid" logfile="/var/log/${name}.log" load_rc_config $name : ${immich_server_enable:="NO"} : ${immich_server_envfile:="/usr/local/etc/immich_server.env"} : ${immich_server_root:="/linux"} : ${immich_server_user:="root"} : ${immich_server_group:="wheel"} start_cmd="${name}_start" stop_cmd="${name}_stop" status_cmd="${name}_status" immich_server_start() { echo "Starting ${name}." set -a # export all variables . ${immich_server_envfile} set +a /usr/sbin/daemon -P ${pidfile} -o ${logfile} \ /usr/sbin/chroot \ -u ${immich_server_user} -g ${immich_server_group} \ ${immich_server_root} \ /usr/local/bin/node /usr/src/app/server/dist/main.js } immich_server_stop() { if [ -f ${pidfile} ]; then echo "Stopping ${name}." kill $(cat ${pidfile}) 2>/dev/null rm -f ${pidfile} else echo "${name} is not running." fi } immich_server_status() { if [ -f ${pidfile} ] && kill -0 $(cat ${pidfile}) 2>/dev/null; then echo "${name} is running as pid $(cat ${pidfile})." else echo "${name} is not running." return 1 fi } run_rc_command "$1"</code></pre> Now, some things don't map to this filesystem-focused way of running container apps. Containerfiles can define: environment variables</li> exposed ports</li> user and group ids</li> </ul> You might want to implement these in some way. My own approach can be seen in the rc</code> service example: you can supply an envfile with FOO=bar</code> style variables and specify user and group with rc.conf</code> variables. # Set up environment variables in this file [immich-server]$ touch /usr/local/etc/immich_server.env [immich-server]$ chmod 600 /usr/local/etc/immich_server.env</code></pre> Enable the service to start automatically on jail startup, and start it once right away: [immich-server]$ service immich_server enable [immich-server]$ service immich_server start</code></pre>Upgrading the container</a></h3> I have yet to upgrade to a more recent version of the image, but I'd imagine it is as simple as: stopping the service,</li> unmounting all mountpoints,</li> removing the /linux</code> directory, and</li> redoing the steps that download and extract an image into /linux</code>, using the new image TAG</li> </ol> Then, a jail restart should bring everything up again. Thoughts</a></h2> I have had a good experience with this setup. It is somewhat manual, sure, and I guess some utility scripts could be used for the download and extract part at least, but that doesn't bother me really. Obviously adhoc setups like this could be improved and made more robust/rigorous. You can also run multiple container images in a single jail with this method. Immich has a separate machine learning container for running face recognition tasks etc. I run that in the same jail with a separate rc</code> service. One fun approach could be to wrap this into a FreeBSD port, and build the image fs with poudriere. A simple pkg install</code> could then set up the service and everything. Something to consider!

🌱 Now, spring 2026 2026-04-12T00:00:00+00:00 Planning the wedding, reworking my wardrobe. Home reno. Dogs playing in the dog park.</figcaption> </figure> Jojo (the shiba inu) breached containment one night. We were going to take him out on a walk but the dog was nowhere to be seen. The backyard gate was slightly open. We tried finding him by driving around the neighborhood. Some people on social media had seen him walking around so we tried to track him, but we were always too late to the scene. Luckily, he walked back home and was waiting for us in the backyard. You're a smart boy, Jojo, but don't do that again. One of the most stressful evenings of my life. TV & anime</a></h2> I was sick for a week so I had ample time to watch a bunch of stuff from my backlog. Started Chiikawa. The episodes are so short that we watch a bunch at a time.</li> Jojo's Bizarre Adventure: Steel Ball Run aka part 7 (where are the episodes, Netflix?)</li> </ul> Finished Dandadan S2</li> The Witcher, seasons S2–S4</li> Golden Boy</li> Yuru Camp S1</li> Beyond the Boundary (series and Future movie)</li> Paprika (movie)</li> The Boy and the Heron (movie)</li> </ul> Manga</a></h2> Started Jojo's Bizarre Adventure: Jojolion, aka part 8</li> Witch Hat Atelier (in Japanese)</li> </ul> Finished Berserk 1–43. RIP Kentaro Miura.</li> DU-RAN-KI</li> </ul> Games</a></h2> Stray</li> Pizza Tower (dropped midway, didn't spark interest)</li> Castlevania: Symphony of the Night</li> Warhammer 40K: Space Marine II</li> Absolum</li> </ul> I also won a game of Twilight Imperium (4th ed). Music</a></h2> Stopped using Spotify. I already pay for Youtube Premium + Music so I already have a streaming service that I can use. I also try to be more mindful of my music consumption and focus on supporting independent artists and creators. Mostly by buying digital albums or tapes from Bandcamp or distributors.</li> Saw Merzbow</a> live.</li> Went to a Bongo's Bingo</a>.</li> </ul> I listen to a bunch of black metal and adjacent genres. There's a lot of white supremacists and fascists in those communities, especially in the Finnish scene (sadly). I figured I should use a couple of hours to go through some of the artists that I have listened to and see if they're sketchy or not. I'm happy to find that most of the stuff I listen to is a-ok, and a great deal of artists are vocally against hate, or at least apolitical (whatever that means). However, some artists had slipped through the cracks. Mgła collaborates with Nazis and the frontman has an earlier project with clearly anti-semitic titles and lyrics. Drudkh has used Nazi imagery during their live shows. I really enjoyed their music in 2025, but I won't be supporting them anymore. Top tunes</a></h3> The Spiritual Sound by Agriculture</a></iframe> This website</a></h2> The new Zola-based implementation has been working well. There was a bunch of figuring-out to do at first, like how to structure the templates to get the /now</a> page working, or how to get the previous/next post links appended to each post, but it's been worth it. Zola compilation is way faster than my earlier custom Scheme-based SSG. My earlier system had the major upside that it directly read Markdown from my Obsidian vault, which allowed me to edit posts on the go. Currently everything's laptop-driven, which is bit of a pain. I might set up something with file shares to allow editing posts from my phone. Deployments will still happen from the laptop. Home improvements</a></h2> Quick-fire round: Woodworking: new windowsill and shelf in the living room great for positioning the rear bluetooth speakers</li> </ul> </li> shoe rack inside a cabinet in Marika's room</li> shoe rack inside a cabinet in the front door hallway</li> </ul> Bought furniture: new metal and glass cabinet in the kitchen</li> a bench for not-clean-but-not-dirty clothes, upstairs</li> a new towel rack for the bathroom</li> </ul> The studio room is also progressing after a hiatus. I got the server/synth rack set up and the old studio desk disassembled. Excited about getting things moving in that room too. Previous update</a></h2> ❄️ Now, winter 2025</a></li> </ul> A home server journey, part 5: Ansible 2025-12-26T00:00:00+00:00 This is the fifth episode in a series where I set up a FreeBSD home server, explaining all the steps, problems and solutions along the way. This time we're provisioning the server with Ansible. Check out episodes 1</a>, 2</a>, 3</a>, 4</a>. Automation</a></h2> Ansible</a> is a tool for running a bunch of Python scripts, or "tasks", in a kind of declarative way. It's commonly used for provisioning servers. My ansible configuration is publicly available on my GitHub. I update it regularly. 🌐 jantuomi/ansible-freebsd-home-server</a> I have only one server, and I'm planning to have it for a long time. Why would I need automated provisioning? It seems like an extra step when I could just provision everything manually. There is no need to synchronise multiple hosts or anything like that. I view this kind of automation as executable documentation, or readable instructions for both the computer and the human. If I define the server in terms of these Ansible tasks, I can (in theory) reconstruct what's been done with the server just by reading the Ansible playbook. To be reliable, this necessitates that everything is defined in Ansible. Which happens to be very difficult to actually do. Project structure</a></h2> There are many ways to structure an Ansible project. I picked one that I consider to be simple: a single main playbook, with tags for selective execution of sub-playbooks</li> a non-tracked secrets.yml</code> that contains all secret values reasoning: this way I don't need to parse a separate configuration format and I get access to all features of YAML, including its data structures (lists, objects), which I would be lacking if I used a flat file format such as .env</code>.</li> </ul> </li> a flat file hierarchy with names mirroring the target path, e.g. templates/root_ssh_config.j2</code> goes to /root/ssh/config</code>.</li> no handlers and notify, because I want complete control over the execution order</li> </ul> This is my first non-trivial Ansible project, so I wouldn't be surprised if I have some anti-patterns in there. The playbooks are designed to be fully idempotent: I can run the playbook again after the first run and expect the system to be in the same state. This is very important, since I want to be able to fearlessly run any playbook at any time and expect a success, or at least a helpful failure that doesn't compromise basic operation of the host. The only host in the Ansible inventory is my server. I run the playbook like this from my development laptop: $ ansible-playbook -i inventory playbook.yml</code></pre> If I want to only update the ingress</code> jail, I run: $ ansible-playbook -i inventory playbook.yml -t jail_ingress</code></pre>Separation of responsibilities</a></h2> Let's borrow and tweak the standard cloud infrastructure stack diagram that shows what parts of the stack are handled by the cloud provider and what parts are handled by the customer. My current approach is to use Ansible for the "core" parts of server administration, installing packages, defining service jails, etc: A stack model depicting the software layers in my server</figcaption> </figure> Some notes about this setup: The top "application layer" is currently a chaotic no-man's-land with varying levels of automation. Optimally I could rebuild all service jails completely with Ansible.</li> The host OS release is managed manually, i.e. release upgrades are run manually with freebsd-update</code>. This is fine IMHO. I will be supervising all the few and in between OS upgrades anyway, so automation does not help much there.</li> </ul> Why not Chef, Salt, etc?</a></h2> Ansible is very simple. It's pretty much a framework to write idempotent shell scripts without having to write shell scripts. Or Python scripts, whichever way you want to look at it. It's agentless. I don't have to run a service on the FreeBSD host to use Ansible. It uses SSH as transport and runs the tasks with Python, both of which are software that I expect to be present on any *nix server. A snippet of Ansible playbook installing PostgreSQL in the "postgres" jail</figcaption> </figure> How about containers?</a></h2> I'd image that most new server setups in 2025 are designed with container workloads in mind. This one is too, kinda. I isolate most services with FreeBSD jails, which are similar to OCI containers. Processes are isolated from other jails and the host automatically. Virtual networking (vnet</code>) isolates the network. ZFS snapshots and clones provide thin jail filesystems that have a small storage footprint. Jails share the host kernel. Many OCI container concepts translate well to jails, but jails are somewhat more persistent. Conventionally, jail filesystems are not ephemeral and survive jail restarts. Only ssh</code>, bash</code>, vim</code> and some other packages are installed on the host directly. Everything else is 🔐 incarcerated 🔐. A list of running jails on the server</figcaption> </figure> FreeBSD OCI container support</a></h3> FreeBSD was recently welcomed</a> into the prestigious club of platforms that can run OCI containers. This was achieved by using jails as the container runtime and podman</code> as container manager. This pretty much means that we can use Dockerfiles/Containerfiles to define our jails. Existing Containerfiles cannot be used directly, since they are built on Linux base images, but they can be used as a starting point for building new, FreeBSD-based images. While this sounds very cool and promising, I want to let the implementation mature a bit before building everything on it. I tried installing the podman-suite</code> package and following the instructions, and promptly broke all of my networking, so yeah 😑 </blockquote> I'm sure OCI containers will be a valid and respectable approach to containerization on FreeBSD, after the kinks have been ironed out. To be continued</a></h2> In the next part(s) we will be looking at the specifics of the jail setup, e.g. how to create jails using jail.conf.d</code> scripts. A home server journey, part 4: Networking 2025-12-24T00:00:00+00:00 This is the fourth episode in a series where I set up a FreeBSD home server, explaining all the steps, problems and solutions along the way. This time we're looking at networking. Check out episodes 1</a>, 2</a>, 3</a>. Dual interfaces</a></h2> I already have a private network (192.168.0.0/16</code>) that uses my pfSense router as its gateway. The FreeBSD server will connect to this network through ethernet interface number one (lan0</code>). Packets to and from local devices go through this interface. The host will also be connected directly to the ISP's network using its second interface (wan0</code>). This interface will get its IP using DHCP. Packets to the internet, as well as packets to public services running on the FreeBSD host go through this interface. A simplified diagram showing the two interfaces</figcaption> </figure> A dual interface set up like this is simple in theory, but there are important nuances, e.g. regarding return traffic routing and DNS. Routing</a></h2> If we send a packet out through eth0</code>, we should expect return traffic to arrive on eth0</code> (and vice versa). However, it is rather easy to misconfigure the system. Assume we have a public service, such as an nginx</code> web server, which listens on the public interface. If we set up rc.conf</code> naively like this: defaultrouter=192.168.0.1</code></pre> ...the request might arrive through the public interface, but the response from the web server leaves through the private interface since we have configured the private gateway as the default. This is called asymmetric routing. This might work! Both routes lead to the internet. From the perspective of the ISP, it doesn't really matter whether the packet went through the home router or not, in this case. Sometimes however, this setup leads to the most vexing of networking issues. Figuring out what's wrong taught me a bunch about DHCP and layer 3 routing. Routing issue #1: ISP DHCP server and MAC addresses</a></h3> A DHCP server can keep track of clients using their MAC address. Separate physical interfaces have separate MAC addresses, so there is an obvious problem here. If an initial DHCP request broadcast leaves through one interface, and following DHCP requests (non-broadcast) leave through another interface, the DHCP server might see this as a forged packet. This happened to me because of the defaultrouter</code> setting: The initial broadcast leaves through the wan0</code> interface correctly. An IP is received.</li> When the lease is about to expire, a targeted request is sent to the now known DHCP server address. This is routed through lan0</code> and 192.168.0.1</code>, since it's the defaultrouter</code>.</li> The DHCP server sees the FreeBSD WAN MAC on first contact, and the home router MAC address on second contact. The lease is not renewed.</li> The lease expires, repeat from step 1.</li> </ol> My solution? Just don't use defaultrouter</code>. As part of the routine DHCP song and dance, dhclient</code> adds a valid default route to the system routing table. Just use that for all internet-bound traffic. You can see the routes with netstat -rn</code>: # netstat -rn Routing tables Internet: Destination Gateway Flags Netif Expire default 87.92.64.1 UGS wan0 87.92.64.0/18 link#36 U wan0 192.168.0.0/16 link#25 U lan0 127.0.0.1 link#57 UH lo0 ...</code></pre> The default</code> route was added by DHCP. Routing issue #2: DNS-level ad blocker in my router</a></h3> I run pfBlockerNG</a> on my router to block ads on a DNS level (think Pi-hole). If I route traffic through the router, the return traffic is processed by this extra firewall. Some packets got dropped by pfBlockerNG and never arrived at the destination. This was very annoying to debug! At least I had logging on, so I could confirm what's happening pretty quickly. DNS</a></h2> Nameservers are defined on a whole system basis in /etc/resolv.conf</code>, and not per interface or per IP. I have a basic DNS resolver running on my home server, so I simply configured my resolv.conf</code> as: nameserver 192.168.0.1</code></pre>Split horizon</a></h3> Which IP should be returned from the DNS server if I query some-public-service.jan.systems</code>? The private address from 192.168.0.0/16</code>, or a public IP reachable from the internet? This is called split horizon DNS. One approach is to configure the DNS server to respond differently based on the address of the querying host. A private network host gets the private IP, etc. I decided to not worry about this, and just use a separate domain, local.jan.systems</code> for local addresses. This is a bit inconvenient, but I don't mind. The fewer DNS problems the better. DHCP and resolv.conf</code></a></h3> By default, dhclient</code> has a hook that overwrites resolv.conf</code> with the DHCP-provided nameserver information. I want to always use my router as the DNS server, so I had to disable this functionality. On FreeBSD, there are two simple solutions: resolvconf.conf</code>: a meta-config that configures the resolvconf</code> tool, which is used internally by dhclient</code></li> </ol> To disable resolvconf</code> altogether, add this to /etc/resolvconf.conf</code>: resolvconf=NO</code></pre> Now, resolvconf</code>, and transitively dhclient</code>, won't overwrite your changes anymore. making /etc/resolv.conf</code> immutable with a flag</li> </ol> As root, you can set the file as immutable with chflags</code>. Then, nothing can edit the file before the flag is removed. chflags schg /etc/resolv.conf</code></pre> Note that if you have a non-default securelevel</code></a>, you might not be able to remove this flag. Dual stack?</a></h2> For now, I'm building everything on IPv4. My ISP has no support for SLAAC which makes IPv6 somewhat non-trivial. I will most likely add IPv6 at some point, but it's not a priority. To be continued</a></h2> In the next part(s) we will be looking at provisioning with Ansible. A home server journey, part 3: Installation 2025-12-23T00:00:00+00:00 This is the third episode in a series where I set up a FreeBSD home server, explaining all the steps, problems and solutions along the way. This time we're installing the OS for the first time. Check out episodes 1</a> and 2</a>. Installing FreeBSD</a></h2> Installation should be pretty straightforward. I'm going to go with the latest stable release installer (14.3-RELEASE</code>) in the amd64</code> + memstick.iso</code> variety. Let's burn the installer onto a memory stick, plug it in, and was enter the install wizard. Note from the future! 15.0-RELEASE</code> is already out, and I have recently updated to it. This post is already outdated! </blockquote> The initial idea is this: ZFS, for all the automatic durability gains and easy-to-setup RAID1+0 (stripe of mirrors)</li> encrypted ZFS datasets (kinda similar to partitions) for jails, which would contain all the actual services</li> unencrypted root, so that I can reboot the machine remotely, physically unattended</li> </ul> Jails</a> are a lightweight way to containerize applications. They can get a separate process space, network stack, file system, root user, among others. They use the same kernel as the host, so they are more similar to LXC or OCI containers (think Docker, but more mature and flexible) than to virtual machines, which in FreeBSD are managed with bhyve</a>. Teaser: we will be installing bhyve</code> later too. </blockquote> Using the install wizard, I set up the system following my rough plan. And here we go, all up and running: Fastfetch output showing the machine specs. Disregard the uptime (I took the screenshot way later)</figcaption> </figure> RAIDZ</a></h3> You might notice that I bought 4 x 1 TB of NVMe disks, but fastfetch</code> is only showing ~2TB. That's because I set up the disks into a "RAID 1+0" configuration: A "RAID 1+0" configuration</figcaption> </figure> RAID 1+0 is a combination of two RAID levels. RAID 1, or mirror, consumes two disks to produce one virtual disk that has the capacity of only one physical disk but can withstand the loss of either one. ZFS can automatically heal missing data in a member of a mirror by copying it over from the healthy member. RAID 0, or stripe, consumes two disks to produce a disk that has the capacity of the sum of its member capacities as well as double I/O speed, but fails if either member disk fails. The combination of these is a useful way to get increased speed and increased durability at the price of half your raw capacity. Threat profile and encryption</a></h2> To figure out what level and what kind of at-rest encryption I need, I need to stop and think about the threat model. Scenario A, online intruder. An attacker that gains shell access can exfiltrate any data that the user has access to, since the decryption key has been activated at boot. At-rest encryption won't help here. Scenario B, burglar. An intruder grabs the machine and brings it to a place where they can inspect the disks, possibly with sophisticated recovery tools. In a non-encrypted-root install, everything outside the encrypted jails is instantly accessible. Stored API keys and similar secrets leak. The administrator must take great care not to keep anything of value on the unencrypted partition(s), and store everything in encrypted datasets.</li> An encrypted root would be safe from this attack, assuming the cryptography used in the encryption is bulletproof.</li> </ul> Scenario C, evil maid attack. A friend, spouse or similar tampers with the unattended physical system. Illegitimate access is blocked by requiring login and keeping the credentials in my personal vault. If the whole disk is encrypted, the worst thing the attacker can do is cause temporary harm and possibly data loss by powering off the system. If not, the attacker can do all kinds of nasty things, like booting a live environment and copying the disk contents, replacing the kernel/bootloader, installing malware etc. Conclusion</a></h2> It makes sense to encrypt the whole thing. ⚠️ But wait a minute! This is against my initial idea: unencrypted root, so that I can reboot the machine remotely, physically unattended </blockquote> Encrypting the whole disk loses the ability to do unattended reboots. A bit inconvenient, but it is what it is. I'll just make sure to only reboot when I'm physically near the machine, which should be often, considering I work from home and the server is, uh, right there. Because of this architectural change, I ended up installing FreeBSD for a second time, now with full disk encryption. System disk?</a></h2> Sometimes a separate small system disk is used in addition to a redundant array of "data disks". I decided to not pursue this setup, since then the system would not benefit from the RAIDZ redundancy and self-healing capabilities. In fact, I'd imagine that the ability to repair the OS and packages is even more important to me than repairing bulk data. I decided to keep the system next to the data on the disks (a "traditional" install). To be continued</a></h2> In the next part(s) we will be looking at networking. I had some – let's say curious – issues with DHCP leases from the ISP. We'll also take a look at my jail setup. ❄️ Now, winter 2025 2025-12-16T00:00:00+00:00 Fall has gone by, fast. Mostly rain and darkness. Managing the estate of my late father has taken up a lot of time I would've otherwise spent on hobbies. Some decor and reno at home, some game programming, a lot of games. Game design has been on my mind a lot lately. I also attended my first ever Finnish defence forces reservist refresher training exercise. I had a good time! Metroidvania game dev</a></h2> 🚨 Original game idea alert 🚨 I decided to make a 2D platformer with ability-gated progression. It's gonna have pixel art too. It's been a very long time since I made a complete game project. I don't care about how many players I'm gonna get. I just want to create a game, for me. I figured I should do some proper design upfront instead of doing the easy thing, i.e. jumping straight into programming mechanics. That's why I started writing a Game Design Document ASAP. With that, maybe I can come back to this project easier, after the inevitable plateau and loss of interest. Maybe some screenshots later. Future of ATK16</a></h2> An idea came to me in my sleep. I want to change the course of my computing project ATK16 and turn it into a stack-based, Forth-like system. Clearly I've been subconsciously processing ideas from Forth and Uxntal</a>, since my current vision is a hodgepodge of features from those two: an interactive REPL-compiler, able to compile native code on the fly</li> a system-wide dictionary (map of symbols to code or data), giving structure to the linear memory</li> reverse Polish notation, which falls naturally out of the stack machine design</li> </ul> A basic session could look like this: ATK16 v0.1 Dictionary usage: 10 KB : average3 (a b c -- avg) + + 3 / ;</code></pre> This would define a new symbol, average3</code>, that computes the average of the top 3 elements on the stack and pushes the result on the stack. The stack could be implemented in hardware with a top-of-stack optimization: the top three slots live in fast registers, while the rest is in dedicated SRAM. This would allow fast access to the most important, i.e. topmost, elements of the stack. In addition, I'm thinking of doing some things a bit unorthodox: The system dictionary could live in FRAM, which is non-volatile. All symbol definitions would then be automatically persistent, like files on a disk. This could be huge.</li> A programmer board could then allow me to directly update this dictionary from my dev laptop, possibly by emulating the same REPL software that runs on the hardware.</li> </ul> In fact, it might be possible to design this in a way that completely does away with assemblers and cross-compilers. I would just need an emulator and a bit of bootstrap assembly that implements a minimal REPL that can self-compile new symbols into the dictionary. Like this, I wouldn't need to worry about ensuring that the assembler and self-compiler work exactly the same: there is only one compiler implementation! I just emulate it on my laptop. Everything is implementation defined! Home</a></h2> ”Dopamine office” decor</a></h3> Office room number one is now pretty much complete. We tried to combine some of pastel colors and fun patterns, while keeping it smart and tidy. The dopamine office</figcaption> </figure> Backdoor clothes rack and wall feature</a></h3> We use our apartment's back door a lot, more than the front door really. It's easier to take the dog out that way. Until now, there has been nowhere to really hang our outdoor clothes nicely. The dining table and its chairs have doubled as a clothing rack (not ideal). So we got the idea to repurpose the empty space in the corner, adding some visual interest with acoustic paneling as well as utility with some colorful "knobs" that you can hang coats and scarves on. Install in progress</figcaption> </figure> And the final product (in completely different lighting): An installed wood paneling with some coats hanging off of colored knobs</figcaption> </figure> The white box is an IKEA shoebox. We keep some dog gear in there. Cool dog print</a></h3> Cool dog</figcaption> </figure> Games</a></h2> Played God of War: Ragnarök</li> Cocoon</li> Another Crab’s Treasure</li> Super Metroid</li> Metroid Dread</li> Prince of Persia: The Lost Crown</li> Ori and the Blind Forest</li> </ul> Anime</a></h2> Finished Bocchi the Rock S1</li> Spirited Away (movie)</li> Ghost in the Shell (movie)</li> Kill la Kill</li> </ul> Started Dandadan S2</li> Spy x Family S1</li> </ul> Tunes</a></h2> Mostly Moomin music</a>. I went to see the Muumimusiikkia show in Musiikkitalo (Helsinki) in November, and after that I haven't been able to get Shiratori's melodies out of my head. This is a positive problem. A photo from our seats at Musiikkitalo, showing the brochure</figcaption> </figure> Spotify Wrapped</a></h3> I feel like I'm using Spotify less and less. Might drop the subscription in the near future. I really don't like the policies they are driving. My top genres, all over the place</figcaption> </figure> Previous update</a></h2> 🍁 Now, fall 2025</a></li> </ul> EuroBSDCon 2025: conference notes 2025-10-17T00:00:00+00:00 EuroBSDCon is one of the events organized under the BSD community umbrella, focusing on all things related to and descending from 4.4 Berkeley Software Distribution. This year's event was held between September 25th and 28th in Zagreb, Croatia, but the city and country change every year. My event experience consisted of two days of "trainings", sometimes also referred to as labs, and two days of conference proper. In addition to these, there were also dev summits and smaller "conference-in-a-conference" kind of deals related to some BSD subsystems like bhyve</code>, but those were not relevant to me so I skipped them outright. The event was held at the Faculty of Electrical Engineering and Computing (University of Zagreb). The venue was nostalgic in a way since it reminded me a lot of the building where I started my studies in Aalto University. Functional. A photo of a stairway in the conference venue</figcaption> </figure> Recordings from the presentation rooms can be found on Youtube</a>. You might have to check the talk schedule to find the timestamp of a given talk. Kernel deep-dive</a></h2> I attended a two day lab by Prof. Kirk McKusick, who is a well known figure in the BSD world, having worked on core operating system components in the formative years of the BSD lineage. I really enjoyed his relaxed but still intensive teaching style. The lab, or maybe interactive lecture would be more fitting, was an introduction to the FreeBSD kernel subsystems, explaining how things like I/O, scheduling, filesystems and networking work in the kernel. Note that the FreeBSD kernel is not the same as the Linux kernel, or the other *BSD kernels either for that matter. It is FreeBSD exclusive, but it shares history with other systems that descend from 4.4BSD, which is the common ancestor for many Unix-like OSs. </blockquote> You see, I'm not a huge kernel guy (at least not yet) so I was a bit worried that the lab content would go over my head. What happened though surprised me: I understood something like 90% of the material. Apparently I had the necessary prerequisite knowledge after all, or maybe Kirk was just so good at teaching. Maybe both. Two spiral notebooks of lecture notes, one for each day</figcaption> </figure> Favorite talks</a></h2> There was a healthy range of themes in the talk schedule. Some were straightforward demos of recent development efforts, some were about history (mostly 1970–80s, the childhood years of the BSD project). Some war stories as well, explaining how the speaker et al. dealt with some hindrance. There were also some, I would say not so BSD-related, talks about things like data and identity ownership, federated social media, freedom. There is a bunch of overlap between BSD enthusiasts and digital freedom enthusiasts so it was only fitting. Here's my top 3, based on overall vibes. Lessons learned Open Sourcing the UK's Covid Tracing App, by Terence Eden</a></h3> Terence was the third in line in the Saturday's opening keynote schedule. Terence was one of the key engineers behind the open source Covid tracing app that the UK developed and used. The keynote handled themes of public relations, talking about software licenses to lawyers, protecting privacy of developers from the wrath of the public, successful platform launches and shutdowns... a lot of stuff delivered with great pacing and enthusiasm. Timestamped link to this talk: Youtube</a> Enhancing Unix Education through Chaos Engineering and Gamification using FreeBSD, by Benedict Reuschling, Andreas Kirschner</a></h3> Benedict and Andreas had noticed that their students at Hochschule Darmstadt were not very proficient when it came to administering a UNIX system and debugging issues on it. They devised a platform where their students use exercise environments (with root access) and solve problems like DNS problems against the clock. The fastest student teams get winning points on a leaderboard. The talk format was a mix of a war story and tech demo: they explained their pedagogical conundrum and walked the viewers through their solution, which was based on FreeBSD and liberal use of jails. Timestamped link to this talk: Youtube</a> AI slop attacks on the curl project, by Daniel Stenberg</a></h3> Daniel is the main developer in the curl</code> project. In his Sunday keynote he explained how the project is being pestered by AI generated, low effort security issue reports that take up a lot of contributor time to review. Why not just block those people outright? Daniel argues that they take all reports indicating a critical vulnerability seriously; they can not allow to mistakenly disregard a valid report. Daniel is an entertaining speaker with big responsibility in the open source world. Sadly, the talk seems to not be recorded on Youtube. Community</a></h2> I was curious to see what the people are like. I knew that BSD is a pretty niche thing so I was afraid the community might be hard to get into, but I was happy to notice that everyone that I talked to seemed very welcoming and excited to share. I noticed that there was very little "hierarchy" at the event. Speakers, sponsors and attendees were all mingling together at lunches and at social events. I didn't really see signs of cliques or circles that didn't accommodate newcomers. Since the event, I have familiarised myself with BSD community channels such as the FreeBSD IRC channels</a> on Libera.Chat and the various forums of BSD Cafe</a>, hosted by Stefano Marinelli, who was also speaking at the conference. A group photo was taken on the final day</figcaption> </figure> There and back again, and the touristy bits</a></h2> There were no direct flights from Helsinki to Zagreb, so I had to layover in Germany both on the way there and on the way back. Leaving Finland, the departure time was gnarly: around five in the morning. Good thing I can sleep in economy. I had plenty of time to change planes, and got to the destination without a hitch. I stayed in B&B Boutique Casablanca, which was a nice bed & breakfast place with friendly staff. Traditional & local foods were my primary target when looking for restaurants. My top picks: ćevapi at Plac (Tripadvisor</a>), pictured below</li> štrukli at La Štruk (Website</a>)</li> </ul> A serving of ćevapi with cream cheese and paprika spread</figcaption> </figure> The return trip was more eventful. The plane didn't start boarding until it was more than an hour late. We were never told the reason. That delay caused me to miss my connecting flight 😑 I was rerouted via Frankfurt which turned my nice "get home for dinner" schedule into a gruesome "you're home sometime between midnight and 2 AM" trek. Luckily I got a seat on both of the rerouted flights (that was not a given). I was home after 1 AM. I have then learned that there would have been a very nice direct route from Finland to Ljubljana, which lies just across the Croatian border, accompanied by a bus route that would have taken me from city to city in a couple of hours. Now I know. The next event</a></h2> ...will be held in Brussels, Belgium. It's closer to Finland (👍) but I've heard that it's kind of a dull city to visit. Whether that's true or not, I don't know really, never been there before. But I'd prefer going a bit farther away from my home to escape the weather 😅 EuroBSDCon 2026 website</a> 🍁 Now, fall 2025 2025-10-05T00:00:00+00:00 Late summer and early autumn have been a time of ups and downs. I lost my father to illness. The passing was expected, in a way, so I have had time to process things in advance, but when it actually happened it turned everything on its head for a while. Sorting out things after the death has taken a lot of time and effort, but things are now more or less in order. I have got a lot of support and help from my peers, and I feel I have let myself process the grief well. I try to focus on positive things. We've also been planning the wedding that's taking place in 2026. In many ways I feel out of my element, but things are moving forward. Home</a></h2> A lot of renovations this summer. One of the biggest ones was the translucent roofing installation: Installing the sunroof</figcaption> </figure> After around six hours (including breaks), it's all done! Just in time for rain. Complete sunroof</figcaption> </figure> You can see the gnarly reddish wall in the picture. That and a bunch of other grime and residue was cleaned off as part of a neighborhood exterior painting project. The place is looking a lot nicer now from the outside (no pictures of this I'm afraid). We also got some minor things done, like installing curtains to my fiancé's office room. I got some new toolboxes that I use to keep everything nice and organized, and hidden away when not needed. With all the materials and tools lying around our home has felt like a job site, but now that everything's done and cleaned up, I'm happy that everything got done as well as it did. FreeBSD server</a></h2> I have been setting up a home server and writing a blog series about it. Check out parts one</a> and two</a>! My plan is to move things back from the cloud & other people's computers back to my home and self-host as many things as possible. Books</a></h2> Finished Robert Nystrom, Crafting Interpreters</li> Michael W. Lucas, Absolute FreeBSD</li> Michael W. Lucas, FreeBSD Mastery: ZFS</li> Michael W. Lucas, FreeBSD Mastery: Jails</li> Leo Brodie, Thinking Forth</li> </ul> Started Benjamin C. Pierce, Types and Programming Languages</li> Adam Aleksic, Algospeak</li> </ul> Games</a></h2> Played Bomb Rush Cyberfunk</li> Hollow Knight: Silksong</li> </ul> Started God of War: Ragnarök</li> </ul> Enjoyed as a VOD/live stream Watched CDawgVA's playthroughs of MGS 1–3 and Revengeance</li> A lot of Silksong VODs and speedruns</li> </ul> Travel</a></h2> I late August I went on a company trip to Krakow, Poland for one weekend. A nice city with beautiful old town buildings, but sadly the weather was a bit dull. My favorite food spot was the Black Duck</a> 😋. In September we had booked a trip to Italy with a group of friends. We stayed in Rome for a couple of days, enjoying the 30C heat and sights such as the Villa Borghese. We had already visited the Colosseum and the Vatican on earlier trips so we decided to avoid the queues and visit less popular places. It was the Jubileum year so many sights were jam-packed. After that we got a rental and drove ~500km south to Calabria, where we spent the next week at a really nice villa overlooking the sea. The view from the villa</figcaption> </figure> Later in September I attended EuroBSDCon 2025 in Zagreb, Croatia. A lot of great talks and lab sessions! I might write a conference notes post about the trip. So, a lot of traveling in a short timespan, so I've been feeling quite exhausted. The rest of the autumn is looking less hectic, so I might be able to work on projects more 🤔 Anime</a></h2> Puella Magi Madoka Magica</li> Started Kill la Kill</li> Chainsaw Man (still a couple of eps to go)</li> </ul> Previous update</a></h2> ☀️ Now, summer 2025</a></li> </ul> A home server journey, part 2: Hardware 2025-10-04T00:00:00+00:00 “My first impulse, when presented with any spanking-new piece of computer hardware, is to imagine how it will look in ten years’ time, gathering dust under a card table in a thrift shop.” ― William Gibson, Distrust That Particular Flavor</cite> </blockquote> This is the second post in a blog series chronicling my progress with designing and setting up a new, physical FreeBSD home server. Last time we went over my motivations, and this time we're looking at the physical hardware. Check out episode 1</a>. Budget specs</a></h2> My yearly cost in the public cloud is around 420€. It feels reasonable for a project of this caliber that a year’s expenses could buy a capable minicomputer. What is a capable minicomputer then, you may ask. Well, my needs are pretty straightforward: Qualitative requirements</td></tr> Usefulness</td> Can run a range of small to medium load web services without a hitch</td></tr> Trustworthiness</td> Data is durable, disk failures are not catastrophic, I can sleep at night</td></tr> Expandability</td> Can add more terabytes in the future</td></tr> Quantitative requirements</td></tr> CPU</td> Low power, economical, can run FreeBSD.</td></tr> Memory</td> Won’t OOM swap in day-to-day operation, ZFS is happy</td></tr> Disk I/O</td> I don’t really care, no high-throughput required. As long as it’s not especially bad (i.e. HDD-level bad).</td></tr> Disk space</td> Slots for multiple SSDs (RAID). Enough space to hold important files and some media with redundancy. No need for data hoarding.</td></tr> Network</td> 2 interfaces (private and public networks), Gigabit ethernet. No need for wireless.</td></tr> Annoyance</td> Low noise, low temps, sleek form factor</td></tr> </table> With this list of requirements, I handwaved some models and numbers: CPU: Intel N series ⭐️</li> Memory: 16GB</li> Disk space: 2TB (usable)</li> </ul> ⭐️ Intel N series processors, formally known as Alder Lake-N</a> and Twin Lake-N</a>, are affordable processors designed to be primarily used in mobile devices, lower end laptops (think Chromebooks) and small workstations. Some models, such as the N100, N150, N200 and N250, have thermal power ratings as low as 6W, making them popular in the passively-cooled, quasi-embedded design space: routers, NAS's, and the like. </blockquote> I got the idea for an Intel N series chip from a friend who has succesfully set up computing cluster from a bunch of small machines with those chips. They seemed to be just what I was looking for. With these, I sail off towards the east (AliExpress). By the way, I also looked at ARM and RISC-V chips for this. I figured that if Apple Silicon can work as well as it does while being based on ARM, what's stopping me from reaping the same benefits, at least in part? ARM has T1 support from FreeBSD. Turns out that there simply aren't any reasonably priced machines based on chips comparable to e.g. the Intel N150. Everything's either designed for mobile devices or just prohibitively expensive. Maybe there is no market yet for small non-x64 computers? Sourcing the silicon</a></h2> AliExpress, an online retailer based in China, is nice since they have a huge variety of devices at prices that would never be profitable if sold in a western shop. I would prefer to buy European in this current political atmosphere, but I'm working off a budget, and limiting my options to reputable and ethical vendors would force me to relax my requirements a lot or stop the project in its tracks altogether. Some of the results of a "mini pc" search query</figcaption> </figure> I'm happy to notice that there is a varied selection of devices at the ~200€ price point. Some are designed to be network devices, with a bunch of physical interfaces and limited storage options, while some are clearly NAS oriented, with SATA 3.5" drive bays capable of housing two or four disks, most commonly. I'm looking for something in the middle ground: I need two physical interfaces (a property of router-likes) but I also need storage, preferably of the solid state variety (a property of NAS-likes). Conclusion: I'm going with this one (possibly stale link warning): Topton Pocket Mini PC</a>. With some mystery promotions applied, I had to only pay 162.27€, with free shipping. I also purchased 16GB of RAM (Crucial DDR5 SODIMM 4800MHz) separately, also from AliExpress. AliExpress tends to have multiple layers of ‼️ LIMITED SALE ‼️ and 🤑 TOP DEAL COUPON 🤑 going on at the same time. In the mobile app they also have a bunch of connect-four-type games that can score you big AliExpress Coins©. Please continue consuming. </blockquote> A promotional image of the mini PC I picked, hosted here in case the product page goes poof. Please enjoy the broken English.</figcaption> </figure> Regarding disks, I think I want to buy them locally, just in case there are issues with them. It's way less stressful to handle returns and such with a local vendor than with an overseas megacorp. I feel that stuff like RAM is pretty often OK even if bought from less reputable sources, but with disks I don't want to test my luck. Conclusion: I'm going to get 4 x 1 TB (double the required usable space because of mirroring) of basic NVMe drives from a computer parts shop (Gigantti) nearby. Setting up hardware</a></h2> The box arrives after a bit of a wait (par for the course for the cheapest delivery option, China Airmail). Everything seems to be in order content-wise, but there is no installation manual whatsoever included. I would like one, since I need to figure out how to install the RAM stick. It seems to somehow go below the NVMe sticks, but there is no obvious mechanism for detaching the NVMe bay. However, with a bit of trial and error I find the correct screw to remove. The top layer comes off, revealing the RAM stick slot underneath. Very carefully I slot in the memory and push down the clamp that fixes it in place. With similar care I put the drive bay back in, and connect the four NVMe drives and stick on their respective thermal material stickers that conduct heat for the drives to the heatsink on top of the machine. I screw everything in place with the tiny screws that came with the machine. A magnetic screwdriver would be a godsend now! After a bit, everything's put together. After connecting the power cable, the machine powers on without me even touching the power switch, which is a bit surprising, but ok. I hear the POST beep. Success! To be continued</a></h2> In the next part(s) we will be looking at installing FreeBSD for the first (and second) time, and networking. I had some – let's say curious – issues with DHCP leases from the ISP. We might also take a look at my jail setup. A home server journey, part 1: Motivation 2025-06-30T00:00:00+00:00 This is the first post in a blog series chronicling my progress with designing and setting up a new, physical FreeBSD home server. I'm guessing this will become at least a three-parter, but that depends on how things actually go, and how in-depth I happen to write. This first part is about my motivations and requirements, whereas the latter ones will be more technical-deepdive-like. A promotional image portraying the mini-PC I ended up getting</figcaption> </figure> I need a place to run code and store files</a></h2> I have pretty simple requirements for a server. I need to run a bunch of services, most of which are Node.js or Python apps, and serve some static websites and files. These are primarily personal applications: tracking finances, or keeping track of house chores, but also hobby projects that I host and expose to the world. I also need to store files somewhere, like everyone that partakes in the modern digital society. There isn't that much data to store, really. I don't take that many photos or videos, which tend to be the main driver for purchasing more cloud storage, but I have some Ableton project files (music production) that take up some space. Currently all my project files fit in a couple dozen gigabytes. I store them alongside my documents in Google Drive, using a real-time Drive sync app. This does not include the audio samples and recordings in my projects: I would have to buy a restrictively expensive plan to store those in Drive. I have a trusty Ubuntu server, chugging away in some rack in a DigitalOcean datacenter in Amsterdam. Even though DigitalOcean pricing is pretty reasonable for individuals in general, my monthly price tag is around ~35€, after taxes. That sum is based on the cost of running a medium sized x86-64 instance and storing some backup snapshots from that machine. Times twelve, that comes to around 420€ per year. To me, that is a sizeable amount of money. DigitalOcean is charging $36.14 this month</figcaption> </figure> 🤔 I would like to run a smaller instance, but I needed a certain level of RAM to reliably run Obsidian Sync. For whatever reason, less memory would have the app crash intermittently. </blockquote> Having upgraded to instance to the current size, it is hard to downscale back to a smaller machine. It is possible, of course. But instead of doing that, I started to consider an alternative: maybe I could save some coins and get some hardware of my own, like in the prehistoric times, before cloud services became the de-facto way to run anything. With one year's cloud costs, I could surely get a capable small machine. Old man yells at Cloud (FFVII)</figcaption> </figure> Ownership and control</a></h2> Money is not the only motivator. I dislike the idea of having the continuity of my digital presence rely on American / multinational corporations that have no real responsibility when it comes to ensuring my files stay intact, containers running and website up. Google could ban my account without batting an eyelid, which would directly make me lose access to my collection of personal photos, important documents, and various other files I prefer not lose. DigitalOcean could flag my server for suspicious activity. All this isn't very likely, but it still happens. And even if it didn't, I don't like having a soulless, corporate entity being the arbitrator on whether I can access my own digital life or not. I would prefer to have the probability of an account-frozen catastrophe be exactly zero instead of 0.1%. 🤔 In terms of cloud provider trustworthiness, I think DigitalOcean is pretty high up in the rankings. I haven't seen much ire against them.🤔 </blockquote> I could provide these capabilities to myself, by managing my own hardware and networking. I could set up a NAS (network attached storage) box for the files, and run the services locally on either the same machine or some other hardware. It would have to be publicly accessible (Internet), just like my DigitalOcean VPS. It would have to provide at least the same guarantees as the status quo: periodic restorable backups, redundant storage and at-rest encryption for stored files. As an alternative, I could move my stuff to a European, maybe even Finnish, company. There are some shared hosting</a> providers that exist. I don't really consider this to be that good of an option. I feel that if I'm moving out of the public cloud, I might as well go all the way. </blockquote> To replace something as generally trusted and widely used as Google Drive requires some proper thinking. I haven't previously set up any redundant disk storage. My systems have never followed the 3-2-1 backup rule</a>. Maintain at least 3 copies of your data, keep 2 copies stored at separate locations, store at least 1 copy at an off-site location. Source: msp360.com</figcaption> </figure> Reaching for full ownership and control is not solely an objective aim. It is in part psychological, an attempt to get back control in a world of weakening privacy and walled content gardens. It is driven by emotion. And this is completely fine: humans are allowed to be motivated by emotion, especially when it comes to personal, hobby-adjacent things. To claim otherwise would be dishonest. Physical electronics are fun, tinkering is fun</a></h2> There is an inherent value in physical things. People collect music on CDs, cassette tapes, and vinyls. Playing games on real hardware is seen differently from emulation. A computer running in my home is "more real" than a resource-sharing virtual machine in some datacenter. It is nice to own, instead of rent. It is nice to not be bound by a contract, or a service agreement. Having fewer dependencies, legal or technical, is often favorable. I can pick out the components and design the infrastructure for my system. I know the moving parts, I know that if something fails, one of the cogs in the machine has stopped turning. I then replace the cog. There is no mystery, at least in an unknown-unknowns</a> kind of way. As long as things are not that serious, maintaining and administrating physical systems can be pretty fun. Simplicity begets reliability</a></h2> Physical components are one thing, software is another. I have been running Ubuntu on the VPS for a long time, but I can think of multiple reasons to reconsider that choice. When I picked Ubuntu years ago, I didn't know what kind of programs I would be running on the machine. I opted for a Linux distribution that is well supported and offers relatively recent versions of software. I was also uncertain about whether or not I would need to run graphical software. Ubuntu ships with snap</code> and flatpak</code> , both of which are used to run desktop apps. It is now clear to me that I don't need any of this; stable server software is all I need. I am inspired by simplicity. I feel that systems are often improved by removing, not adding. I don't understand what is going on in a Ubuntu installation. There are so many components that interact, it's hard to make sense of what affects what. There are sediment layers of Linux history in there, with some Canonical-added goodness in between. To be fair, I don't think I understand the inner workings of any Linux distribution, for that matter. A friend had recently set up a bunch of machines using FreeBSD. The elegance of simplicity lures me in. FreeBSD is well respected when it comes to running stable server software. The system boots up with just a couple of processes running in top</code>. The fantastic FreeBSD handbook</a> and supplementary reading by Michael W. Lucas</a> directly teach what each file under /etc/</code> does. I did some more reading as well as some experimentation with a FreeBSD virtual machine. It quickly became clear that this should be the way forward. I am excited to try out new, but at the same time respected and old, technology. FreeBSD is different. A familiar, but still strange system is fascinating. I have only worked with Linux systems before, so many things are as I expect them to be, while similarly many surprise me. To be continued</a></h2> In the next part we'll dive into technical good stuff: setting up the machine and installing FreeBSD. ☀️ Now, summer 2025 2025-06-15T00:00:00+00:00 A torii gate in the Kenroku-en garden</figcaption> </figure> Here's three seasons of updates in one package. AutereDB project</a></h2> I was reading Designing Data-intensive Applications</a> and I came across a chapter where the author goes over log-structured database architecture. I knew about B-tree based systems, but this seemingly simpler approach was new to me. I was intrigued, but I also felt like I didn't fully grok how every cog in the theoretical database machine worked together. Therefore, I decided to write a quick MVP thing in Rust during a conference flight. The result is AutereDB (Github</a>). AutereDB is more like a database engine. It doesn't have a query language, authorization mechanisms, multi-table support or other higher-level features. It simply makes sure that records are written to disk as expected, and queries return the correct data. You can read more about the project in the README.md</code>. I have no plans to really further this project. I feel it was a one-off to better grok how these things work. I consider this goal met; I am now more confident about reasoning about data systems. Many things that I learned the hard way during this project have already proved to be beneficial in my day job, so mission success. Help yourself to the ARCHITECTURE.md</code> file in the repository, and have a laugh at how I made multiple major miscalculations early on in the project, and then scrambled to fix these as I realized my folly. I tried to document most of these in the architecture decision log, for posterity. FemtoQueue project</a></h2> Another data-centric project I conjured up: a Python task queue library that uses files in the filesystem for task persistence, and rename()</code> to atomically move tasks from one state to another. FemtoQueue is on Github</a>, as well as on PyPI</a> as a pip-installable package. I'm pretty proud of this one. The core idea fits in under 100 lines of no-dependency Python. The current version with QoL stuff and docstrings clocks in at around 350 LoC. I could see it being very useful for small projects where you need some kind of a durable queue for sending emails etc., but don't want to add a whole separate networked Redis-like thing, or Celery or a home-cooked SQLite-based solution. Japan trip</a></h2> Me and my fiancée made a long-awaited trip to Japan in the spring. We landed in the KIX airport near Ōsaka right in the middle of the cherry blossom season, hanami. We traveled the central island, Honshū, for three weeks. Mostly by train, but also by bus. We visited Ōsaka, Nara, Kyōto, Gifu-Takayama, Kanazawa and finally Tōkyō. This route skips the popular south-coast bullet train connection, instead going north through the mountains. The garden of a preserved samurai family home, with a koi fish pond and stone lantern</figcaption> </figure> I got to finally test my Japanese. Speaking was very laborious at first, but it got way easier the more I got to practise. My vocabulary didn't improve that much, but what improved were things like cadence, aizuchi</a>, and ability to respond with more natural word choices. Big up to active listening and copying native speakers. We ate and drank well. We mostly gravitated towards traditional-style, or washoku, establishments. Our favorite meals were prepared by a sweet grandma in a hot springs guesthouse in the mountains. Simple and clean ingredients. Something to note: pickled veggies go great with meat-centered, hearty meals. We were eager to implement this in our home cooking as soon as we got home. Wagyu beef, mushroom and peppers on a tabletop charcoal grill</figcaption> </figure> We visited the obligatory tourist spots, like the Thousand torī gates in Kyōto, and the Dōtonbori shopping street in Ōsaka. We like seeing sights, but we know that our most memorable experiences have always come naturally from exploration and keeping an open mind. That's why we spent only a fraction of our time visiting Tripadvisor locations and most of the time wandering around, following local recommendations and keeping our eyes, ears and nostrils peeled. We are planning to travel there again, maybe on honeymoon. FreeBSD home server</a></h2> I have recently started a project of setting up a small publicly accessible home server that will replace my DigitalOcean VPS in some time. The system will be very FreeBSD jail focused. I have just received the hardware and verified that the everything is up to par. Very hyped about this one. I am planning to write some posts about the progress. Home</a></h2> A lot of small things need renovated. I guess this is what owning a house is. We have done a lot, and even more is still on the backlog. しょうがないね。 Going to install some patio roofing during the next couple of weeks, first time doing that. Books</a></h2> Mostly FreeBSD stuff by Michael W. Lucas</a>. Finished Designing Data-intensive Applications</a> (took a long time to work through this one)</li> FreeBSD Mastery: Storage Essentials</li> </ul> Started Absolute FreeBSD</li> FreeBSD Mastery: ZFS</li> FreeBSD Mastery: Jails</li> </ul> Games</a></h2> Played Gato Roboto</li> A Short Hike</li> Cozy Grove (watched my fiancée play this one)</li> Warhammer 40k: Boltgun</li> </ul> Enjoyed as a VOD/live stream Blue Prince</li> Rainworld</li> </ul> Anime</a></h2> Jujutsu Kaisen 0, S1, S2</li> FLCL Progressive</li> Demon Slayer: Mugen Train</li> Evangelion rebuild movies</li> Blame! (movie)</li> Puella Magi Madoka Magica</li> Dandadan</li> Chainsaw Man (still a couple of eps to go)</li> </ul> Previous update</a></h2> 🍁 Now, fall 2024</a></li> </ul> My pile of incomplete projects 2025-04-28T00:00:00+00:00 The number of started projects and/or empty checkboxes in my to do list is getting out of hand. I have: > 7 hobby tech projects in a state where I need to put ”just a bit” more effort to them to get them to the finish line,</li> 2 or 3 hobby tech projects that have an incalculable number of man-hours left, and</li> a nebulous cloud of non-tech stuff that should be done (and preferably prioritized).</li> </ul> Starting is easy (and fun), finishing is hard (and dull). Despite having internalized this, it is very tempting to step into the trap willingly and start another one. And now?</a></h3> I’ll make the conscious effort to finish incomplete work before starting new projects. I’m going to be a lot stricter in the scoping of my DIY software: things that are supposed to be small should be very small indeed. No extra features. jan.systems tech stack retro/prospective 2025-04-28T00:00:00+00:00 I have a website authoring system that involves Obsidian sync and a hand-crafted static site generator (SSG) written in Scheme</a> that: syncs Markdown files to my VPS</li> compiles Markdown source files into HTML pages using pandoc</li> parses and processes Markdown frontmatter as metadata</li> builds an RSS feed from the pages</li> builds the blog archive page that shows a time-sorted list of blog posts</li> builds the /now</code> page based on the most recent post with frontmatter binding type: now</code></li> copies the compilation artifacts and static files to the web server directory</li> </ul> I have a couple of qualms with this setup</a></h3> Running Obsidian Sync requires a graphical X environment, as Obsidian is a GUI app I have successfully used xpra</a> for this, since my VPS seems to have X installed (why, I'll never know). A properly headless server could use xvfb</a></li> </ul> </li> Refactoring scheme source code to weave new data through the compilation pipeline is kind of rough, and makes me long for static typing</li> A full build is slow (several seconds), mainly because of pandoc, but also because of interpreted scheme</li> A change in one file triggers a full build, since the build system does not understand incremental builds.</li> Pandoc handles inline HTML in a very weird way when using specific tags. I have not looked into why. This makes writing HTML-infused Markdown very fragile since I have to constantly manually inspect the output HTML for quirks.</li> Pandoc is very heavy in terms of disk space (I have a small VPS SSD)</li> When making edits, CPU usage on the VPS easily jumps to over 50%</li> </ul> The good parts</a></h3> It works pretty well. There as some small issues here and there, but it works. New feature: linklog</a></h3> I would like to add a new feature: rendering recent links from my linkhut profile</a> on the /liked</code> page (possibly to be renamed to /linklog</code> or something). Adding this to the current setup is possible. Linkhut has a JSON API for this use case, so I would only have to 1) parse the JSON, and 2) render a HTML fragment. Approach</a></h3> In the light of my most recent post</a> I should fight the urge to rewrite the thing in Rust. However, I really want to get rid of pandoc. As such, I will probably RiiR at some point, using a markdown library</a> instead of pandoc. MacOS: Opening Git commit prompt in active GUI editor 2025-01-29T00:00:00+00:00 This is a quick, neat thing I happened to find on accident. As a result of the application bundle system that MacOS uses ubiquitously, you can figure out the currently open application with the __CFBundleIdentifier</code> environment variable. $ echo $__CFBundleIdentifier dev.zed.Zed</code></pre> This bundle identifier uniquely identifies an installed application. Many editors or IDEs (Zed in my example) allow you to open an integrated terminal. It can be convenient to use that same graphical editor as the $EDITOR</code> for commands like git commit</code> or git rebase -i</code> instead of using vim</code> or nano</code> or some other TUI editor inside the integrated terminal. Use it like this: # $HOME/.zshrc if [ "$__CFBundleIdentifier" = "dev.zed.Zed" ]; then export EDITOR="zed -w" elif [ "$__CFBundleIdentifier" = "com.jetbrains.intellij" ]; then export EDITOR="idea --wait" fi</code></pre> Alternatively, if your editor supports setting custom environment variables for the integrated terminal, you can do that and avoid having the if-else in your shell rc. I prefer to have all my environment shenanigans in one place so I chose not to follow that route. Note that your editor must support a flag like -w</code> or --wait</code> that blocks the editor command from exiting before you close the file. If you don't do that, you will see stuff like: $ git commit Aborting commit due to empty commit message</code></pre> Path-conditional config and SSH key signing in `git` 2024-12-21T00:00:00+00:00 Today I learned about two recent-ish Git features. Conditional configs</a></h2> Since Git version 2.13, it is possible to use different Git configurations based on values such as the current branch, or what's useful in my use case, path prefix: # File: .gitconfig [includeIf "gitdir:~/Projects/Work/"] path = .gitconfig-work</code></pre> 🔗 includeIf</code> in Git documentation</a> I personally use separate Git identities and SSH keys for personal and work projects. With includeIf</code>, using the right ones is a breeze. Just make sure to includeIf</code> after your default configuration, in order for precedence to function as expected. # File: .gitconfig-work [core] sshCommand = ssh -i $HOME/.ssh/<work key name> -o IdentitiesOnly=yes [user] email = <work email> signingkey = $HOME/.ssh/<work key name> [gpg] format = ssh [commit] gpgsign = true</code></pre> I'm happy that this is supported natively, so I don't have to use any wrapper scripts, such as those described in a previous note</a>. SSH key signing</a></h2> The above config snippet also includes another recent addition: [user] signingkey = $HOME/.ssh/<key name> [gpg] format = ssh</code></pre> 🔗 gpg.format = ssh</code> in Git documentation</a> You can use the same SSH keys that you use to authenticate your pushes to sign your commits. This is a nice for multiple reasons: Most developers already have an SSH key</li> PGP keys are not as popular as SSH keys, and suffer from usability issues</li> Managing one key is less work than managing multiple keys</li> </ul> After configuring your key as a signing key, you need to enable commit signing either with git commit -S</code> or the inaccurately named configuration value: [commit] gpgsign = true</code></pre> Your Git server must support SSH key signing for your commits to show up as Verified. At least GitHub and modern versions of GitLab support this. Just make sure your corresponding public key is listed as a Signing key (GitHub) or an Authentication & signing key (GitLab). 🍁 Now, fall 2024 2024-12-10T00:00:00+00:00 Home</a></h2> Dog dug up the yard and the new grass. Multiple times even. Planted some clovers to hide the bald spot. Fixed up a vine that fell down from the wall.</li> Painted some rooms. The previous owner left them in a sorry state.</li> Built a little bathroom shelf, a little nightstand and a sound diffuser. Getting the hang of woodworking.</li> </ul>

Previous update</a></h2>

❄️ Now, winter 2025</a></li> </ul>

`To be continued</a></h2> In the next part(s) we will be looking at the specifics of the jail setup, e.g. how to create jails using jail.conf.d</code> scripts.</p>`

To be continued</a></h2>
In the next part(s) we will be looking at provisioning with Ansible.</p>

To be continued</a></h2>
In the next part(s) we will be looking at networking. I had some – let's say curious – issues with DHCP leases from the ISP. We'll also take a look at my jail setup.</p>

Tunes</a></h2>
Mostly Moomin music</a>. I went to see the Muumimusiikkia</em> show in Musiikkitalo (Helsinki) in November, and after that I haven't been able to get Shiratori's melodies out of my head. This is a positive problem.</p>

Spotify Wrapped</a></h3>
I feel like I'm using Spotify less and less. Might drop the subscription in the near future. I really don't like the policies they are driving.</p>

Previous update</a></h2>

🍁 Now, fall 2025</a></li> </ul>

FreeBSD server</a></h2>
I have been setting up a home server and writing a blog series about it. Check out parts one</a> and two</a>! My plan is to move things back from the cloud & other people's computers back to my home and self-host as many things as possible.</p>

Anime</a></h2>

Puella Magi Madoka Magica</li>
Started Kill la Kill</li>
Chainsaw Man (still a couple of eps to go)</li> </ul>
Previous update</a></h2>

☀️ Now, summer 2025</a></li> </ul>

Previous update</a></h2>

☀️ Now, summer 2025</a></li> </ul>

A home server journey, part 1: Motivation

`To be continued</a></h2> In the next part we'll dive into technical good stuff: setting up the machine and installing FreeBSD.</p>`

☀️ Now, summer 2025

Previous update</a></h2>

🍁 Now, fall 2024</a></li> </ul>

My pile of incomplete projects

And now?</a></h3>
I’ll make the conscious effort to finish incomplete work before starting new projects. I’m going to be a lot stricter in the scoping of my DIY software: things that are supposed to be small should be very small indeed. No extra features.</p>

jan.systems tech stack retro/prospective

`Approach</a></h3> In the light of my most recent post</a> I should fight the urge to rewrite the thing in Rust. However, I really want to get rid of pandoc.</p> As such, I will probably RiiR at some point, using a markdown library</a> instead of pandoc.</p>`

MacOS: Opening Git commit prompt in active GUI editor

Path-conditional config and SSH key signing in `git`

🍁 Now, fall 2024

Jan Tuomi

Linux OCI containers as plain FreeBSD jails (without Podman)

🌱 Now, spring 2026

A home server journey, part 5: Ansible

A home server journey, part 4: Networking

A home server journey, part 3: Installation

❄️ Now, winter 2025

EuroBSDCon 2025: conference notes

🍁 Now, fall 2025

A home server journey, part 2: Hardware

Jan Tuomi

Linux OCI containers as plain FreeBSD jails (without Podman)

Upgrading the container</a></h3> I have yet to upgrade to a more recent version of the image, but I'd imagine it is as simple as:</p> stopping the service,</li> unmounting all mountpoints,</li> removing the /linux</code> directory, and</li>

🌱 Now, spring 2026

Games</a></h2> Stray</li> Pizza Tower (dropped midway, didn't spark interest)</li> Castlevania: Symphony of the Night</li> Warhammer 40K: Space Marine II</li>

Home improvements</a></h2> Quick-fire round:</p> Woodworking:</p> new windowsill and shelf in the living room great for positioning the rear bluetooth speakers</li> </ul> </li> shoe rack inside a cabinet in Marika's room</li>

A home server journey, part 5: Ansible

Project structure</a></h2> There are many ways to structure an Ansible project. I picked one that I consider to be simple:</p> a single main playbook, with tags for selective execution of sub-playbooks</li>

A home server journey, part 4: Networking

A home server journey, part 3: Installation

❄️ Now, winter 2025

EuroBSDCon 2025: conference notes

🍁 Now, fall 2025

Home</a></h2> A lot of renovations this summer. One of the biggest ones was the translucent roofing installation:</p> Installing the sunroof</figcaption> </figure> After around six hours (including breaks), it's all done! Just in time for rain.</p>

A home server journey, part 2: Hardware

Anime</a></h2> Jujutsu Kaisen 0, S1, S2</li> FLCL Progressive</li> Demon Slayer: Mugen Train</li> Evangelion rebuild movies</li> Blame! (movie)</li> Puella Magi Madoka Magica</li> Dandadan</li>

My pile of incomplete projects

jan.systems tech stack retro/prospective

MacOS: Opening Git commit prompt in active GUI editor

Path-conditional config and SSH key signing in `git`

🍁 Now, fall 2024