Posts on SpellFab

Using GitHub from IPv6-only hosts

Sat, 24 Jan 2026 13:23:00 +0200

(or: living in the present, trapped in the past)

IPv6 has been around for roughly forever™, yet in the year 2026 GitHub still behaves like the internet ends at 0.0.0.0/0.
If you are running an IPv6-only host (because you enjoy modern networking) you may have noticed that GitHub is unreachable. git clone fails and HTTPS goes nowhere.

Option 1: The /etc/hosts + proxy hack

One straightforward workaround is to route GitHub traffic through an IPv6-accessible proxy that speaks IPv4 on your behalf.

A public proxy is provided by Daniel Winzen, which exposes the GitHub services over IPv6.

Because DNS is a suggestion and /etc/hosts is the law, we simply override GitHub’s hostnames there:

2a01:4f8:c010:d56::2 github.com
2a01:4f8:c010:d56::3 api.github.com
2a01:4f8:c010:d56::4 codeload.github.com
2a01:4f8:c010:d56::6 ghcr.io
2a01:4f8:c010:d56::7 pkg.github.com npm.pkg.github.com maven.pkg.github.com nuget.pkg.github.com rubygems.pkg.github.com
2a01:4f8:c010:d56::8 uploads.github.com
2606:50c0:8000::133 objects.githubusercontent.com www.objects.githubusercontent.com release-assets.githubusercontent.com gist.githubusercontent.com repository-images.githubusercontent.com camo.githubusercontent.com private-user-images.githubusercontent.com avatars0.githubusercontent.com avatars1.githubusercontent.com avatars2.githubusercontent.com avatars3.githubusercontent.com cloud.githubusercontent.com desktop.githubusercontent.com support.github.com
2606:50c0:8000::154 support-assets.githubassets.com github.githubassets.com opengraph.githubassets.com github-registry-files.githubusercontent.com github-cloud.githubusercontent.com

After that, you can use GitHub as usual.

Without modifying /etc/hosts, you can use the proxy as following.

Via HTTPS

git clone https://danwin1210.de:1443/DanWin/le-chat-php.git

or via SSH

git clone git@github-ipv6-proxy.danwin1210.de:DanWin/le-chat-php.git

But using this approach with HTTPS you are man-in-the-middle’ing yourself on purpose (SSL is broken in the middle. So do not transfer any sensitive information! You’ve been warned!).

Option 2: NAT64 / DNS64

In short: your IPv6-only machine asks for a AAAA record, the DNS64 server makes one up from the IPv4 address, and NAT64 magically translates your IPv6 packets into IPv4 on the fly. It’s like sending a letter in Elvish and having a goblin deliver it in Klingon. Somehow, the message still arrives, but only if the magical translator (the NAT64) is awake and caffeinated. Not every network has this wizardry, but when it works, you can access IPv4-only services without touching /etc/hosts.

If your network does not support NAT64/DNS64 (and you don’t feel like doing it yourself), you can use a public NAT64 service instead.

Let’s take nat64.net as an example.

The easy way is to enter the DNS servers listed under Configure your system to use these nameservers: into your /etc/resolv.conf. However, this means that all DNS queries will then go through the DNS servers of nat64.net.

If that is not an option, find the first DNS server from the website (at the time of this blog post its 2a01:4f8:c2c:123f::1) and we’ll use the magic of /etc/hosts again.
To do this, we find the AAAA DNS entry of github.com via nat64.net’s DNS server and add to it:

dig +short github.com AAAA @2a01:4f8:c2c:123f::1 | sed -e 's/$/ github.com/g' >> /etc/hosts

After that, github.com should be usable as normal for cloning repositories.

Eine VM auf Uberspace betreiben

Tue, 07 Oct 2025 13:23:00 +0200

Zu Urzeiten, als es weder Xen noch KVM gab, hab ich, nach einem kurzen Intermezzo zu Linux-VServer, User Mode Linux genutzt, um virtuelle Server zu betreiben.

Hierbei wird der Kernel als normaler (Userspace-)Prozess gestartet.

Ich habe mir die Frage gestellt, ob ich eine VM mithilfe von User Mode Linux auf Uberspace betreiben kann.

Die Kernelkonfigurationsdatei (.config) habe ich aus dem debian-Paket (config.amd64) genommen.

Der Versuch den Kernel auf meinem Uberspace zu kompilieren ist aufgrund der Betagtheit des CentOS mit irgendwelchen obskuren Fehlern abgebrochen - nach der dritten Datei, die ich manuell angepasst habe, hatte ich keine Lust mehr und habe geschaut, wie ich den Kernel auf meinem Rechner als statisches Programm kompilieren kann.

Nur CONFIG_STATIC_LINK=y zu setzen, hat bei mir nicht geklappt - ich musste in der arch/um/Kconfig zwei Zeilen unter config STATIC_LINK noch eine Zeile auskommentieren:

#    depends on CC_CAN_LINK_STATIC_NO_RUNTIME_DEPS || !MAY_HAVE_RUNTIME_DEPS

Danach ein beherztes make ARCH=um und nach einiger Zeit hatte ich ein statisches linux-Binary.

Das Dateisystem des User Mode Linux ist ein Imagedatei und da ich bei Uberspace kein root habe, musste ich das Image auf meinem Rechner vorbereiten:

dd if=/dev/zero of=debian.img bs=1M count=$((1024*5))
mkfs.ext4 debian.img
mount -o loop debian.img /mnt
debootstrap trixie /mnt

Die erste Zeile erstellt eine Imagedatei, die 5 GB groß ist, die zweite erstellt ein ext4-System darin, die dritte mountet dieses nach /mnt und die letzte Zeile installiert ein Debian trixie.

Danach bin ich per chroot /mnt /bin/bash in das neue System gewechselt. Es müssen alle Standard-Terminals deaktiviert (und maskiert) werden und stattdessen eins auf tty0 gestartet werden:

rm /etc/systemd/system/getty.target.wants/getty@*
for i in $(seq 2 6); do ln -sf /dev/null /etc/systemd/system/getty@tty$i.service; done
ln -sf /dev/null /etc/systemd/system/getty-static.service
ln -s /usr/lib/systemd/system/getty@.service /etc/systemd/system/getty.target.wants/getty@tty0.service

Außerdem habe ich per passwd ein root-Passwort gesetzt.

Auch die Netzwerkkonfiguration kann man schon gut vorbereiten:

cat >> /etc/network/interfaces <<EOF

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
    address 10.0.2.15/24
    post-up ip route add default dev \$IFACE
EOF

Abschließend die Chroot-Umgebung per exit verlassen und die Imagedatei mit umount /mnt unmounten.

Das Image habe ich danach einfach per SCP auf meinen Uberspace kopiert.

Soweit so gut. Als ich User Mode Linux früher als Virtualisierungslösung benutzt habe, habe ich die Netzwerkanbindung mit TAP-Devices realisiert, was jedoch root erfordert, was ich, wie oben erwähnt, bei Uberspace nicht habe.

In der Netzwerkdokumentation vom User Mode Linux bin ich jedoch über den Satz “slirp - if you don’t have root access on the host to setup networking, or if you don’t want to allocate an IP to your UML” gestolpert. Das klang genau nach dem was ich brauchte.

Also flugs die Quellen runtergeladen (vom Debian-Mirror, weil zum kompilieren sowieso die Patches aus dem Debian-Paket notwendig sind):

mkdir ~/slirp
cd ~/slirp
wget http://deb.debian.org/debian/pool/main/s/slirp/slirp_1.0.17.orig.tar.gz
wget http://deb.debian.org/debian/pool/main/s/slirp/slirp_1.0.17-11.debian.tar.xz
tar xf slirp_1.0.17.orig.tar.gz
tar xf slirp_1.0.17-11.debian.tar.xz
cd slirp-1.0.17/
for i in ../debian/patches/*.patch; do patch -p1 -i "$i"; done
cd src/
./configure
make CFLAGS="-I. -DUSE_PPP -DUSE_MS_DNS -fno-strict-aliasing -Wno-unused -std=gnu89 -DFULL_BOLT"

Da ich das User Mode Linux hinterher per SSH erreichen wollte, musste ich einen Port in der Uberspace Firewall öffnen:

uberspace port add

Damit das Portforwarding für SSH funktioniert, brauchte es zum Starten von Slirp ein Wrapperscript:

#! /usr/bin/env bash

exec /home/USERNAME/slirp/slirp-1.0.17/src/slirp "redir PORT 22" "host address 10.0.2.2"

USERNAME ist hierbei durch den eigenen Uberspace Benutzernamen und PORT durch den eben geöffneten Port ersetzt werden.

Jetzt konnte ich das erste mal das UML starten:

/home/USERNAME/linux ubd0=/home/USERNAME/debian.img root=/dev/ubda rw mem=256M eth0=slirp,,/home/USERNAME/slirp.sh reboot=force

Das mem=256M sagt hierbei, dass das User Mode Linux maximal 256MB RAM nutzen darf, was okay sein sollte, da auf https://manual.uberspace.de/basics-resources/#ram steht, dass ein Asteroid maximal 1.5 GB nutzen darf.

Nachdem das User Mode Linux gestartet war, konnte ich mich einloggen (mit root und dem Passwort von oben) und per apt-get --no-install-recommends install openssh-server einen SSH-Server installieren. Danach habe ich noch meinen SSH Public Key nach /root/.ssh/authorized_keys gelegt und konnte mich per SSH einloggen:

ssh -pPORT USERSPACE-HOST

Fazit: Man kann das machen, es ist aber nicht besonders schnell. Ich sehe das ganze nur als PoC und werde das nicht produktiv betreiben.

Wo kommt denn der zweite gpg-agent her?

Mon, 25 Aug 2025 13:23:00 +0200

Ich hab vor einiger Zeit von ArchLinux auf debian gewechselt. Danach fiel mir auf, dass wenn ich pass nutze und danach SSH, ich zweimal die PIN für den Yubikey eingeben muss. Außerdem hat manchmal pass nicht funktioniert, wenn ich es nach SSH aufgerufen hab (da wurde dann die “GPG-Smartcard” (der Yubikey) gar nicht gefunden). Da war dann die Lösung den Yubikey einmal neu zu stecken und danach pass vor SSH aufzurufen.

Auffällig war, dass nach dem pass-Aufruf immer ein zweiter gpg-agent lief. Ich hab mir eine zeitlang damit beholfen in die ~/.gnupg/scdaemon.conf pcsc-shared zu schreiben - damit ist der Yubikey nicht exklusiv von einem der beiden gpg-agents blockiert, aber nach dem Update auf trixie ist noch irgendwas anderes schief (dazu in einem anderen Blogpost mehr), so dass ich bei jedem Zugriff auf den Yubikey die PIN eingeben muss. Also musste ich mal das eigentliche Problem lösen.

Also mal Yubikey angesteckt, eine SSH-Verbindung aufgebaut und danach pass aufgerufen. Es wird ein zweiter gpg-agent gestartet und der pass-Aufruf funktioniert nicht. Soweit kennen wir das ja schon. Das googlen nach den Parametern, mit denen der gpg-agent gestartet wird (--use-standard-socket --daemon) hat mich dann zumindest drauf gebracht, dass er wohl mittels gpgconf --launch gpg-agent gestartet wird, hat sonst aber wenig Erkenntnisse gebracht.

Dann also mal strace auf den pass-Aufruf geschmissen und das große Wundern geht los: Wieso wird der gpg-agent-socket in /run/user/1000/gnupg/d.4wrkznjfxmhuw5861gsoydhj/S.gpg-agent gesucht, wenn doch die systemd-User-Unit %t/gnupg/S.gpg-agent als Pfad vorgibt (was /run/user/1000/gnupg/S.gpg-agent ist).

Nach einigem Googlen nach der Frage wie man den Ort des Sockets anpassen kann, bin ich auf https://gnupg-users.gnupg.narkive.com/1JY1lXWm/change-agent-socket-path gestoßen wo ich folgenden Absatz fand:

If you use a GNUPGHOME different from ~/.gnupg gpg will not connect
to /run/user/1000/gnupg but to /run/user/1000/gnupg/SOMEDIR/. That dir
is not created on the fly but requires that the user creates it in
advance. SOMEDIR is the hash of GNUPGHOME and gpgconf has a command to
compute that hash and create the directory.

Ich hatte mir irgendwann im Rahmen von mein Homedir soll schöner werden überlegt, dass ich ~/.gnupg lieber in ~/.config/gnupg haben will und hab in meiner .xinitrc, .xprofile und .zshrc export GNUPGHOME="${XDG_CONFIG_HOME}/gnupg" gesetzt. Ich hatte außerdem einen Symlink gesetzt (von ~/.gnupg nach ~/.config/gnupg). D.h. eigentlich wäre die Umgebungsvariable auch gar nicht nötig gewesen…

Was ist also passiert: Der von systemd gestartete gpg-agent war für SSH zuständig (das hat auch funktioniert, da der SSH-agent über die Umgebungsvariable SSH_AUTH_SOCK bekannt gemacht wird (und nicht über komische Regeln)). Wenn ich aber gpg genutzt habe, hat es festgestellt, dass kein gpg-agent an dem angenommenen Unix-Socket lauscht und hat kurzerhand einen neuen gestartet (weil es für Smartcards (Yubikey) nötig ist, dass einer läuft).

Die Lösung: Ausgiebig ge-face-palmt, die GNUGPGHOME-Einträge aus den Dateien entfernt und ein reboot später war alles tuffi und funktioniert so wie es soll.

GPodder Sync

Thu, 31 Jul 2025 13:23:00 +0200

bitstacker hatte mich auf audiobookshelf aufmerksam gemacht, womit man die aktuelle Position in Podcasts über mehrere Geräte (z.B. Smartphone und Notebook) synchron halten kann.

Da ich aus Gründen, die ich in einem extra Blogpost noch erläutern werde, aktuell Abstand davon nehme, Kram selber zu hosten, ich die Funktionalität aber haben wollte, habe ich mich nach einer Nextcloud-App umgeschaut.

Aufgrund meiner überragenden Google-Skills (“antennapod sync”) bin ich auf https://antennapod.org/de/documentation/general/synchronization gestoßen, wo die Nextcloud-App GPodder Sync als mögliches Syncziel für AntennaPod vorgestellt wird.

Die App in der Nextcloud installiert, flugs im AntennaPod eingerichtet (man muss vorher kein Anwendungspasswort anlegen - das passiert alles während der Einrichtung) und fertig ists.

Auf der GitHub-Seite von GPodder Sync findet eine Liste kompatibler Clients. Meine Wahl ist auf Cardo gefallen. Die Einrichtung ist ähnlich einfach, wie bei AntennaPod:

Cardo starten
Aufs Zahnrad klicken
Bei SYNCHRONIZATION die Nextcloud URL eintragen und auf CONNECT klicken
Im aufploppenen Browserfenster in der Nextcloud einloggen und der App den Zugriff erlauben

Dauert einen Moment bis der dann anfängt zu syncen.

Auffe Ohren

Fri, 04 Jul 2025 13:23:00 +0200

Der gute bitstacker hat in seinem Blog geschrieben welche Podcasts er so hört und ich wollte da auch mal meinen Senf zu geben:

Erdbeeren! Überall Erdbeeren!

Thu, 03 Jul 2025 13:23:00 +0200

Letztens haben wir das wunderbare Wetter genutzt und einen kleinen Familienausflug zum Erdbeerhof Delmenhorst gemacht, wo man Erdbeeren selbst pflücken kann.

Ich hatte mir vorher Sorgen gemacht, dass unsere 1 ½ Jahre alte Tochter eher keine Lust darauf hat nicht durch die Pflanzen zu toben, aber sie saß ganz entspannt zwischen den Erdbeerreihen, hat mit unserer Hilfe hier und da selbst ein paar Beeren gepfückt und futterte zwischendurch genüsslich angereichte Erdbeeren.

Am Ende hatten wir trotz ihrer kleinen Naschpausen mehrere Kilo zusammen - aus denen wir, als wir wieder zu Hause waren, selbstgemachte Erdbeermarmelade gemacht haben.

Hierzu braucht man 500g 3-zu-1-Gelierzucker und 1500g frische Erdbeeren.

Zuerst muss man die Erdbeeren gründlich waschen, entstielen und klein schneiden. Die Erdbeeren in einem ausreichend großen Topf zusammen mit dem Gelierzucker unter ständigem Rühren zum Kochen bringen (hierbei Überkochen vermeiden!). Dann mindestens 4 Minuten sprudelnd weiterkochen und dabei umrühren.

Anschließend eine Gelierprobe machen (etwas Marmelade auf einen kalten Teller geben - wird sie fest, ist sie fertig). Die heiße Marmelade sofort randvoll in vorbereitete Gläser füllen, gut verschließen und auf den Deckel stellen.

Debian auf einer Compute Instanz in der Oracle Cloud

Thu, 19 Jun 2025 20:31:37 +0200

Letztes Wochenende hab ich mir endlich mal die Free Tier Instanz (AMD based Compute VMs with 1/8 OCPU and 1 GB memory each) in der Oracle Cloud geklickt. Das hab ich schon ewig vor mir her geschoben und jetzt hab ich mal ein bisschen Zeit gefunden. Leider konnte ich nicht direkt Debian als Betriebssystem auswählen, aber als Community-Image gab es Ubuntu.

Nachdem ich ein bisschen damit rumgespielt habe, wollte ich aber doch lieber Debian haben (ich hab überall Debian installiert) - also hab ich angefangen zu suchen, ob das schon jemand gelöst hat.

Im Blog von Pieter Hollander wurde ich fündig.

Ich hab auf Verschlüsselung und Swapfile verzichtet, weil ich auf der Box nicht mehr als 1GB RAM brauche und ich Dateisystemverschlüsselung in VMs für Blödsinn halte.

Der Ablauf ist wie folgt:

Eine SSH-Verbindung in das Ubuntu aufbauen, root werden und das Ubuntu mit Alpine Linux ersetzen:

ssh -o "StrictHostKeyChecking=no" -o "UserKnownHostsFile=/dev/null" ubuntu@REPLACE_WITH_YOUR_INSTANCES_PUBLIC_IP_ADDRESS
sudo -i
cd /
wget https://dl-cdn.alpinelinux.org/alpine/v3.21/releases/x86_64/alpine-virt-3.21.3-x86_64.iso
dd if=alpine-virt-3.21.3-x86_64.iso of=/dev/sda
sync
reboot

Damit rebootet die Instanz in das Alpine Linux, wodurch der SSH-Zugriff verloren geht, da Alpine Linux standardmäßig keinen laufenden SSH-Server hat.

Über die Oracle Cloud Console muss eine Konsolenverbindung erstellt werden.

Dafür auf Compute, Instances und Instance details klicken.

Dann die Instanz auswählen, herunterscrollen und bei Console connection auf Launch Cloud Shell connection klicken.

Wenn die Verbindung zu dem Cloudserver aufgebaut ist, steht im Fenster Instance Console Connection reached state: ACTIVE.

An dem erscheinenden Loginprompt mit dem Benutzernamen root und ohne Passwort einloggen.

Als erstes muss die Netzwerkkonfiguation gefixt werden:

vi /etc/network/interfaces

i drücken, um dein Einfügemodus zu aktivieren.

auto eth0
iface eth0 inet dhcp

Mit :wq den vi verlassen und speichern. Danach das Netzwerk neustarten:

/etc/init.d/networking restart

Um nicht alles in der - doch etwas anstrengenden - Konsole zu machen, richten wir uns den SSH-Server ein:

setup-sshd
Which ssh server? ('openssh', 'dropbear' or 'none') [openssh]
Allow root ssh login? ('?' for help) [prohibit-password]
Enter ssh key or URL for root (or 'none') [none]
 * service sshd added to runlevel default
 * Caching service dependencies ...
 [ ok ]
ssh-keygen: generating new host keys: RSA ECDSA ED25519
 * Starting sshd ...
 [ ok ]

Den öffentlichen SSH-Schlüssel ablegen:

mkdir /root/.ssh
vi /root/.ssh/authorized_keys

Danach per SSH weitermachen:

ssh -o "StrictHostKeyChecking=no" -o "UserKnownHostsFile=/dev/null" root@REPLACE_WITH_YOUR_INSTANCES_PUBLIC_IP_ADDRESS

Das Alpine Linux auf eine Ramdisk bewegen und von da weiterarbeiten:

mkdir /media/setup
cp -a /media/sda/* /media/setup
mkdir /lib/setup
cp -a /.modloop/* /lib/setup
/etc/init.d/modloop stop
umount /dev/sda
mv /media/setup/* /media/sda/
mv /lib/setup/* /.modloop/

Paket-Repositories konfigurieren und benötige Pakete installieren:

setup-apkrepos
apk update
apk add dosfstools e2fsprogs debootstrap cryptsetup nano gptfdisk partx btrfs-progs

Die Festplatte partitionieren:

gdisk /dev/sda

3 drücken, damit gdisk eine neue GPT-Partitionstabelle erstellt.

Command (? for help): n
Partition number (1-128, default 1):
First sector (34-104857566, default = 2048) or {+-}size{KMGTP}:
Last sector (2048-104857566, default = 104855551) or {+-}size{KMGTP}: +1024M
Current type is 8300 (Linux filesystem)
Hex code or GUID (L to show codes, Enter = 8300):
Changed type of partition to 'Linux filesystem'
Press n to create the EFI partition. Make it 512MB and set it to EFI.

Command (? for help): n
Partition number (2-128, default 2):
First sector (34-104857566, default = 2099200) or {+-}size{KMGTP}:
Last sector (2099200-104857566, default = 104855551) or {+-}size{KMGTP}: +512M
Current type is 8300 (Linux filesystem)
Hex code or GUID (L to show codes, Enter = 8300): EF00
Changed type of partition to 'EFI system partition'
Press n to create the root file system partition. Make it use all available remaining disk space.

Command (? for help): n
Partition number (3-128, default 3):
First sector (34-104857566, default = 3147776) or {+-}size{KMGTP}:
Last sector (3147776-104857566, default = 104855551) or {+-}size{KMGTP}:
Current type is 8300 (Linux filesystem)
Hex code or GUID (L to show codes, Enter = 8300):
Changed type of partition to 'Linux filesystem'
Press p to display the partition table. It should give the following result:

Command (? for help): p
Disk /dev/sda: 104857600 sectors, 50.0 GiB
Model: BlockVolume
Sector size (logical/physical): 512/4096 bytes
Disk identifier (GUID): 57C983BB-7A42-4B74-BD69-F9A0AEFD5199
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 104857566
Partitions will be aligned on 2048-sector boundaries
Total free space is 4029 sectors (2.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         2099199   1024.0 MiB  8300  Linux filesystem
   2         2099200         3147775   512.0 MiB   EF00  EFI system partition
   3         3147776       104855551   48.5 GiB    8300  Linux filesystem

Mit w speichern und beenden.

Anschließend muss eine MBR-Partitionstabelle auf die Festplatte geschrieben.

Dazu zunächst die alte MBR-Partitionstabelle löschen…

partx -v -d /dev/sda
partition: none, disk: /dev/sda, lower: 0, upper: 0
/dev/sda: partition #1 removed
/dev/sda: partition #2 removed
/dev/sda: partition #3 removed

…und die neue schreiben:

partx -v -a /dev/sda
partition: none, disk: /dev/sda, lower: 0, upper: 0
/dev/sda: partition table type 'gpt' detected
range recount: max partno=3, lower=0, upper=0
/dev/sda: partition #1 added
/dev/sda: partition #2 added
/dev/sda: partition #3 added

Alle Partitionen formatieren…

mkfs.ext4 /dev/sda1
mkfs.vfat /dev/sda2
mkfs.ext4 /dev/sda3

…und mounten:

mount -t ext4 /dev/sda3 /mnt
mkdir /mnt/boot
mount -t ext4 /dev/sda1 /mnt/boot
mkdir /mnt/boot/efi
mount -t vfat /dev/sda2 /mnt/boot/efi

Debian herunterladen und installieren:

mkdir -p /mnt/var/tmp
chmod 1777 /mnt/var/tmp
debootstrap bookworm /mnt

Hostnamen konfigurieren:

echo YOUR_PREFERRED_HOSTNAME > /mnt/etc/hostname

cat <<EOF >> /mnt/etc/hosts
127.0.1.1 YOUR_PREFERRED_HOSTNAME.YOUR_DOMAIN YOUR_PREFERRED_HOSTNAME
EOF

Netzwerk konfigurieren:

rm -rf /mnt/etc/network

cat <<EOF >> /mnt/etc/systemd/network/ens3.network

[Match]
Name=ens3

[Network]
DHCP=yes
EOF

Paketquellen konfigurieren:

cat  <<EOF > /mnt/etc/apt/sources.list
deb http://deb.debian.org/debian/ bookworm main contrib non-free non-free-firmware
#deb-src http://deb.debian.org/debian/ bookworm main contrib non-free non-free-firmware
deb http://security.debian.org/ bookworm-security main contrib non-free non-free-firmware
#deb-src http://security.debian.org/ bookworm-security main contrib non-free non-free-firmware

# bookworm-updates, previously known as 'volatile'
deb http://deb.debian.org/debian/ bookworm-updates main contrib non-free non-free-firmware
#deb-src http://deb.debian.org/debian/ bookworm-updates main contrib non-free non-free-firmware

# bookworm-backports, previously on backports.debian.org
deb http://deb.debian.org/debian/ bookworm-backports main contrib non-free non-free-firmware
#deb-src http://deb.debian.org/debian/ bookworm-backports main contrib non-free non-free-firmware
EOF

In den root-Mountpoint chrooten:

mount --rbind /dev /mnt/dev
mount --rbind /proc /mnt/proc
mount --rbind /sys /mnt/sys
LANG=C chroot /mnt /bin/bash

Paketquellen und System updaten:

apt update
apt dist-upgrade -y

Die Systemsprache konfigurieren:

apt install locales -y
dpkg-reconfigure locales

Zeitzone konfigurieren:

dpkg-reconfigure tzdata

Und das Netzwerk konfigurieren:

apt purge ifupdown

systemctl enable systemd-networkd

/etc/fstab erstellen:

cat <<EOF > /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / partition
EOF

echo UUID=$(blkid -s UUID -o value \
      /dev/mapper/luks1) \
      / ext4 defaults 0 2 >> /etc/fstab

cat <<EOF >> /etc/fstab

# /boot partition
EOF

echo UUID=$(blkid -s UUID -o value \
      /dev/sda1) \
      /boot ext4 defaults 0 2 >> /etc/fstab

cat <<EOF >> /etc/fstab

# UEFI /boot/efi partition (fat32)
EOF
echo PARTUUID=$(blkid -s PARTUUID -o value \
      /dev/sda2) \
      /boot/efi vfat defaults 0 1 >> /etc/fstab

Bootloader installieren:

apt install -y grub-efi
grub-install --target=x86_64-efi --efi-directory=/boot/efi --recheck --no-floppy

Die serielle Konsole im GRUB aktivieren, damit der Zugriff auf den Server über das Webportal noch geht:

cat <<EOF >> /etc/default/grub
GRUB_TERMINAL_INPUT="console serial"
GRUB_TERMINAL_OUTPUT="gfxterm serial"
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200"
GRUB_CMDLINE_LINUX_DEFAULT="\${GRUB_CMDLINE_LINUX_DEFAULT} console=tty0 console=ttyS0,115200"
EOF
update-grub2

Den Kernel und benötigte Pakete installieren:

apt install -y linux-image-amd64 ssh systemd-timesyncd haveged wget curl net-tools git gpg build-essential dosfstools qemu-guest-agent

Und wieder den öffentlichen SSH-Schlüssel ablegen:

mkdir ~/.ssh
vi ~/.ssh/authorized_keys

Und am Ende aufräumen:

apt --purge autoremove

Danach in das Debian rebooten und genießen:

exit
reboot

Hallo Welt!

Wed, 18 Jun 2025 13:23:00 +0200

Moin. Das ist der erste Post in diesem Blog.

Ich bin mortzu oder Momo (Das kleine Mädchen in mir hatte schon immer was gegen die grauen Herren, die ihr die Zeit stehlen wollten). Ich arbeite an der Uni-Bremen als Netzwerkadministrator.

2012 hab ich den Hackerspace Bremen und 2013 das „Freifunk Bremen“-Projekt mitgegründet.

In diesem Blog erwartet euch ein bisschen Technik (Linux, Netzwerk, …), ein bisschen Familienalltag und sehr wahrscheinlich auch Heimwerkerkrams.

Zum technischen Aufbau: Das Blog ist ein Hugoblog, was in einem Git auf codeberg liegt. Ich habe zuerst überlegt, ob ich das Blog mit einem CI baue. Aber irgendwie erschien mir das Overkill. Also hab ich hugo-webhook gebaut, was darauf wartet, dass der bei Codeberg hinterlegte Webhook angesprochen wird. Dann holt es sich das Git-Repository, baut das Blog und rsynct das in den entsprechenden Ordner.

Ich freu mich über Kontakte auf codeberg oder Mastodon.