Konfekt
I migrated my git repos from my old server to my new one and used the opportunity to set up a Gitea instance while doing so. I guess it is more visually appealing than my old solution, which just dumped the master branch file tree to text files…
I still need to fix some paths inside the repos, particularly in the go.mod files. And then decide, if I want to use Gitea for release management.
In my efforts to migrate my server to a new machine and a different OS, I found myself in need of replacing FreeBSD Jails with an analogous way of containerization. My distaste for Docker outweighed my distaste for systemd, so I tried systemd-nspawn. With Jails and ezjail it was fairly easy to set up a container with a separate, static IP address to which I could redirect particular traffic, either by port or (in case of HTTP) name. I’m not completely sure about my solution with nspawn yet, but it seems ok. I switched the host network configuration from networking.service to systemd-networkd and I’m using the trick described here to keep other parts of the network setup simple. It uses the default virtual ethernet interfaces and runs a DHCP server on the host with a pool of one - thus effectively forcing a static IP. I’m using it for the same purpose as described in the link - to proxy by name via nginx. You don’t necessarily need that for redirection by port, you can just use “port mapping” there.
It makes sense to configure some resource limits for CPU and the like, depending on the application. But other than that, below is my script to create a new nspawn machine for now. It takes a machine name, installs Debian stable and sets up networking.
#!/bin/bash
set -eu
if [ "$#" -ne 1 ]; then
echo "Need machine name"
exit 1
fi
name="$1"
path="/var/lib/machines/$name"
if [[ -e "$path" ]]; then
echo "Machine already exists"
exit 2
fi
echo "Bootstrapping debian stable to $path"
debootstrap --include=systemd,dbus stable "$path"
echo "Enable networkd in container"
systemd-nspawn -M "$name" --as-pid2 rm /etc/hostname
systemd-nspawn -M "$name" --as-pid2 systemctl enable systemd-networkd
echo "Set root password"
systemd-nspawn -M "$name" --as-pid2 passwd root
# find out which virtual device name systemd uses
machinectl start "$name"
ip a
read -p "Virtual ethernet name? " veth
# set a "static" ip 192.168.x.y with
# host y = 1 and machine y = 2
# by running a DHCP server with pool size 1
numberOfMachines=`ls /var/lib/machines/ | wc -l`
machinectl stop "$name"
networkdpath="/etc/systemd/network/50-$name.network"
cat <<EOF >"$networkdpath"
[Match]
Name=$veth
Driver=veth
[Network]
Address=192.168.$numberOfMachines.1
LinkLocalAddressing=ipv4
DHCPServer=yes
IPMasquerade=ipv4
LLDP=yes
EmitLLDP=customer-bridge
IPv6SendRA=no
[DHCPServer]
PoolOffset=2
PoolSize=1
EOF
echo "Restarting networkd and starting machine"
systemctl restart systemd-networkd
sleep 2
machinectl start "$name"
machinectl enable "$name"
# list all machines with IP address
machinectl
I got bored of procrastinating the matter and migrated my server to a new machine - including the mail setup. My old machine ran FreeBSD and I used Jails to create subdivisions in the setup. ezjail (shoutout to erdgeist) made that easy enough. From time to time the setup inside the Jails broke, though, making updates difficult, and I’m more familiar with Linux - so my new machine runs Debian.
Migrating the mail setup was easier than I thought. But then again, I’m using only Postfix, Dovecot and a delivery to the Maildir of a standard Unix user account with some aliases. Postfix is configured suitably paranoid, of course, and does not try to be compatible to the 1990s. This might influence your server’s spam rating (just saying…).
It was thus only a matter of installing said programs, migrating the config - some paths are different, which is annoying -, creating the same user, copying the Maildir in /home and pointing DNS to the new machine. Done. I was pleasantly surprised.
I wanted my bookshelf to have kind of a fireplace background lighting - slightly pulsing yellow-orange light:
I chose to separate the LED slats into 4 groups, 2 slats each, so that the maximum distance between the ESP32 data out and the last LED would be small and I wouldn’t run into problems due to the difference between nominal (5V) and actual (3.3V) data logic level.
I used a perfboard to hook up four 3-pin connectors to the ESP32, which itself rests in a socket rather than being soldered to the board. The LED slats get their power directly from the 5V and GND pins and their data from GPIOs 19, 18, 5 and 17 - all right next to each other. I flashed WLED to the ESP via the web installer, made it connect automatically to my WLAN, configured the 4 LED outputs at Config > LED preferences, made a preset for the fireplace animation, et voila, done.
I can now control the book shelf backlight via smartphone or computer command. For the latter I also configured a convenient mDNS name (Config > WiFi Setup). I can then post partial JSON of the desired state to that address:
curl -X POST http://bookshelf.local/json -d '{"on":true, "ps":1}' -H "Content-Type: application/json"
… which turns on the LEDs and switches to preset 1.