So verwandelst du einen GL.iNet Flint 3 mit OpenWrt in QNetd f?r einen Proxmox-Cluster

1. Die verwendete Umgebung

In meiner Installation:

Código

Router:
GL.iNet Flint 3 / GL-BE9300
IP: 192.168.1.1
OpenWrt 23.05-SNAPSHOT
ARM64-Architektur

Cluster:
Name: hectormox

Knoten 1:
miniproxmox
192.168.1.6

Knoten 2:
zimaproxmox
192.168.1.7

Die minimale Debian-Installation befand sich unter:

/opt/debian-qnetd

QNetd lauscht auf dem Standardport:

TCP 5403

2. Per SSH mit dem Flint 3 verbinden

Unter Windows k?nnen wir direkt den in PowerShell enthaltenen SSH-Client verwenden:

ssh root@192.168.1.1

Wir geben das Administrationspasswort des Routers ein.

Nach der Anmeldung sehen wir etwas ?hnliches wie:

Código

BusyBox
OpenWrt
root@GL-BE9300:~#

Bevor wir irgendetwas installieren, lohnt es sich herauszufinden, was tats?chlich vorhanden ist.

3. System, Architektur, Pakete und verf?gbaren Speicherplatz pr?fen

Wir f?hren Folgendes aus:

bash

cat /etc/os-release
cat /etc/openwrt_release

uname -a
uname -m

command -v opkg
command -v apk

opkg print-architecture

df -h

Auf meinem Flint erhielt ich ein System mit:

OpenWrt 23.05-SNAPSHOT

aarch64

und opkg als Paketmanager.

Ich habe auch gepr?ft, welche Werkzeuge verf?gbar waren:

bash

command -v ar
command -v tar
command -v gzip
command -v xz
command -v wget
command -v curl
command -v mount
command -v chroot

Und insbesondere, ob OpenWrt Corosync bereits anbot:

bash

opkg update
opkg list | grep -Ei 'corosync|qnetd|qdevice|libnss|libqb'

In meiner Firmware war corosync-qnetd nicht vorhanden.

Daher konnten wir nicht einfach Folgendes ausf?hren:

opkg install corosync-qnetd

wie wir es mit einem nativen OpenWrt-Paket tun w?rden.

4. Warum eine minimale Debian-Umgebung innerhalb von OpenWrt verwenden

Anstatt Corosync und alle zugeh?rigen Abh?ngigkeiten direkt f?r OpenWrt zu kompilieren, entschied ich mich f?r eine deutlich einfachere L?sung:

eine minimale Debian-ARM64-Umgebung in einem Verzeichnis erstellen und QNetd ?ber chroot ausf?hren.

OpenWrt bleibt das Betriebssystem des Routers. Wir installieren keinen anderen Kernel, virtualisieren nichts und ersetzen die Firmware nicht.

Die Struktur sieht einfach so aus:

Código

OpenWrt
└── /opt/debian-qnetd
    └── Debian 12 ARM64
        └── corosync-qnetd

Der Flint funktioniert also weiterhin als OpenWrt-Router, verf?gt aber ?ber eine kleine Debian-Umgebung, aus der wir Software ausf?hren k?nnen, die in seinen Repositories nicht vorhanden ist.

5. debootstrap auf dem Flint installieren

Zuerst aktualisieren wir die Paketindizes:

opkg update

Wir installieren debootstrap:

opkg install debootstrap

Wir pr?fen, ob es verf?gbar ist:

bash

command -v debootstrap
debootstrap --version

Und pr?fen den verf?gbaren Speicherplatz:

df -h /overlay

Bei mir waren mehrere Gigabyte frei, genug f?r eine minimale Debian-Installation.

6. Problem mit GPG und Debian Bookworm

Hier trat eines der ersten Probleme auf, die spezifisch f?r meine OpenWrt-Version waren.

debootstrap muss die Signaturen der Debian-Repositories ?berpr?fen, aber das auf dem Router zun?chst verf?gbare gpgv war f?r einige von Bookworm verwendete Signaturen zu alt.

Die L?sung bestand darin, Folgendes zu installieren:

opkg install gpgv2

Wir k?nnen die Installation damit ?berpr?fen:

gpgv2 --version

Au?erdem ben?tigen wir die offiziellen Debian-Schl?ssel.

Wir bereiten ein tempor?res Verzeichnis vor:

bash

BASE="/tmp/qnetd-bootstrap"

mkdir -p "$BASE"
mkdir -p "$BASE/bin"

Wir laden das Paket debian-archive-keyring f?r Debian Bookworm herunter.

Hier sollte man pr?fen, welche Paketversion zum Zeitpunkt der Verwendung dieser Anleitung aktuell ist, anstatt dauerhaft eine bestimmte URL zu ?bernehmen.

Nach dem Herunterladen:

DEB="$BASE/debian-archive-keyring.deb"

Wir entpacken den Inhalt:

bash

ar p "$DEB" data.tar.xz |
    xz -dc |
    tar -xf - -C "$BASE"

Der Schl?ssel steht nun hier zur Verf?gung:

bash

KEY="$BASE/usr/share/keyrings/debian-archive-keyring.gpg"
ls -l "$KEY"

Damit debootstrap gpgv2 verwendet, legen wir vor?bergehend einen kleinen Override an:

ln -sf /usr/bin/gpgv2 "$BASE/bin/gpgv"

Das wirkt sich nur auf den PATH aus, den wir beim Ausf?hren von debootstrap verwenden.

7. Debian 12 ARM64 minbase erstellen

Wir legen fest, wo die Installation erfolgen soll:

TARGET="/opt/debian-qnetd"

Wir f?hren Folgendes aus:

bash

PATH="$BASE/bin:$PATH" \
debootstrap \
    --arch=arm64 \
    --variant=minbase \
    --keyring="$KEY" \
    bookworm \
    "$TARGET" \
    https://deb.debian.org/debian

Damit wird eine minimale Debian-12-Installation heruntergeladen und hier eingerichtet:

/opt/debian-qnetd

Wir k?nnen den Inhalt pr?fen:

ls -la /opt/debian-qnetd

Und die Umgebung manuell betreten:

chroot /opt/debian-qnetd /bin/bash

Um zu OpenWrt zur?ckzukehren:

exit

8. Debian aktualisieren und QNetd installieren

Direkt von OpenWrt aus k?nnen wir Befehle innerhalb des chroot ausf?hren:

chroot "$TARGET" /usr/bin/apt-get update

Vor der Installation pr?fen wir, ob das Paket verf?gbar ist:

bash

chroot "$TARGET" \
    /usr/bin/apt-cache policy corosync-qnetd

Bei mir bot Debian Folgendes an:

corosync-qnetd 3.0.3-1

Bei der ersten Installation fehlten einige Abh?ngigkeiten der minbase-Umgebung.

Zuerst reparierte ich die Paketdatenbank mit:

bash

chroot "$TARGET" \
    /usr/bin/apt-get --no-remove -y --fix-broken install

Danach installierte ich:

bash

chroot "$TARGET" \
    /usr/bin/apt-get install -y \
    --no-install-recommends \
    corosync-qnetd \
    libnss3-tools

Zu den Abh?ngigkeiten, die Debian schlie?lich installierte, geh?rten NSS-Bibliotheken, Perl, netbase und weitere ben?tigte Pakete.

9. `/proc` und `/dev/pts` w?hrend der Installation

W?hrend der Installation gab es einige Warnungen zu /proc und /dev/pts.

Ich band vor?bergehend Folgendes ein:

bash

mount -o bind \
    /proc \
    /opt/debian-qnetd/proc

Und:

bash

mount -o bind \
    /dev/pts \
    /opt/debian-qnetd/dev/pts

Das half uns bei der Vorbereitung von Debian.

Sp?ter stellten wir fest, dass QNetd diese Bind-Mounts im normalen Betrieb nicht ben?tigt. Sie geh?ren daher nicht zum endg?ltigen Service.

10. QNetd-Zertifikate initialisieren

QNetd verwendet eine NSS-Datenbank zur Verwaltung seiner Zertifikate.

In unserer Debian-Umgebung steht daf?r folgendes Werkzeug zur Verf?gung:

corosync-qnetd-certutil

Wir initialisieren sie von OpenWrt aus:

bash

chroot /opt/debian-qnetd \
    /usr/bin/corosync-qnetd-certutil \
    -i

Die NSS-Datenbank befindet sich, von OpenWrt aus gesehen, hier:

/opt/debian-qnetd/etc/corosync/qnetd/nssdb

Wir k?nnen sie folgenderma?en ?berpr?fen:

bash

ls -lah \
    /opt/debian-qnetd/etc/corosync/qnetd/nssdb

Innerhalb des chroot lautet derselbe Pfad:

/etc/corosync/qnetd/nssdb

Die ?ffentliche CA befindet sich hier:

/opt/debian-qnetd/etc/corosync/qnetd/nssdb/qnetd-cacert.crt

11. Den Benutzer `coroqnetd`

Das Debian-Paket erstellt einen eigenen Benutzer f?r die Ausf?hrung von QNetd.

Wir pr?fen seine Kennungen:

chroot /opt/debian-qnetd id coroqnetd

In meiner Installation erhielt ich:

UID 100

GID 101

Das ist wichtig, weil ich QNetd sp?ter mit folgender Option ausf?hre:

--userspec=100:101

Diese Zahlen d?rfen nicht ungepr?ft ?bernommen werden.

Jede Installation muss Folgendes ausf?hren:

chroot /opt/debian-qnetd id coroqnetd

und die ermittelten Werte verwenden.

Au?erdem pr?fen wir die Berechtigungen der NSS-Datenbank:

bash

DB="/opt/debian-qnetd/etc/corosync/qnetd/nssdb"
ls -ln "$DB"

Bei mir musste ich Folgendes anpassen:

bash

chgrp 101 \
    "$DB/pwdfile.txt" \
    "$DB/pkcs11.txt"

chmod 640 \
    "$DB/pwdfile.txt" \
    "$DB/pkcs11.txt"

Auch in meiner Installation war 101 die konkrete GID.

12. QNetd manuell testen

Bevor wir daraus einen Service machen, sollten wir pr?fen, ob der Daemon tats?chlich startet.

Ich testete Folgendes:

bash

timeout -s TERM 10 \
    chroot --userspec=100:101 \
    /opt/debian-qnetd \
    /usr/bin/corosync-qnetd \
    -f \
    -4 \
    -l 192.168.1.1 \
    -p 5403 \
    -s req

Die verwendeten Parameter bedeuten:

-f: im Vordergrund ausf?hren.
-4: IPv4 verwenden.
-l 192.168.1.1: Adresse, auf der QNetd lauscht.
-p 5403: Port.
-s req: TLS in der von uns verwendeten Version erzwingen.

Bevor wir die Optionen ?bernehmen, sollten wir die Hilfe der installierten Version pr?fen:

bash

chroot /opt/debian-qnetd \
    /usr/bin/corosync-qnetd \
    -h

13. Das LD_PRELOAD-Problem von OpenWrt

Beim Ausf?hren von Debian-Programmen unter OpenWrt erschienen Warnungen zu einer Firmware-Variablen namens LD_PRELOAD.

Damit der chroot-Prozess keine OpenWrt-eigenen Variablen ?bernimmt, f?hrte ich ihn schlie?lich mit einer sauberen Umgebung aus:

bash

/usr/bin/env -i \
    PATH=/usr/sbin:/usr/bin:/sbin:/bin \
    ...

Dieses Detail wurde Teil des endg?ltigen Service.

14. Den QNetd-Service unter OpenWrt einrichten

Hier liegt einer der wichtigsten Unterschiede zu einer normalen Debian-Installation.

Unter Debian w?rden wir systemd verwenden.

Unter OpenWrt verwenden wir procd und Skripte unter:

/etc/init.d/

Wir erstellen die Datei:

bash

cat > /etc/init.d/qnetd-debian <<'EOF'
#!/bin/sh /etc/rc.common

USE_PROCD=1
START=98
STOP=10

start_service() {
    procd_open_instance

    procd_set_param command \
        /usr/bin/env -i \
        PATH=/usr/sbin:/usr/bin:/sbin:/bin \
        /usr/sbin/chroot --userspec=100:101 \
        /opt/debian-qnetd \
        /usr/bin/corosync-qnetd \
        -f -4 -l 192.168.1.1 -p 5403 -s req

    procd_set_param respawn 3600 5 5
    procd_set_param stdout 1
    procd_set_param stderr 1

    procd_close_instance
}
EOF

Wir setzen die Berechtigungen:

chmod 755 /etc/init.d/qnetd-debian

Wir aktivieren den automatischen Start:

/etc/init.d/qnetd-debian enable

Wir k?nnen die angelegten Links pr?fen:

ls -l /etc/rc.d/*qnetd*

Auf meinem Flint wurden folgende Eintr?ge angelegt:

/etc/rc.d/S98qnetd-debian

/etc/rc.d/K10qnetd-debian

Wir starten den Service:

/etc/init.d/qnetd-debian start

15. Pr?fen, ob QNetd l?uft

Zuerst suchen wir den Prozess:

pidof corosync-qnetd

Anschlie?end pr?fen wir den Port:

netstat -lntp 2>/dev/null | grep 5403

Wir sollten Folgendes sehen:

192.168.1.1:5403 LISTEN

Wir k?nnen auch den vollst?ndigen Prozess pr?fen:

ps w | grep '[c]orosync-qnetd'

Und den Status direkt bei procd:

bash

ubus call service list \
    '{"name":"qnetd-debian"}'

Ein korrekter Status enth?lt:

"running": true

Bei mir war au?erdem Folgendes zu sehen:

Código

/usr/bin/corosync-qnetd
-f
-4
-l 192.168.1.1
-p 5403
-s req

16. Den Respawn pr?fen

Der Service enth?lt folgende Einstellung:

procd_set_param respawn 3600 5 5

Dadurch kann procd QNetd erneut starten, wenn der Prozess unerwartet endet.

W?hrend der Tests beendeten wir den Prozess manuell und pr?ften, ob er mit einer anderen PID erneut gestartet wurde und wieder auf diesem Port lauschte:

192.168.1.1:5403

17. Proxmox vorbereiten

Jetzt wechseln wir zum ersten Cluster-Knoten:

ssh root@192.168.1.6

Wir pr?fen den aktuellen Status:

pvecm status

Und:

corosync-qdevice-tool -s

Mein Cluster hei?t:

hectormox

Zuvor lief ein anderer QNetd auf:

192.168.1.5:5403

Der neue wird hier laufen:

192.168.1.1:5403

18. Vor dem ?ndern von QDevice ein Backup erstellen

Bevor ich die Zertifikate ?nderte, sicherte ich folgende Pfade:

/etc/corosync/qdevice

/etc/pve/corosync.conf

Zum Beispiel:

bash

BACKUP="/root/qdevice-backup-$(hostname)-$(date +%Y%m%d-%H%M%S).tar.gz"

tar -czf "$BACKUP" \
    -C / \
    etc/corosync/qdevice \
    etc/pve/corosync.conf

sha256sum "$BACKUP"

ls -lh "$BACKUP"

Ich empfehle nicht, ohne dieses Backup fortzufahren.

19. Eine neue NSS-Datenbank auf Proxmox erstellen

Auf miniproxmox:

bash

DIR="/root/qnetd-migration"
DB="$DIR/nssdb-new"
PASS="$DIR/pwdfile-new.txt"

mkdir -p "$DIR"
mkdir -m 700 "$DB"

: > "$PASS"
chmod 600 "$PASS"

Inicializamos NSS:

certutil -N \
    -d "sql:$DB" \
    -f "$PASS"

20. Die CA vom Flint nach Proxmox kopieren

Von miniproxmox:

bash

scp \
    root@192.168.1.1:/opt/debian-qnetd/etc/corosync/qnetd/nssdb/qnetd-cacert.crt \
    /root/qnetd-migration/qnetd-cacert.crt

Wir importieren die CA:

bash

certutil -A \
    -d "sql:$DB" \
    -n "QNet CA" \
    -t "CT,c,c" \
    -i "$DIR/qnetd-cacert.crt" \
    -f "$PASS"

Wir pr?fen das Ergebnis:

bash

certutil -L \
    -d "sql:$DB" \
    -f "$PASS"

Wir sollten Folgendes sehen:

QNet CA CT,c,c

21. Den CSR des Clusters erstellen

Wir erzeugen etwas Entropie:

bash

dd if=/dev/urandom \
    of="$DIR/noise-new.txt" \
    bs=1024 \
    count=1 \
    status=none

Wir erstellen den CSR:

bash

CSR="$DIR/qdevice-net-node.crq"
certutil -R \
    -d "sql:$DB" \
    -f "$PASS" \
    -z "$DIR/noise-new.txt" \
    -s "CN=hectormox" \
    -g 3072 \
    -o "$CSR"

Folgendes muss ersetzt werden:

hectormox

durch den tats?chlichen Clusternamen.

Wir k?nnen ihn folgenderma?en pr?fen:

pvecm status

22. Den CSR an den Flint senden

Von Proxmox aus:

bash

scp \
    "$CSR" \
    root@192.168.1.1:/opt/debian-qnetd/tmp/hectormox.crq

Wir verbinden uns erneut mit dem Flint:

ssh root@192.168.1.1

Und signieren ihn:

bash

chroot /opt/debian-qnetd \
    /usr/bin/corosync-qnetd-certutil \
    -s \
    -c /tmp/hectormox.crq \
    -n hectormox

Das signierte Zertifikat befindet sich hier:

/opt/debian-qnetd/etc/corosync/qnetd/nssdb/cluster-hectormox.crt

23. Das signierte Zertifikat abrufen

Von miniproxmox:

bash

scp \
    root@192.168.1.1:/opt/debian-qnetd/etc/corosync/qnetd/nssdb/cluster-hectormox.crt \
    /root/qnetd-migration/cluster-hectormox.crt

Wir k?nnen es in PEM umwandeln:

bash

cd /root/qnetd-migration

openssl x509 \
    -inform DER \
    -in cluster-hectormox.crt \
    -out cluster-hectormox.pem

Und ?berpr?fen:

bash

openssl verify \
    -CAfile qnetd-cacert.crt \
    cluster-hectormox.pem

Das korrekte Ergebnis lautet:

OK

24. Das Cluster-Zertifikat importieren

Wir f?gen das signierte Zertifikat zu NSS hinzu:

bash

certutil -A \
    -d "sql:$DB" \
    -n "Cluster Cert" \
    -t "u,u,u" \
    -i "$DIR/cluster-hectormox.crt" \
    -f "$PASS"

Wir pr?fen das Ergebnis:

bash

certutil -L \
    -d "sql:$DB" \
    -f "$PASS"

Nun sollten folgende Eintr?ge erscheinen:

QNet CA CT,c,c

Cluster Cert u,u,u

25. Zertifikat und privaten Schl?ssel nach PKCS#12 exportieren

Wir erzeugen die Datei:

bash

pk12util \
    -o "$DIR/qdevice-net-node.p12" \
    -d "sql:$DB" \
    -k "$PASS" \
    -W "" \
    -n "Cluster Cert"

Erwartetes Ergebnis:

PKCS12 EXPORT SUCCESSFUL

Diese Datei enth?lt einen privaten Schl?ssel. Sie darf nicht ver?ffentlicht oder weitergegeben werden.

26. Den zweiten Proxmox-Knoten vorbereiten

Wir kopieren die Datei auf den zweiten Knoten:

bash

scp \
    /root/qnetd-migration/qnetd-cacert.crt \
    root@192.168.1.7:/root/qnetd-migration/

Und:

bash

scp \
    /root/qnetd-migration/qdevice-net-node.p12 \
    root@192.168.1.7:/root/qnetd-migration/

Auf zimaproxmox:

bash

DIR="/root/qnetd-migration"
DB="$DIR/nssdb-new"
PASS="$DIR/pwdfile-new.txt"
CA="$DIR/qnetd-cacert.crt"
P12="$DIR/qdevice-net-node.p12"

mkdir -m 700 "$DB"

: > "$PASS"
chmod 600 "$PASS"

certutil -N \
    -d "sql:$DB" \
    -f "$PASS"

Wir importieren die CA:

bash

certutil -A \
    -d "sql:$DB" \
    -n "QNet CA" \
    -t "CT,c,c" \
    -i "$CA" \
    -f "$PASS"

Wir importieren PKCS#12:

bash

pk12util \
    -i "$P12" \
    -d "sql:$DB" \
    -k "$PASS" \
    -W ""

Das korrekte Ergebnis lautet:

PKCS12 IMPORT SUCCESSFUL

Und pr?fen:

bash

certutil -L \
    -d "sql:$DB" \
    -f "$PASS"

27. Eine endg?ltige NSS-Datenbank vorbereiten

Bevor ich die tats?chlich von QDevice verwendete Datenbank ?nderte, bereitete ich ein weiteres Verzeichnis vor:

/root/qnetd-migration/nssdb-ready

Auf jedem Knoten:

bash

DIR="/root/qnetd-migration"
READY="$DIR/nssdb-ready"

mkdir -m 700 "$READY"

cp -a \
    "$DIR/nssdb-new/." \
    "$READY/"

install -m 600 \
    "$DIR/pwdfile-new.txt" \
    "$READY/pwdfile.txt"

Wir pr?fen das Ergebnis:

bash

certutil -L \
    -d "sql:$READY" \
    -f "$READY/pwdfile.txt"

Und k?nnen die Identit?t ?berpr?fen:

bash

certutil -L \
    -d "sql:$READY" \
    -n "Cluster Cert" \
    -a |
openssl x509 \
    -noout \
    -subject \
    -issuer

Bei mir:

subject=CN=hectormox

issuer=CN=QNet CA

28. Die aktiven Zugangsdaten ersetzen

Diesen Schritt f?hrten wir Knoten f?r Knoten.

Wir stoppen ausschlie?lich QDevice:

systemctl stop corosync-qdevice

Corosync stoppen wir nicht.

Wir sichern die alte Datenbank:

bash

ACTIVE="/etc/corosync/qdevice/net/nssdb"
BACKUP="${ACTIVE}.pre-glinet-$(date +%Y%m%d-%H%M%S)"
mv "$ACTIVE" "$BACKUP"

Wir kopieren die neue Datenbank:

bash

cp -a \
    /root/qnetd-migration/nssdb-ready \
    "$ACTIVE"

Wir passen die Berechtigungen an:

bash

chown -R root:root "$ACTIVE"
chmod 700 "$ACTIVE"
chmod 600 "$ACTIVE"/*

Wir pr?fen das Ergebnis:

bash

certutil -L \
    -d "sql:$ACTIVE" \
    -f "$ACTIVE/pwdfile.txt"

Und starten QDevice:

systemctl start corosync-qdevice

Wir wiederholen denselben Vorgang auf dem anderen Knoten.

29. Die IP des alten QNetd ?ndern

In meinem Fall war QDevice bereits f?r einen anderen Server konfiguriert:

192.168.1.5

und sollte auf den Flint umgestellt werden:

192.168.1.1

Zuvor erstellte ich ein weiteres Backup:

bash

cp \
    /etc/pve/corosync.conf \
    "/root/corosync-pre-glinet-$(date +%Y%m%d-%H%M%S).conf"

Die ?nderung sah so aus:

- host: 192.168.1.5

+ host: 192.168.1.1

Au?erdem erh?hten wir:

- config_version: 3

+ config_version: 4

Der betreffende Abschnitt sah anschlie?end etwa so aus:

bash

quorum {
  device {
    model: net
    net {
      algorithm: ffsplit
      host: 192.168.1.1
      tls: on
    }
    votes: 1
  }
}

Beachte, dass config_version gegen?ber dem Wert der jeweiligen Installation erh?ht werden muss.

Die Werte 3 ? 4 d?rfen nicht w?rtlich ?bernommen werden.

30. Nur QDevice neu starten

Nach der ?nderung ?bernahm Corosync die neue Konfiguration, aber der QDevice-Prozess verwendete weiterhin die alte Adresse, bis wir ihn neu starteten.

Wir f?hren Folgendes aus:

systemctl restart corosync-qdevice

Wir pr?fen den Status:

corosync-qdevice-tool -s

Das korrekte Ergebnis war:

Cluster name: hectormox

QNetd host: 192.168.1.1:5403

Algorithm: Fifty-Fifty split

State: Connected

Wir starten QDevice auch auf dem zweiten Knoten neu.

31. Das Quorum pr?fen

Wir f?hren Folgendes aus:

pvecm status

In unserem Fall lautete das Endergebnis:

Expected votes: 3 Highest expected: 3 Total votes: 3 Quorum: 2 Quorate: Yes

Und in der Mitgliederliste:

0x00000001 1 A,V,NMW 192.168.1.6

0x00000002 1 A,V,NMW 192.168.1.7

0x00000000 1 Qdevice

Das bedeutet:

miniproxmox: 1 voto.
zimaproxmox: 1 voto.
QDevice/QNetd: 1 Stimme.

Insgesamt:

3 Stimmen

Das ben?tigte Quorum betr?gt weiterhin:

2

32. Ein vollst?ndiges Backup des Flint-QNetd erstellen

Nachdem alles eingerichtet war, erstellte ich ein vollst?ndiges Backup der Umgebung.

Wir legen Folgendes fest:

bash

SERVICE="/etc/init.d/qnetd-debian"
BACKUP="/overlay/qnetd-backup-completo-$(date +%Y%m%d-%H%M%S).tar.gz"

Wir stoppen QNetd kurzzeitig:

"$SERVICE" stop

Wir erstellen das Backup:

bash

tar -czf "$BACKUP" \
    -C / \
    --exclude=opt/debian-qnetd/proc \
    --exclude=opt/debian-qnetd/dev/pts \
    --exclude=opt/debian-qnetd/run \
    --exclude=opt/debian-qnetd/tmp \
    opt/debian-qnetd \
    etc/init.d/qnetd-debian \
    etc/rc.d/S98qnetd-debian \
    etc/rc.d/K10qnetd-debian

Anschlie?end starten wir den Service wieder:

"$SERVICE" start

Wir ?berpr?fen die Integrit?t:

bash

tar -tzf "$BACKUP" >/dev/null
sha256sum "$BACKUP"
ls -lh "$BACKUP"

Mein fertiges Backup war ungef?hr:

157 MB

33. Das Backup nach Windows herunterladen

In PowerShell:

bash

scp -O `
    root@192.168.1.1:/overlay/qnetd-backup-completo-XXXXXXXX.tar.gz `
    "$env:USERPROFILE\Downloads\"

Anschlie?end berechnen wir den Hash:

bash

Get-FileHash `
    "$env:USERPROFILE\Downloads\qnetd-backup-completo-XXXXXXXX.tar.gz" `
    -Algorithm SHA256

Der Wert muss exakt mit dem zuvor auf dem Flint ermittelten Wert ?bereinstimmen.

Das Backup enth?lt Zertifikate und private Schl?ssel und muss daher sicher aufbewahrt werden.

34. Das System nach einem Neustart des Flint testen

Ich wollte das Projekt nicht schon dann als abgeschlossen betrachten, wenn es nach einem manuellen Start funktionierte.

Ich startete den Flint 3 ?ber seine Weboberfl?che neu.

Sobald er wieder erreichbar war, meldete ich mich erneut an:

ssh root@192.168.1.1

Zuerst pr?fte ich, ob das Skript noch vorhanden war:

wc -l /etc/init.d/qnetd-debian

Danach:

pidof corosync-qnetd

Ich pr?fte den Port:

netstat -lntp 2>/dev/null | grep 5403

Y finalmente procd:

bash

ubus call service list \
    '{"name":"qnetd-debian"}'

Beim abschlie?enden Test erhielt ich:

23 /etc/init.d/qnetd-debian

eine g?ltige PID:

28139

den Port:

192.168.1.1:5403 LISTEN

und:

"running": true

Damit war nachgewiesen, dass QNetd nach dem Neustart des Routers automatisch gestartet war.

35. Pr?fen, ob Proxmox die Verbindung automatisch wiederherstellt

Auf miniproxmox:

corosync-qdevice-tool -s

Der Status wechselte automatisch zur?ck zu:

QNetd host: 192.168.1.1:5403 State: Connected

Und:

pvecm status

zeigte erneut Folgendes an:

Expected votes: 3

Total votes: 3

Quorum: 2

Quorate: Yes

Wenn wir den Flint neu starten, verlieren die Proxmox-Knoten vor?bergehend die Stimme von QDevice. Sobald QNetd wieder l?uft, verbinden sich die QDevice automatisch erneut.

36. Ein ungew?hnliches Problem, das auftrat

Bei einem der Tests geschah etwas Merkw?rdiges.

Der Service wurde als aktiviert angezeigt:

/etc/init.d/qnetd-debian enabled

aber QNetd lief nicht.

Wir pr?ften:

pidof corosync-qnetd

Es wurde keine PID zur?ckgegeben.

Auch lauschte nichts auf dem Port:

bash

netstat -lntp 2>/dev/null |
    grep 5403

Also ?berpr?ften wir das Skript:

wc -l /etc/init.d/qnetd-debian

Dabei stellten wir fest:

0 /etc/init.d/qnetd-debian

Die Datei war leer geworden.

Die folgenden Eintr?ge waren jedoch weiterhin vorhanden:

/etc/rc.d/S98qnetd-debian

/etc/rc.d/K10qnetd-debian

Deshalb konnte OpenWrt den Service als aktiviert anzeigen, obwohl tats?chlich nichts zum Ausf?hren vorhanden war.

Wir stellten das Skript wieder her und wiederholten den vollst?ndigen Neustarttest.

Danach startete der Service korrekt.

Die Schlussfolgerung ist wichtig:

Es reicht nicht, nur zu pr?fen, ob ein Service aktiviert ist.

Zus?tzlich sollte man Folgendes ?berpr?fen:

bash

pidof corosync-qnetd
netstat -lntp 2>/dev/null | grep 5403
ubus call service list \ '{"name":"qnetd-debian"}'

37. Schnelldiagnose, wenn QNetd nicht startet

Zuerst pr?fen wir, ob das Skript vorhanden und nicht leer ist:

bash

wc -l /etc/init.d/qnetd-debian
cat /etc/init.d/qnetd-debian

Danach:

/etc/init.d/qnetd-debian enabled

Wir suchen den Prozess:

pidof corosync-qnetd

Port:

bash

netstat -lntp 2>/dev/null |
    grep 5403

Status in procd:

bash

ubus call service list \
    '{"name":"qnetd-debian"}'

Und wenn wir QNetd au?erhalb von procd testen m?chten:

bash

timeout 5 /usr/bin/env -i \
    PATH=/usr/sbin:/usr/bin:/sbin:/bin \
    /usr/sbin/chroot --userspec=100:101 \
    /opt/debian-qnetd \
    /usr/bin/corosync-qnetd \
    -f -4 \
    -l 192.168.1.1 \
    -p 5403 \
    -s req

echo "EXIT=$?"

Wenn der Befehl Folgendes zur?ckgibt:

124

bedeutet das, dass der Daemon noch lief, als timeout ihn beendete.

In diesem Fall liegt das Problem wahrscheinlich beim procd-Service und nicht bei QNetd.

38. Schnelldiagnose von Proxmox aus

Zuerst pr?fen wir die Services:

bash

systemctl is-active corosync
systemctl is-active corosync-qdevice

Danach:

corosync-qdevice-tool -s

Richtig ist:

State: Connected

Und:

pvecm status

sollte Folgendes anzeigen:

Total votes: 3

Quorate: Yes

Wenn Folgendes erscheint:

Cannot initialize CMAP service

bedeutet das nicht zwangsl?ufig, dass QNetd fehlerhaft ist.

Pr?fen wir zuerst:

systemctl is-active corosync

W?hrend meiner Tests trat genau so ein Vorfall auf. Ursache war ein von QNetd unabh?ngiges Problem mit NFS-Mounts auf dem Proxmox-Host.

39. Werte, die an die eigene Installation angepasst werden m?ssen

Nicht alle Werte aus dieser Anleitung d?rfen unver?ndert ?bernommen werden.

Adresse des Flint

In meinem Fall:

192.168.1.1

Proxmox-Knoten

192.168.1.6

192.168.1.7

Clustername

hectormox

Pr?fe ihn mit:

pvecm status

Architektur

Mein Flint verwendet:

ARM64

Wir sollten sie jedoch pr?fen mit:

uname -m

UID und GID von `coroqnetd`

In meiner Installation:

100:101

Pr?fen mit:

bash

chroot /opt/debian-qnetd \
    id coroqnetd

Debian-Pfad

Ich habe Folgendes gew?hlt:

/opt/debian-qnetd

Das ist nicht zwingend erforderlich.

Debian-Version

In dieser Anleitung:

Debian 12 Bookworm

TLS

Meine Version verwendete:

-s req

Pr?fe es mit:

bash

chroot /opt/debian-qnetd \
    /usr/bin/corosync-qnetd \
    -h

`config_version`

?bernimm nicht einfach:

3 → 4

Der aktuelle Wert in unserer corosync.conf muss um eins erh?ht werden.

40. Das Endergebnis

Nach Abschluss aller Schritte l?uft der Flint 3 wie folgt:

Código

OpenWrt
??? Debian 12 ARM64 in chroot
    ??? corosync-qnetd

QNetd:

192.168.1.1:5403

TLS

procd

Respawn

automatischer Start

Und der Cluster:

Código

miniproxmox  → QDevice ─┐
                         ├──→ Flint 3 / QNetd
zimaproxmox  → QDevice ─┘

Das Endergebnis k?nnen wir mit folgendem Befehl pr?fen:

corosync-qdevice-tool -s

lautet:

QNetd host: 192.168.1.1:5403

State: Connected

Und mit:

pvecm status

erhalten wir:

Expected votes: 3

Total votes: 3

Quorum: 2

Quorate: Yes

Das Besondere an dieser L?sung ist, dass wir den Flint 3 weder in einen Debian-Server verwandelt noch OpenWrt ersetzt haben.

Der Flint bleibt unser OpenWrt-Router.

Wir nutzen lediglich ein st?ndig eingeschaltetes ARM64-Ger?t mit ausreichend Speicherplatz und Unterst?tzung f?r chroot, um eine minimale Debian-Umgebung ausschlie?lich f?r QNetd einzurichten.

So erhalten wir eine physisch unabh?ngige dritte Stimme f?r einen Proxmox-Cluster mit zwei Knoten, ohne einen weiteren Server nur f?r den Arbitrator eingeschaltet zu halten.

Empfohlene Ausruestung

In diesem Projekt verwendetes Geraet: GL.iNet GL-BE9300 Flint 3. Falls du es brauchst, findest du es hier:

GL.iNet GL-BE9300 Flint 3 — Im Video getestet: AliExpress España · AliExpress desde Europa · AliExpress Oficial GL.iNet · Amazon

1. Die verwendete Umgebung

2. Per SSH mit dem Flint 3 verbinden

3. System, Architektur, Pakete und verf?gbaren Speicherplatz pr?fen

4. Warum eine minimale Debian-Umgebung innerhalb von OpenWrt verwenden

5. debootstrap auf dem Flint installieren

6. Problem mit GPG und Debian Bookworm

7. Debian 12 ARM64 minbase erstellen

8. Debian aktualisieren und QNetd installieren

9. /proc und /dev/pts w?hrend der Installation

10. QNetd-Zertifikate initialisieren

11. Den Benutzer coroqnetd

12. QNetd manuell testen

13. Das LD_PRELOAD-Problem von OpenWrt

14. Den QNetd-Service unter OpenWrt einrichten

15. Pr?fen, ob QNetd l?uft

16. Den Respawn pr?fen

17. Proxmox vorbereiten

18. Vor dem ?ndern von QDevice ein Backup erstellen

19. Eine neue NSS-Datenbank auf Proxmox erstellen

20. Die CA vom Flint nach Proxmox kopieren

21. Den CSR des Clusters erstellen

22. Den CSR an den Flint senden

23. Das signierte Zertifikat abrufen

24. Das Cluster-Zertifikat importieren

25. Zertifikat und privaten Schl?ssel nach PKCS#12 exportieren

26. Den zweiten Proxmox-Knoten vorbereiten

27. Eine endg?ltige NSS-Datenbank vorbereiten

28. Die aktiven Zugangsdaten ersetzen

29. Die IP des alten QNetd ?ndern

30. Nur QDevice neu starten

31. Das Quorum pr?fen

32. Ein vollst?ndiges Backup des Flint-QNetd erstellen

33. Das Backup nach Windows herunterladen

34. Das System nach einem Neustart des Flint testen

35. Pr?fen, ob Proxmox die Verbindung automatisch wiederherstellt

36. Ein ungew?hnliches Problem, das auftrat

37. Schnelldiagnose, wenn QNetd nicht startet

38. Schnelldiagnose von Proxmox aus

39. Werte, die an die eigene Installation angepasst werden m?ssen

Adresse des Flint

Proxmox-Knoten

Clustername

Architektur

UID und GID von coroqnetd

Debian-Pfad

Debian-Version

TLS

config_version

40. Das Endergebnis

Empfohlene Ausruestung

Verwandtes Video

Empfohlene Ausruestung

9. `/proc` und `/dev/pts` w?hrend der Installation

11. Den Benutzer `coroqnetd`

UID und GID von `coroqnetd`

`config_version`