Unix

Webseiten mit pelican

Kleine Webseiten erstelle ich gern mit Pelican, einem statischen Seiten-Generator. Geht nice & easy und entsprechend schnell. Der Generator ist in Python geschrieben und damit extrem portabel. Tatsächlich gibt es ihn für alle Betriebssysteme, mit denen ich arbeite.

Häufiger muss ich mit einem laufenden Projekt auf einen anderen Computer umziehen. Kein Problem: Einfach das Arbeitsverzichnis herüber kopieren und auf der neuen Maschine pelican installieren.

Und dann wundere ich mich beinahe jedes mal wieder, das der Generator rummeckert und nichts erzeugt. Dann habe ich wieder mal vergessen, eine winzige Installation vorzunehmen.

Richtig ist es also, wie folgt vorzugehen:

1. Arbeitsverzeichnis rüber kopieren, wie auch immer.
2. pelican entsprechend dem jeweiligen OS installieren, z.B pkg_add pelican
3. Zusätzlich pip installieren, heisst meiste py-pip oder py3-pip oder ähnlich.
4. Einmalige Installation mit python -m pip install "pelican"

Und schon läuft der Generator einwandfrei durch. Wird auch mit Markdown gearbeitet, lautet der Aufruf:

python -m pip install "pelican[markdown]"

Keine VTs unter NetBSD mit xdm

Unter NetBSD setze ich als DisplayManager meist den slim ein. Der wird aber seit längerer Zeit schon nicht mehr gepflegt, und so bin ich auf den xdm umgeschwenkt, der ja ohnehin der bevorzugte DM unter NetBSD ist.

Also einfach den xdm in der /etc/rc.conf mit xdm=YES aktiviert, noch ein nettes Hintergrund-Image in der /etc/X11/xdm/Xsetup_0 geladen und fertig. Dachte ich zumindest.

Der xdm ist auch brav gestartet und hat die .xsession korrekt ausgeführt. Nur konnte ich jetzt nicht mehr mittels Ctrl-Fn auf die VTs, die virtuellen Terminals, umschalten. Die waren weg, und das konnte nur der xdm angerichtet haben.

So war's dann auch, aber mit ein paar wenigen Einstellungen ist das einfach zu reparieren. Das hab ich wie folgt gemacht:

1. In der Datei /etc/X11/xdm/xdm-config die letzte Zeile auskommentiert. Die Zeile sieht dann anschliessend so aus: ! DisplayManager.requestedPort:0

2. In der Datei /etc/X11/xdm/Xservers.ws wird die Zeile mit dem X-Server Aufruf (in meinem Fall war's auch wieder die letzte Zeile) wie folgt geändert: :0 local /usr/X11R7/bin/X vt05 :0

Nach einem Neustart ist die Welt jetzt wieder in Ordnung: Der X-Server läuft auf VT5, also Ctrl-F5, und auf Ctrl-F1 ... Ctrl-F4 habe ich meine Konsolen wieder. So soll es sein.

swapfile unter NetBSD

Die NetBSD-Images für aarch64 (evbarm) enthalten von Hause aus keine swap-Partition. Ehrlich gesagt hab ich die auch noch nie vermisst, und mir ist noch kein RaspBerryPi mit übergelaufenem RAM abgeschmiert. Dennoch gönne ich all meinen Raspis mit NetBSD ein kleines swapfile, ganz besonders denen, die 7/24, also rund um die Uhr laufen und arbeiten müssen, beispielsweise als Kamera-Server oder Web-Server.

Das Erstellen und Aktivieren des Swapfile mache ich so:

1. Erstellen des swapfiles mit dem Namen swapfile im Wurzelverzeichnis des Rechners mit dd if=/dev/zero of=/swapfile bs=10m count=200. Nach wenigen Sekunden ist /swapfile mit der Grösse 2GB erstellt.

2. Die Datei /swapfile erhält die Attribute 600 mittels chmod 0600 /swapfile

3. Das swapfile wird aktiviert mit swapctl -a -p 1 /swapfile

4. Jetzt noch das swapfile in die /etc/fstab eintragen, damit es bei jedem Start automatisch aktiviert wird. Die entsprechende Zeile in /etc/fstab sieht so aus: NAME=swapfile /swapfile none sw,priority=2 0 0

Und das wars's dann auch schon. Jetzt hab ich ein nervenberuhigendes swapfile auf den Raspis.

Wayland und Freebsd

Ja, ich hatte tatsächlich Respekt vor einem Umstieg von xorg auf Wayland, vielleicht sogar ein wenig Angst. Dann habe ich es real probiert, und zwar zuerst auf einem FreeBSD-Rechner mit Version 14.1 Und ehrlich: Sooo schlimm war es dann gar nicht.

Orientiert hab ich mich an der offiziellen FreeBSD-Dokumentation, und das kann ich für den ersten Start nur sehr empfehlen. In Kurzform liefs dann so ab:

Der Benutzer von Wayland muss auf jeden Fall Mitglied in der Gruppe video sein:

pw groupmod video -m berni

Die Compositoren meiner Wahl laufen alle mit dem drm-kmod Graphik-Treiber, an dem Punkt musste ich also nichts besonderes einstellen oder installieren.

Dann die Wayland-Protokolle und den seatd installiert:

pkg install wayland seatd

Alle Kompositoren benötigen ein definiertes Runtime-Verzeichnis, das z.B in der .profile oder in einem Start-Script festgelegt wird. Ich nehme dazu $HOME/.config/run:

export XDG_RUNTIME_DIR=~/.config/run

Sofern nicht vorhanden, muss run erstellt werden.

Der seatd Daemon managed die Umgebung für den Compositor. ER wird jetzt also enabled und gestartet:

sysrc seatd_enable="YES"

service seatd start

Bei den Compositoren habe ich mit wayfire angefangen. Dazu gleich einige sinnvolle Werkzeuge und Hilfsprogramme installiert:

pkg install wayfire wf-shell alacritty kitty swaylock-effects\ swayidle wlogout kanshi mako wlsunset

Ich empfehle dringend, eine (vorläufige) config-Datei zu nutzen, die dann später individuell modifiziert wird:

mkdir ~/.config/wayfire

cp /usr/local/share/examples/wayfire/wayfire.ini ~/.config/wayfire

Die meisten Einstellungen in dieser config-Datei werden ganz gut passen, damit kann man jedenfalls erst mal starten:

wayfire -c ~/.config/wayfire/wayfire.ini

Jetzt sollte der Compositor starten, ein nettes Hintergrundbild darstellen und einen Button für den Programm-Launcher zeigen.

OpenBSD sysupgrade beim BananaPi

Normalerweise ist ein System-Upgrade auf die nächste Version bei OpenBSD extrem einfach und narrensicher. Mit dem Tool sysupgrade läuft das perfekt durch.

Beim BananaPi M5 aber ist das ein wenig anders, sofern man den Rechner so eingerichtet hat, dass er OpenBSD von der internen eMMC bootet. Der Grund ist, dass diese eMMC beim Bootvorgang eine andere interne Bezeichnung hat als nachher im Betrieb.

Nachdem mir das klargemacht wurde, mache ich Systemupgrades auf dem BPiM5 nach folgendem Schema:

1. Herunterladen des neuen Installationskernel bsd.rd von openbsd.org und ins / des upzugradenden BananaPi kopieren.
2. Eintrag in /etc/boot.conf vornehmen: boot bsd.rd. Die /etc/boot.conf habe ich während der ersten Installation von OpenBSD erstellt. Dort habe ich nur set tty fb0 eingetragen. Das wurde jetzt durch boot bsd.rd ergänzt.
3. Jetzt neu Booten.
4. Das System bootet nun den neuen Kernel und startet ein Sysupgrade.
5. Nach dem Sysupgrade nicht neu booten, sondern eine Shell aufrufen. Das neue /etc-Verzeichnis ist jetzt noch unter /mnt/etc gemountet.
6. Da ausser ed zu diesem Zeitpunkt kein Editor verfügbar ist, überschreibe ich die boot.conf in /mnt/etc: echo "set tty fb0" > /mnt/etc/boot.conf. Dieser Eintrag wird benötigt, wenn die Ausgabe nach HDMI erfolgen soll, also wenn ein Monitor angeschlossen ist. Wird der BananaPi headless betrieben, ist eine boot.conf gar nicht mehr nötig.

Grundsätzlich könnte man auch bei sysupgrade so ähnlich vorgehen. Sysupgrade kann ja auch mit Parametern so aufgerufen werden, dass die neuen Dateipakete nicht gelöscht, sondern behalten werden und dass zwischen den Upgrade-Schritten nicht automatisch gebootet wird.

Dann muss zwischen den Schritten die boot.conf mehrfach geändert und dann mittels reboot manuell gebootet werden. Ist also etwas kniffeliger, aber ebenso möglich.

Boot-Medium mit EDK-Firmware für Raspberries

Einige Betriebssysteme wie NetBSD und eingeschränkt auch OpenBSD benötigen beim Raspberry 4B und 5 ein Start-Medium mit der EDK-Firmware. Damit wird der Raspberry via UEFI gebootet und kann danach das Betriebssystem laden. So weit, so gut.

Anfangs hatte ich die EDK-Firmware immer auf eine kleine SD-Karte geschrieben und diese in den Kartenslot des Rechners gesteckt. Leider ist es dann ab und zu vorgekommen, dass das Medium irgendwann beschädigt war und der Raspi nicht mehr bootete.

Daher habe ich mir aus China 10 Stück winzige SSD mit 16 GB besorgt, um darauf die EDK-Firmware zu installieren. Wo immer es ging, habe ich allerdings die Firmware auf eine kleine Partition der SSD mit dem Betriebssystem zusammen untergebracht. Die Vorgehensweise ist für beide Fälle quasi identisch.

Prinzipiell kann die Aktion unter jedem beliebigen Betriebssystem erledigt werden. Ich persönlich machs aber am liebsten unter Linux, und diesen Weg beschreibe ich hier auch:

1. Auf der SSD wird eine mit gdisk eine neue, leere GUID Partitions-Tabelle (GPT) erstellt. Dies erfolgt in gdisk mit dem Befehl o.

2. Anschliessen wird, immer noch in gdisk, die erste Partition mit n erzeugt. Ich wähle meist eine Größe von 500MB ... 1 GB. Als Partitions-Typ wird MS-basic-date (0700) gewählt. Erstelle ich eine reine Boot-SSD, gibt es noch eine zweite Partition in der gleichen Größe, ebenfalls mit Typ 0700. Diese nehme ich als Backup, wenn die erste Partition beschädigt werden sollte. Ist tatsächlich schon passier. Auf einer SSD mit dem kompletten OS verzichte ich darauf und lege die weiteren Partition nach Bedarf an, meist eine Swap- und eine Systempartition.

3. Nach dem Speicher verlasse ich gdisk und formatiere die EDK-Partition mit mkfs.fat.

4. Zur Kontrolle starte ich nun gparted und schaue nach, ob die Boot-Partition für die EDK-Firmware die Markierungen esp und boot hat. Ist dies nicht der Fall, werden sie in gparted gesetzt. Das war's dann auch in gparted.

5. Abschliessend wird die Partition gemountet und die aktuele Version der EDK-Firmware wird darauf kopiert. Die Firmware hole ich mir bei Github: EDK-Firmware für Raspberry 4 bzw. EDK-Firmware für Raspberry 5

Das war also die grobe Beschreibung für diese Prozedur. Ist, wie man sieht, nicht schwierig, aber weil ich's nicht jeden Tag mache, hab ich's mal kurz dokumentiert.

Wechselnde MAC-Adressen

Aus dem BananaPi-Forum von sinovoip:

Einige arm64 SOC-Rechner wechseln nach dem Zufallsprinzip beim Systemstart die MAC-Adresse der Netzwerkschnittstelle. Mag für manche Anwendungen gut und sicherer sein, ist aber von Übel bei festen IP-Adressen über einen DHCP-Server.

Dieses Verhalten kann unter Linux sehr einfach abgestellt werden: Unter /etc/udev/rules.d wird eine neue Datei mit dem Namen 75-static-mac erstellt mit dem Inhalt:

ACTION=="add", SUBSYSTEM=="net", ATTR{dev_id}=="0x0", RUN+="/usr/bin/iplink set dev %k address XX:XX:XX:XX:XX:XX"

Dabei wird XX:XX:XX:XX:XX:XX mit der aktuellen MAC-Adresse der Schnittstelle ersetzt. Oder, sofern man sich ein paar MAC Adressen gemerkt hat, einfach eine davon aussuchen.

locale unter Openbsd

Mit den locales auf der Console stehe ich bei OpenBSD immer ein bisschen auf dem Kriegspfad. Da sind so viele Parameter, die da hinein spielen, dass ich wohl den Überblick verloren habe.

Nach vielen Versuchen, Fehl- und Rückschlägen habe ich nun eine Konfiguration, mit der ich leben kann. Perfekt ist sie aber leider noch immer nicht.

Als erstes habe ich mich entschieden, die TERM-Einstellungen in der /etc/ttys nicht zu ändern, sondern auf der Originaleinstellung zu belassen, also auf vt220.

Sollte ich ausnahmsweise mal eine andere Einstellung benötigen, beispielsweise für den midnight-commander, so mach ich das über das Setzen von $TERM in einem Script.

Meine locale Einstellungen lege ich in der ~/.profile fest, und zwar wie folgt:

export LANG=de_DE.UTF-8
export LC_ALL=" "

Die deutsche Tastaturbelegung wird in der /etc/kbdtype mit de.nodead gesetzt.

Das Kommando locale gibt nun das hier aus:

LANG=de_DE.UTF-8
LC_COLLATE=" "
LC_CTYPE=" "
LC_MONETARY=" "
LC_NUMERIC=" "
LC_TIME=" "
LC_MESSAGES=" "
LC_ALL=\

"locale -m" sagt: UTF-8 und "locale charmap" zeigt US-ASCII.

Damit habe ich FAST alle benötigten Sonderzeichen und Umlaute auf der Tastatur - bis auf den € und den ¢. Daran muss ich wohl noch arbeiten. Unter Xorg sind natürlich alle Zeichen vorhanden.

OpenBSD: Probleme mit Arm64 Rechnern

Arm64 Rechner wie der RaspberryPi oder der BananaPi werden ja von OpenBSD recht gut unterstützt. Probleme hatte ich aber mit RaspberryPi 4B und BananaPi M5, wenn OpenBSD von einer USB-SSD booten sollte.

Dabei kam es vor, dass OpenBSD bei jedem Rechnerstart hängen blieb, weil fsck einen nicht behebbaren Fehler meldete. Sehr ärgerlich, besonders wenn die Maschinen headless betrieben werden.

Dann musste der Aufruf einer Emergeny-Shell (sh) bestätigt werden. Wurde dort ein manueller fsck gestartet, lief der ohne Fehler durch und der Rechner bootete dann durch. Es hat sogar gereicht, einfach die sh zu bestätigen und dann sofort wieder zu verlassen: Auch dann bootete der Rechner durch.

Durch Diskussionen im Forum konnte ein timing Problem ausgemacht werden.

Der Rest war einfach: Die Erkennung der USB-SSD brauchte etwas mehr Zeit. Ein Eintrag in der /etc/rc gibt dem System jetzt 5 Sekunden mehr Zeit zur Erkennung der SSD.

So habe ich ein sleep 5 in die /etc/rc geschrieben, und zwar vor die Zeile:

# If bootblocks failed to give us random, try to cause some churn
(dmesg; sysctl hw{uuid,serialno,sensors} ) > /dev/random 2>&1

Je nach System und Version befindet sich die gesuchte Zeile bei ungefähr 400.

Seitdem booten die Einplatinenrechner einwandfrei durch. Bei einem Versionsupgrade oder sysupgrade kann es aber eine neue /etc/rc geben, sodass der Eintrag neu geschrieben werden muss. Muss man halt dran denken.

NetBSD sysupgrade

NetBSD kann, wie auch OpenBSD und FreeBSD recht einfach auf eine höhere Version gebracht werden. Das Werzeug dazu heisst sysupgrade. Es wird nicht automatisch installiert, sondern muss per pkgin manuell installiert werden (# pkgin in sysupgrade).

Soll beispielsweise ein NetBSD 9.0 auf 9.3 hochgezogen werden, dann sähe der Aufruf von sysupgrade so aus:

# sysupgrade auto https://cdn.NetBSD.org/pub/NetBSD/NetBSD-9.3/evbarm-aarch64

In obigem Beispiel wird ein NetBSD für einen RaspBerryPi mit arm64 Prozessor hochgezogen. Das war's aber auch schon, und die Prozedur läuft automatisch durch.

Soll auf ein höheres Major Release hochgezogen werden, also beispielsweise von 9.3 auf 10.0, muss ein wenig manueller Aufwand getrieben werden.

Das könnte dann für ein amd64-System so aussehen:

# sysupgrade fetch https://cdn.NetBSD.org/pub/NetBSD/NetBSD-10.0_RC4/amd64

# sysupgrade kernel

# sysupgrade modules

# reboot

# sysupgrade sets

# sysupgrade etcupdate

# sysupgrade postinstall

# sysupgrade clean

# reboot

Fertig. Ein uname -a nach dem letzten Reboot zeigt nun ein NetBSD 10.0 an.