Unix

AdGuardHome unter OpenBSD manuell updaten

Als Schutz gegen Tracking und lästige Anzeigen in meinem und anderen Netzwerken setze ich AdGuardHome ein und bin damit sehr zufrieden. Die Software tut, was sie soll und das absolut zuverlässig und schnell. Dazu habe ich einen SBC, und zwar einen BananaPi M5 entsprechend aufgebaut. Als Betriebssystem läuft OpenBSD, mein Favorit für fast alle Lebenslagen.

Was allerdings nicht, zumindest bei mir nicht, funktioniert, ist das automatische Update über die Web-Oberfläche. Das muss dann ab und zu manuell erfolgen, und zwar mit folgenden Schritten:

Ich habe AdGuardHome im Verzeichnis /usr/opt/AdGuardHome installiert. Gesteuert wird die Software über ein rc-Script namens adguardhome in /etc/rc.d. Das Script sieht so aus:

#!/bin/ksh
daemon="/usr/opt/AdGuardHome/AdGuardHome"
daemon_flags="-w /usr/opt/AdGuardHome"
daemon_user="root"
. /etc/rc.d/rc.subr
rc_bg=YES
rc_reload=NO
rc_cmd $1

Wenn es nun eine neue Version gibt, lade ich mir diese als .tar.gz File von der Release-Seite herunter. In meinem Fall ist das AdGuardHome_openbsd_arm64.tar.gz. Herunterladen mit curl oder wget geht natürlich auch.

Jetzt wird das Update durchgeführt:

1. Das laufende AdGuardHome beenden:
   # rcctl stop adguardhome
   Das geht aber nur, wenn das rc-Script in /etc/rc.d zur Steuerung verwendet wird. Ansonsten ins Verzeichnis /usr/opt/AdGuardHome wechseln und die Software direkt stoppen mit # ./AdGuardHome -s stop.

2. Sichern der Daten:
   Im AdGuardHome-Verzeichnis die Datei AdGuardHome.yaml und das Verzeichnis data irgendwohin sichern. Man weiss ja nie, allerdings ist bei mir bisher (tio toi toi) noch nie etwas dabei schief gelaufen.

3. Das frisch herunter geladene tarball entpacken:
   Das kann in einem beliebigen Verzeichnis erfolgen, ich machs unter /usr/opt/tmp, also in einem Parallel-Verzeichnis von AdGuardHome.
   # gunzip AdGuardHome_openbsd_arm64.tar.gz
   # tar -xvf AdGuardHome_openbsd_arm64.tarr
   Unter BSD oder Linux geht das natürlich auch in einem Schritt.

4. Ersetzen der alten ausführbaren AdGuardHome durch die neue Version:
   # cp AdGuardHome /usr/opt/AdGuardHome
   Ich kopiere auch jedesmal die neuen Dateien CHANGELOG.md und README.md ins AdGuardHome-Verzeichnis.

5. AdGuardHome neu starten:
   Entweder über # rcctl start adguardhome oder direkt mit der neuen Datei:
   # ./AdGuardHome -s start.

Und schon ist das manuelle Update erledigt und AdGuardHome schützt meine Netzwerke jetzt mit v0.107.079

Unter Linux und MACOS klappt das Update auch perfekt über die Web-Oberfläche. Aber die wenigen Schritte, die (noch) unter OpenBSD notwendig sind, die mache ich gerne alle paar Monate.

Die BananaPi M5 eignen sich tatsächlich ganz hervorragend für den Job mit AdGuardHome. Das machen die quasi nebenbei, so dass daneben sogar noch andere Serverjobs mit erledigt werden. So läuft noch der httpd-Server und liefert Webseiten und Dokumentationen fürs lokale Netz.

Dazu gab es die M5 vor ein paar Jahren, also in den "guten" Zeiten vor Ukraine, Gaza oder Strasse von Hormus zu unglaublich günstigen Preisen unter 50 €. Hab mir damals glücklicherweise einige davon zugelegt.

Fernzugriff auf Xorg via ssh

Auf Rechner unter Xorg ist der Fernzugriff mittels ssh möglich. Dazu muss lediglich in der /etc/ssh/sshd_config ein Parameter geändert werden, und zwar dieser:

X11Forwarding yes

Per Default ist der auf "no" gesetzt. Nach der Änderung muss der Service sshd neu gestartet werden.

Ab sofort kann jetzt aus einem X-Terminal heraus auf diesen Rechner zugegriffen werden:

ssh -X Benutzername@Rechnername

Nun können Programme auf dem Gastrechner ausgeführt werden.

mkdocs unter OpenBSD

Bisher habe ich meine Blogs unter Hugo und Pelican geschrieben und bin mit beiden statischen Generatoren absolut zufrieden. Dennoch schaue ich mich ab und zu nach Alternativen um und dabei bin ich auf mkdocs gestossen. Erschien mir interessant zu sein, auch weil es für reine Dokumenation gut einsetzbar ist.

Das mkdocs Framework ist in Python geschrieben, was mir schon mal sehr sympathisch ist. Bislang hab ich es auf mehreren Betriebssystem installiert: OpenBSD, NetBSD, DragonFly BSD und MidnightBSD. Läuft auf all diesen Platformen einwandfrei,

Im Folgenden beschreibe ich in aller Kürze die einzelnen Schritte für die Installation von mkdocs:

Zuerst als root Python und py-pip installieren. Ich habe Python3.12 dafür genommen.
# pkg_add python3.12 py3-pip

Dann ein Projekt-Verzeichnis erstellt und dorthin gewechselt:
mkdir ~/work/projekt1
cd ~/work/projekt1

In diesem neuen Verzeichnis wird eine virtuelle Umgebung in einem Verzeichnis namens venv eingerichtet. Der Name des Verzeichnisses ist natürlich frei wählbar:
python3 -m venv venv

Nun kann diese virtuelle Umgebung aktiviert werden:
source venv/bin/activate

Ab jetzt zeigt ein (venv) vor dem normalen Prompt an, dass die virtuelle Umgebung aktiv ist. Der Prompt könnte dann z.B. so aussehen:

(venv) $berni@raspi56 ~/work/projekt1 $_

Zum Schluss muss natürlich noch mkdocs und material installiert werden:

pip install --upgrade pip
pip install mkdocs mkdocs-material

Beachte, dass die Installation innerhalb der virtuellen Umgebung erfolgen muss. Klappt aber auch sonst nicht.

Jetzt kann mit der eigentlichen Arbeit am Blog oder der Dokumentatio begonnen werden.
mkdocs new projektname erstellt ein Skelett für ein neues Projekt. Bei mir war es meist so, dass ich vorhandene Pelican-Projekte übernommen habe und die Posts, Pages und Images ins mkdocs-Verzeichnis kopiert habe. Anschliessen dann die mkdocs.yml angepasst.

...too big for the bo

Auf manchen älteren ASUS Mainboards der der Baureihe F2A85M... mit AMD A8 oder A10 Prozessoren hatte ich unter OpenBSD häufig die kryptische Fehlermeldung vbo resource seems to be too big for the bo. Dies trat auf beim Starten von xorg und auch danach beim Aufruf verschiedener Programme.

Spürbare Effekte hatten diese Meldungen nicht, aber sie müllten auch gern ganze Bildschirme voll. Irgendwann hatte ich die Nase voll und begann, die Ursache zu suchen - mit Hilfe der KI. Unsere Zusammenarbeit war dann letztendlich erfolgreich und ich konnte die Meldungen durch eine Konfigurationsdatei unter /etc/X11/xorg.conf.d abstellen.

Der Dateiname ist quasi beliebig, beispielsweise kann er 00-radeon-to-big.conf lauten. Wichtig ist der Inhalt und der sieht bei mir so aus:

    Identifier "Card0"
        Driver     "radeon"
        Option     "AccelMethod" "EXA"
        Option     "ColorTiling" "on"
        Option     "ColorTiling2D" "on"
    EndSection

Und seitdem ist Ruhe. Aber Achtung: Für diese Fehlermeldung kommen auch andere Ursachen in Frage, aber bei der alten Radeon-Grafik hats geholfen.

OpenBSD und RaspberryPI 5 GPIO uart

Es gibt leider Dinge, die ich mir ganz schlecht merken kann. Dazu gehört auch das Wissen um die Funktionen der GPIO Pins. Nur aus diesem Grund lege ich hier ein Foto der GPIO ab. Wenn ich mir's oft genug anschaue, weiss ich irgendwann auswendig, welche Pins für die uarts sind.

Schönes Fotos mit allen GPIO Pins.

Und noch eine Hilfe: Die Bezeichnung und farbliche Zuordnung der drei Leitungen TXD, RXD und GND des Adapters Seriell-USB.

Und so muss ich adaptieren, wenn ich ich den internen kleinen Stecker für den Debug uart des RaspberryPi 5 anschliessen will. Brauch ich aber nur, wenn nicht der spezielle Probe uart benutzt wird, sondern einer meiner Standard-Adapter.

U-Boot Gefrickel

Das U-Boot, also der Bootloader für den RaspBerryPi 5 mit OpenBSD, ist ja eine feine Sache und funktioniert auch. Allerdings muss für den Einsatz von OpenBSD ein U-Boot-Parameter geändert werden, was nur mit einer seriellen Verbindung zwischen dem RaspberryPi und einem zweiten Rechner möglich ist.

Wenn ohnehin gerade frisch installiert wird, ist das natürlich kein Problem: Der Raspi ist dann ohnehin geöffnet und der Stecker für den seriellen Anschluss einigermassen zugänglich.

Ich habe bisher 3 Raspi 5 auf diese Art und Weise installiert, kein Problem. Trotzdem habe ich überlegt, wie ich die serielle Verbindung umgehen kann. Ich habs tatsächlich hinbekommen, aber es war ein ziemliches Gefrickel - allerdings Software-Gefrickel. Das Hardware-Gefrickel konnte ich damit umgehen.

Was habe ich gemacht? Hier im Stenogram-Stil die Schritte:

• Mit dd if=/dev/sd1c of=obsd-rpi5.img bs=1m die SD-Karte eines laufenden OpenBSD in eine Datei geschrieben.

• Mit dd if=obsd-rpi5.img of=/dev/sd2c bs=1m das Image auf eine neue SD-Karte geschrieben.

• Damit habe ich jetzt eine bootfähige SD-Karte mit einem bereits modifizierten U-Boot. Die entsprechende Datei auf der Karte ist die uboot.env.

• Die SD-Karte wurde nun an einem anderen Rechner gemountet, idealerweise einem mit OpenBSD. Dort gibt es unter /etc eine Datei boot.conf. Die habe ich erstellt und dort eingetragen, dass ins HDMI, also in einen Bildschirm gebootet wird. Die Datei enthält bis jetzt nur die Zeile set tty fb0. Dies wird jetzt erweitert durch boot bsd.rd, natürlich in einer neuen Zeile.

• Nun kommt die neue SD-Karte in den Slot des RaspberryPi 5 und wird gebootet. Der Rechner startet, das U-Boot lädt OpenBSD, das geht sofort auf den Bildschirm und landet dann im Installations-Menü von OpenBSD. Je nach Bedarf kann jetzt ein Update oder eine Neuinstallation gestartet werden. Ich nutze die SD-Karte fast immer nur als Root-Partition und installiere den Rest des Systems auf einer NVME, eine der grössten Errungenschaften des RPI5.

• Wichtig! Nach abgeschlossener Installaion nicht sofort neu Booten, sondern eine Shell aurfufen. Das neu installierte System ist noch unter /mnt gemountet, also ins Verzeichnis /mnt/etc wechseln. Jetzt muss der Eintrag boot bsd.rd aus der boot.conf entfernt werden. Am einfachsten durch Überschreiben mit echo "set tty fb0" > boot.conf

• Nun mit exit zurück ins Installations-Menü und von dort aus neu gebootet. Der Rechner wird jetzt mit dem neuen OpenBSD starten.

• Die Geschichte ist aber damit noch nicht fertig. Das System hat jetzt natürlich alle Einstellungen des Muttersystems, beispielsweise auch dessen MAC-Adresse, den hostname und was sonst noch individuell konfiguriert wurde. Das muss alles angepasst werden, eventuell brauchts auch eine neue MAC-Adresse. Das ist aber alles nicht wirklich schwierig, macht jedoch ein wenig Arbeit.

Erspart habe ich mir aber eventuell das Ausbauen der Raspi-Platine aus dem Gehäuse, vielleicht die Anschaffung eines debug uart Kabels, den Aus- und Wiedereinbau der NVME-Platine und und und. Die Zugänglichkeit des debug uart ist beim Raspi leider nicht sehr gut gelöst.

locales unter DragonflyBSD

Ja, mit locales habe ich unter fast allen BSD so meine Probleme. Ganz schlimm war es unter DragonflyBSD 6.4.2, wo ich mir nur mit fiesen workarounds helfen konnte.

Das geht sicher eleganter, aber derzeit sieht meine Lösung so aus:

1) In der /etc/login.conf habe ich die Sektion default:\ um das hier erweitert:

:charset=UTF-8:\
:lang=de_DE.UTF-8:

2) In der ~/.profile der User wird dies hier zusätzlich eingetragen:

export LANG=de_DE.UTF-8
export MM_CHARSET=UTF-8
kbdmap -l de
export LANG=de_DE.ISO8859-15

Der UTF-8 Eintrag in der .profile (oder .cshrc) ist eigentlich ummötig, weil das ja bereits in der /etc/login.conf steht. Also nur zur Sicherheit, schaden kanns nicht.

Das Hauptproblem war, dass bei der Installation von DragonflyBSD zwar mittels kbdmap eine korrekte keymap in der /etc/rc.conf eingetragen wurde, die aber beim Einloggen offensichtlich nicht berücksichtigt wurde.

Wenn jetzt kbdmap -l de aufgerufen wurde, erschien das Auswahlmenü für die keymap - sehr lästig und unzumutbar. Wurde aber LANG auf Unicode gesetzt (also LANG=de_DE.UTF-8 ), erschien das Auswahlfenster nicht und die keymap wurde ordnungsgemäß gesetzt. Allerdings gabs mit UTF-8 die Umlaute nur bei jedem zweiten Tastendruck. Das wurde mit dem ISO8859-15 Eintrag behoben, Alternativ reicht auch ein Aufruf von set -o vi in der .profile.

Irgendwie schräg, und irgendwann finde ich höchstwahrscheinlich eine bessere Lösung. Aber erstmal habe ich jetzt funktionierende locales. Es gibt also alle Umlaute und Sonderzeichen der deutschen Tastatur.

NetBSD: gop Einstellung in /boot.cfg

Unter NetBSD habe ich es ein paar mal erlebt, dass nach der Installation des Betriebssystems die Grafik sowohl auf der Console als auch unter Xorg sehr schlecht war: Auf der Console waren die Schriftzeichen viel zu gross und unter Xorg war die Auflösung miserabel und weit unterhalb von Full HD, also 1920x1080.

Meine Lösung war dann immer, die gop-Einstellung in der /boot.cfg zu ändern. Der Parameter gop ändert dabei Einstellungen im Graphics Output Protocol (GOP).

Um den richtigen Wert für gop zu ermitteln, wird NetBSD gebootet und dabei im Bootmenü die Auswahl Drop to boot prompt gewählt. Am Boot Prompt dann zunächst die möglichen Parameter für gop abfragen: gop list zeigt nun die Möglichkeiten an. Für Full HD war es bei mir zuletzt der Eintrag 6, der 1920x1080 anbot. Das kann aber auch eine andere Zahl sein, abhängig von der verbauten Grafikkarte.

Mit gop set 6 wird dieser Parameter übergeben und dann mit boot frisch gebootet. Jetzt kann im realen System überprüft werden, ob die Einstellungen auf der Console und unter Xorg OK sind.

Um diese Einstellung dauerhaft zu machen, wird dann die Datei /boot.cfg geändert. Dazu muss ein Menü-Eintrag in /boot.cfg entweder geändert oder ein neuer Menüpunkt erstellt werden. Ich habe den Standard-Eintrag angepasst, sodass NetBSD einfach durchstarten kann und nicht jedesmal der neue Menüpunkt explizit eingegeben werden muss. Meine /boot.cfg sieht dann so aus:

menu=Boot normally:gop 6;rndseed /var/db/entropy-file;boot
menu=Boot single user:rndseed /var/db/entropy-file;boot -s
menu=Drop to boot prompt:prompt
default=1
timeout=5
clear=1

Wie unschwer zu erkennen ist, hat jetzt der erste Eintrag (Boot normally) den Eintrag gop 6 dazu bekommen. Jetzt hat das System überall eine vernünftige Auflösung.

Streifen im kitty Terminal

Irgendwann und eigentlich unerwartet geschah es unter NetBSD, dass das Terminalprogramm Kitty über die gesamte Fläche Querstreifen hatte. Diese gingen mittig durch die Buchstaben und Zahlen im Terminal. Das trat auf unter NetBSD 10.1 und auch 11.0-Beta und das sowohl auf amd64 als auch auf arm64-Rechnern.

Es gab viele Hinweise im Netz, die ich durch probiert habe, aber nichts davon konnte die Streifen beseitigen. Das ganze sah dann so aus:

Kitty mit Streifen unter NetBSD:

Erst mit Hilfe der KI von DuckDuckGo konnte ich das Problem beseitigen. Die Lösung war dann ein Eintrag in der ~/.config/kitty/kitty.conf:

modify_font strikethrough_position 10px

An der Wert von 10px musste ich mich, angefangen mit 1, langsam herantasten. Damit ist Kitty, mittlerweile mein Lieblings-Terminal, wieder streifenfrei. Schön!

U-Boot startet OpenBSD nicht

Nachdem es gelungen war, OpenBSD auf dem RaspberryPi 5 zu installieren, trat ein weiteres Problem auf: Das U-Boot.

Während ich bis zum RaspberryPi 4 OpenBSD über die EDK-Firmware booten konnte, funktioniert das beim RaspberryPi 5 nicht damit. Statt dessen werden die Systeme mit dem U-Boot gestartet, einem universellen Bootloader für Arm64-Systeme. Das U-Boot richtet beim Start die Hardware-Komponenten ein und startet danach das Betriebssystem.

Nun trat bei der Kombination Raspi5/OpenBSD ein merkwürdiges Verhalten auf: Die Installation wurde über die serielle Schnittstelle durchgeführt, anschliessend und für den Alltagsbetrieb hat die Datei /etc/boot.conf mit dem Eintrag set tty fb0 die Ausgabe auf HDMI, also den Monitor, gesetzt.

Und nun passierte folgendes: War der Raspberry 5 noch seriell mit dem Installationsrechner verbunden und war diese Verbindung noch aktiv, klappte alles wie am Schnürchen: Das U-Boot startete den Raspi, zeigt dabei kurz sein Logo oben rechts auf dem Monitor und startete dann wie gewünscht das System, also OpenBSD.

Bestand diese serielle Verbindung aber nicht mehr, startete zwar das U-Boot, aber das Logo blieb dauerhauft sichtbar und OpenBSD wurde nicht geladen. Dann musste ich die serielle Verbindung wieder herstellen und konnte dann im Terminal-Programm, z.B. cu, sehen, das es nur bis zum U-Boot-Prompt gelaufen war. Jetzt musste boot eingetippt werden, und dann erst wurde OpenBSD gestartet. Das war natürlich Mist.

Die Lösung kam, nicht unerwartet, über die OpenBSD-Arm-Mailing-Liste. Im U-Boot muss die Umgebungsvariable bootdelay auf -2 gesetzt werden. Das erfolgt am U-Boot-Prompt über die serielle Verbindung mit zwei Befehlen:

setenv bootdelay -2

saveenv

Also die Variablesetzen und dann abspeichern. Damit läuft (bisher) jeder Gerätestart sauber bis zum OpenBSD-Prompt durch. Das Leben kann so einfach sein!

Ach ja, eines noch: Beim Raspberry 5 muss die Debug-Schnittstelle benutzt werden, mit der GPIO-Schnittstelle gibts keine Verbindung. Muss man auch wissen.