Come trasformare un GL.iNet Flint 3 con OpenWrt in QNetd per un cluster Proxmox

1. Ambiente utilizzato

Nella mia installazione:

Código

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

Cluster:
Nome: hectormox

Nodo 1:
miniproxmox
192.168.1.6

Nodo 2:
zimaproxmox
192.168.1.7

Debian minimale ? stato installato in:

/opt/debian-qnetd

QNetd ? in ascolto sulla porta standard:

TCP 5403

2. Connettersi al Flint 3 tramite SSH

Su Windows possiamo usare direttamente il client SSH incluso in PowerShell:

ssh root@192.168.1.1

Inseriamo la password di amministrazione del router.

Una volta effettuato l?accesso, vedremo qualcosa di simile a:

Código

BusyBox
OpenWrt
root@GL-BE9300:~#

Prima di installare qualsiasi cosa, vale la pena scoprire cosa ? effettivamente disponibile.

3. Verificare sistema, architettura, pacchetti e spazio disponibile

Eseguiamo:

bash

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

uname -a
uname -m

command -v opkg
command -v apk

opkg print-architecture

df -h

Sul mio Flint ho trovato un sistema:

OpenWrt 23.05-SNAPSHOT

aarch64

e opkg come gestore di pacchetti.

Ho verificato anche quali strumenti fossero disponibili:

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

E soprattutto se OpenWrt offrisse gi? Corosync:

bash

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

Nel mio firmware non era presente corosync-qnetd.

Quindi non potevamo semplicemente eseguire:

opkg install corosync-qnetd

come faremmo con un pacchetto nativo di OpenWrt.

4. Perch? usare una Debian minimale all?interno di OpenWrt

Invece di provare a compilare Corosync e tutte le sue dipendenze direttamente per OpenWrt, ho scelto una soluzione molto pi? semplice:

creare una Debian ARM64 minimale all?interno di una cartella ed eseguire QNetd tramite chroot.

OpenWrt continua a essere il sistema operativo del router. Non installiamo un altro kernel, non virtualizziamo nulla e non sostituiamo il firmware.

La struttura ? semplicemente questa:

Código

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

Il Flint continua quindi a funzionare come router OpenWrt, ma dispone di un piccolo ambiente Debian da cui possiamo eseguire software non presente nei suoi repository.

5. Installare debootstrap sul Flint

Per prima cosa aggiorniamo gli indici:

opkg update

Installiamo debootstrap:

opkg install debootstrap

Verifichiamo che sia disponibile:

bash

command -v debootstrap
debootstrap --version

E controlliamo lo spazio disponibile:

df -h /overlay

Nel mio caso c?erano diversi gigabyte liberi, sufficienti per una Debian minimale.

6. Problema con GPG e Debian Bookworm

Qui ? comparso uno dei primi problemi specifici della mia versione di OpenWrt.

debootstrap deve verificare le firme dei repository Debian, ma gpgv inizialmente disponibile sul router era troppo vecchio per alcune firme usate da Bookworm.

La soluzione ? stata installare:

opkg install gpgv2

Possiamo verificarlo con:

gpgv2 --version

Ci servono anche le chiavi ufficiali di Debian.

Prepariamo una cartella temporanea:

bash

BASE="/tmp/qnetd-bootstrap"

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

Scarichiamo il pacchetto debian-archive-keyring relativo a Debian Bookworm.

? opportuno verificare quale sia la versione corrente del pacchetto quando si segue questa guida, invece di mantenere per sempre un URL specifico.

Una volta scaricato:

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

Ne estraiamo il contenuto:

bash

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

La chiave ? disponibile in:

bash

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

Per assicurarci che debootstrap usi gpgv2, creiamo un piccolo override temporaneo:

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

Questo influir? solo sul PATH che useremo per eseguire debootstrap.

7. Creare Debian 12 ARM64 minbase

Definiamo il percorso in cui installarla:

TARGET="/opt/debian-qnetd"

Eseguiamo:

bash

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

Questo scarica e installa una Debian 12 minimale in:

/opt/debian-qnetd

Possiamo verificarne il contenuto:

ls -la /opt/debian-qnetd

E accedere manualmente:

chroot /opt/debian-qnetd /bin/bash

Per tornare a OpenWrt:

exit

8. Aggiornare Debian e installare QNetd

Da OpenWrt possiamo eseguire direttamente comandi all?interno del chroot:

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

Prima di installarlo, verifichiamo che il pacchetto sia disponibile:

bash

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

Nel mio caso Debian offriva:

corosync-qnetd 3.0.3-1

L?installazione iniziale ha rilevato alcune dipendenze mancanti nell?ambiente minbase.

Per prima cosa ho riparato il database dei pacchetti con:

bash

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

Poi ho installato:

bash

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

Tra le dipendenze installate da Debian c?erano librerie NSS, Perl, netbase e altri pacchetti necessari.

9. `/proc` e `/dev/pts` durante l?installazione

Durante l?installazione sono comparsi alcuni avvisi relativi a /proc e /dev/pts.

Ho montato temporaneamente:

bash

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

bash

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

Questo ci ha aiutato durante la preparazione di Debian.

In seguito abbiamo verificato che QNetd non ha bisogno di questi bind mount per funzionare normalmente, quindi non fanno parte del service definitivo.

10. Inizializzare i certificati di QNetd

QNetd usa un database NSS per gestire i certificati.

Nella nostra Debian ? disponibile l?utilit?:

corosync-qnetd-certutil

La inizializziamo da OpenWrt:

bash

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

Dal punto di vista di OpenWrt, il database NSS si trova in:

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

Possiamo verificarlo con:

bash

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

All?interno del chroot, lo stesso percorso ?:

/etc/corosync/qnetd/nssdb

La CA pubblica si trova in:

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

11. Verificare l?utente `coroqnetd`

Il pacchetto Debian crea un utente dedicato all?esecuzione di QNetd.

Verifichiamo i suoi identificativi:

chroot /opt/debian-qnetd id coroqnetd

Nella mia installazione ho ottenuto:

UID 100

GID 101

? importante perch? in seguito eseguir? QNetd con:

--userspec=100:101

Questi numeri non vanno copiati senza averli prima verificati.

Ogni installazione deve eseguire:

chroot /opt/debian-qnetd id coroqnetd

e usare i valori ottenuti.

Controlliamo anche i permessi del database NSS:

bash

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

Nel mio caso ho dovuto modificare:

bash

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

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

Anche nel mio caso, 101 era il GID specifico dell?installazione.

12. Provare QNetd manualmente

Prima di trasformarlo in un service, ? importante verificare che il daemon si avvii davvero.

Ho provato:

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

I parametri utilizzati sono:

-f: eseguirlo in foreground.
-4: usare IPv4.
-l 192.168.1.1: indirizzo di ascolto di QNetd.
-p 5403: porta.
-s req: richiedere TLS nella versione utilizzata.

Prima di copiarli, conviene verificare la guida della versione installata:

bash

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

13. Il problema di LD_PRELOAD in OpenWrt

Eseguendo programmi Debian da OpenWrt, sono comparsi avvisi relativi a una variabile del firmware chiamata LD_PRELOAD.

Per evitare che il processo nel chroot ereditasse le variabili di OpenWrt, alla fine l?ho eseguito con un ambiente pulito:

bash

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

Questo dettaglio ? entrato a far parte del service definitivo.

14. Creare il service QNetd in OpenWrt

Questa ? una delle differenze pi? importanti rispetto a una normale Debian.

Su Debian useremmo systemd.

Su OpenWrt usiamo procd e gli script in:

/etc/init.d/

Creiamo il file:

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

Impostiamo i permessi:

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

Attiviamo l?avvio automatico:

/etc/init.d/qnetd-debian enable

Possiamo controllare i collegamenti creati:

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

Sul mio Flint sono stati creati:

/etc/rc.d/S98qnetd-debian

/etc/rc.d/K10qnetd-debian

Avviamo il service:

/etc/init.d/qnetd-debian start

15. Verificare che QNetd sia in esecuzione

Per prima cosa cerchiamo il processo:

pidof corosync-qnetd

Poi controlliamo la porta:

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

Dovremmo vedere:

192.168.1.1:5403 LISTEN

Possiamo anche controllare il processo completo:

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

E consultiamo direttamente procd:

bash

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

Uno stato corretto contiene:

"running": true

Nel mio caso si poteva vedere anche:

Código

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

16. Verificare il riavvio automatico del processo

Il service include:

procd_set_param respawn 3600 5 5

Questo permette a procd di riavviare QNetd se il processo termina inaspettatamente.

Durante le prove abbiamo terminato manualmente il processo e verificato che ricomparisse con un altro PID e tornasse in ascolto su:

192.168.1.1:5403

17. Preparare Proxmox

Passiamo ora al primo nodo del cluster:

ssh root@192.168.1.6

Verifichiamo lo stato attuale:

pvecm status

corosync-qdevice-tool -s

Il mio cluster si chiama:

hectormox

In precedenza c?era un altro QNetd su:

192.168.1.5:5403

Il nuovo sar? su:

192.168.1.1:5403

18. Fare un backup prima di modificare QDevice

Prima di intervenire sui certificati ho salvato:

/etc/corosync/qdevice

/etc/pve/corosync.conf

Per esempio:

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"

Non consiglio di procedere senza questo backup.

19. Creare un nuovo database NSS su Proxmox

Su 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. Copiare la CA dal Flint a Proxmox

Da miniproxmox:

bash

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

Importiamo la CA:

bash

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

Verifichiamo:

bash

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

Dovremmo vedere:

QNet CA CT,c,c

21. Creare il CSR del cluster

Generiamo un po? di entropia:

bash

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

Creiamo il 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"

Bisogna sostituire:

hectormox

con il nome effettivo del cluster.

Possiamo verificarlo con:

pvecm status

22. Inviare il CSR al Flint

Da Proxmox:

bash

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

Ci connettiamo di nuovo al Flint:

ssh root@192.168.1.1

E firmiamo il CSR:

bash

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

Il certificato firmato si trova in:

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

23. Recuperare il certificato firmato

Da miniproxmox:

bash

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

Possiamo convertirlo in PEM:

bash

cd /root/qnetd-migration

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

E verificarlo:

bash

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

Il risultato corretto ?:

OK

24. Importare il certificato del cluster

Aggiungiamo a NSS il certificato firmato:

bash

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

Verifichiamo:

bash

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

Ora dovrebbero comparire:

QNet CA CT,c,c

Cluster Cert u,u,u

25. Esportare il certificato e la chiave privata in PKCS#12

Generiamo:

bash

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

Risultato atteso:

PKCS12 EXPORT SUCCESSFUL

Questo file contiene una chiave privata. Non deve essere pubblicato n? condiviso.

26. Preparare il secondo nodo Proxmox

Copiamo il file sul secondo nodo:

bash

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

bash

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

Su 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"

Importiamo la CA:

bash

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

Importiamo PKCS#12:

bash

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

Il risultato corretto ?:

PKCS12 IMPORT SUCCESSFUL

E controlliamo:

bash

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

27. Preparare un database NSS definitivo

Prima di modificare il database effettivamente usato da QDevice, ho preparato un?altra cartella:

/root/qnetd-migration/nssdb-ready

Su ciascun nodo:

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"

Verifichiamo:

bash

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

E possiamo verificare l?identit?:

bash

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

Nel mio caso:

subject=CN=hectormox

issuer=CN=QNet CA

28. Sostituire le credenziali attive

Abbiamo eseguito questo passaggio nodo per nodo.

Arrestiamo soltanto QDevice:

systemctl stop corosync-qdevice

Non arrestiamo Corosync.

Salviamo il database precedente:

bash

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

Copiamo quello nuovo:

bash

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

Sistemiamo i permessi:

bash

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

Verifichiamo:

bash

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

E avviamo QDevice:

systemctl start corosync-qdevice

Ripetiamo la stessa procedura sull?altro nodo.

29. Cambiare l?IP del vecchio QNetd

Nel mio caso QDevice era gi? configurato per usare un altro server:

192.168.1.5

e doveva passare al Flint:

192.168.1.1

Prima ho creato un altro backup:

bash

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

La modifica ? stata:

- host: 192.168.1.5

+ host: 192.168.1.1

Abbiamo anche incrementato:

- config_version: 3

+ config_version: 4

Il blocco corrispondente ? diventato simile a:

bash

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

Ricorda che config_version deve essere incrementato rispetto al valore presente in ciascuna installazione.

Non copiare alla lettera 3 ? 4.

30. Riavviare solo QDevice

Dopo la modifica, Corosync ha adottato la nuova configurazione, ma il processo QDevice continuava a usare il vecchio indirizzo finch? non lo abbiamo riavviato.

Eseguiamo:

systemctl restart corosync-qdevice

Verifichiamo:

corosync-qdevice-tool -s

Il risultato corretto ? stato:

Cluster name: hectormox

QNetd host: 192.168.1.1:5403

Algorithm: Fifty-Fifty split

State: Connected

Ripetiamo il riavvio di QDevice anche sul secondo nodo.

31. Verificare il quorum

Eseguiamo:

pvecm status

Nel nostro caso il risultato finale ? stato:

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

E nelle informazioni sui membri:

0x00000001 1 A,V,NMW 192.168.1.6

0x00000002 1 A,V,NMW 192.168.1.7

0x00000000 1 Qdevice

Questo significa:

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

Totale:

3 voti

Il quorum necessario continua a essere:

2

32. Fare un backup completo del QNetd sul Flint

Una volta terminato tutto, ho fatto un backup completo dell?ambiente.

Definiamo:

bash

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

Arrestiamo QNetd per qualche istante:

"$SERVICE" stop

Creiamo il 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

Riavviamo il service:

"$SERVICE" start

Verifichiamo l?integrit?:

bash

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

Il mio backup finale occupava circa:

157 MB

33. Scaricare il backup su Windows

Da PowerShell:

bash

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

Poi calcoliamo l?hash:

bash

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

Il valore deve corrispondere esattamente a quello ottenuto prima sul Flint.

Il backup contiene certificati e chiavi private, quindi va conservato in un luogo sicuro.

34. Provare il sistema dopo il riavvio del Flint

Non volevo considerare concluso il progetto solo perch? funzionava dopo averlo avviato manualmente.

Ho riavviato il Flint 3 dalla sua interfaccia web.

Quando ? tornato disponibile, mi sono collegato di nuovo:

ssh root@192.168.1.1

Per prima cosa ho verificato che lo script fosse ancora presente:

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

Poi:

pidof corosync-qnetd

Ho controllato la porta:

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

Y finalmente procd:

bash

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

Nel test finale ho ottenuto:

23 /etc/init.d/qnetd-debian

un PID valido:

28139

la porta:

192.168.1.1:5403 LISTEN

"running": true

Questo dimostrava che QNetd si era avviato automaticamente dopo il riavvio del router.

35. Verificare che Proxmox si riconnetta automaticamente

Su miniproxmox:

corosync-qdevice-tool -s

Lo stato ? tornato automaticamente a:

QNetd host: 192.168.1.1:5403 State: Connected

pvecm status

ha mostrato di nuovo:

Expected votes: 3

Total votes: 3

Quorum: 2

Quorate: Yes

Se riavviamo il Flint, i nodi Proxmox perdono temporaneamente il voto di QDevice; quando QNetd riparte, i QDevice si riconnettono automaticamente.

36. Un problema curioso che abbiamo riscontrato

Durante una prova ? successo qualcosa di insolito.

Il service risultava abilitato:

/etc/init.d/qnetd-debian enabled

ma QNetd non era in esecuzione.

Abbiamo controllato:

pidof corosync-qnetd

Non veniva restituito alcun PID.

Non c?era nemmeno nulla in ascolto:

bash

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

Abbiamo quindi controllato lo script:

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

E abbiamo scoperto:

0 /etc/init.d/qnetd-debian

Il file era diventato vuoto.

Eppure esistevano ancora:

/etc/rc.d/S98qnetd-debian

/etc/rc.d/K10qnetd-debian

Per questo OpenWrt poteva indicare che il service era abilitato anche se in realt? non c?era nulla da eseguire.

Abbiamo ricreato lo script e ripetuto da capo la prova dopo il riavvio.

Da allora l?avvio ? riuscito correttamente.

La conclusione ? importante:

Non basta verificare che un service sia abilitato.

? opportuno controllare anche:

bash

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

37. Diagnostica rapida se QNetd non si avvia

Per prima cosa verifichiamo che lo script esista e non sia vuoto:

bash

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

Poi:

/etc/init.d/qnetd-debian enabled

Cerchiamo il processo:

pidof corosync-qnetd

Porta:

bash

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

Stato in procd:

bash

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

E se vogliamo provare QNetd al di fuori di procd:

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=$?"

Se restituisce:

124

significa che il daemon era ancora in esecuzione quando timeout lo ha terminato.

In questo caso probabilmente il problema riguarda il service procd, non QNetd.

38. Diagnostica rapida da Proxmox

Per prima cosa controlliamo i service:

bash

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

Poi:

corosync-qdevice-tool -s

Il risultato corretto ?:

State: Connected

pvecm status

deve mostrare:

Total votes: 3

Quorate: Yes

Se compare:

Cannot initialize CMAP service

non significa necessariamente che QNetd abbia un problema.

Conviene controllare prima:

systemctl is-active corosync

Durante le mie prove si ? verificato proprio un problema di questo tipo, risultato indipendente da QNetd e legato ad alcuni mount NFS dell?host Proxmox.

39. Valori da adattare alla propria installazione

Non bisogna copiare alla lettera tutti i valori di questa guida.

Indirizzo del Flint

Nel mio caso:

192.168.1.1

Nodi Proxmox

192.168.1.6

192.168.1.7

Nome del cluster

hectormox

Verificalo con:

pvecm status

Architettura

Il mio Flint ?:

ARM64

ma dobbiamo verificare con:

uname -m

UID e GID di `coroqnetd`

Nella mia installazione:

100:101

Ma bisogna controllare con:

bash

chroot /opt/debian-qnetd \
    id coroqnetd

Percorso di Debian

Ho scelto:

/opt/debian-qnetd

Non ? obbligatorio.

Versione di Debian

In questa guida:

Debian 12 Bookworm

TLS

La mia versione usava:

-s req

Va verificato con:

bash

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

`config_version`

Non copiare:

3 → 4

Bisogna incrementare di uno il valore attuale nel nostro corosync.conf.

40. Risultato finale

Al termine dell?intera procedura, il Flint 3 funziona cos?:

Código

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

QNetd:

192.168.1.1:5403

TLS

procd

riavvio automatico

avvio automatico

E il cluster:

Código

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

Possiamo verificare il risultato finale con:

corosync-qdevice-tool -s

QNetd host: 192.168.1.1:5403

State: Connected

E con:

pvecm status

otteniamo:

Expected votes: 3

Total votes: 3

Quorum: 2

Quorate: Yes

Il vantaggio di questa soluzione ? che non abbiamo trasformato il Flint 3 in un server Debian n? sostituito OpenWrt.

Il Flint rimane il nostro router OpenWrt.

Abbiamo semplicemente sfruttato un dispositivo ARM64 sempre acceso, con spazio di archiviazione sufficiente e supporto per chroot, per creare una Debian minimale dedicata all?esecuzione di QNetd.

In questo modo possiamo avere un terzo voto fisicamente indipendente per un cluster Proxmox a due nodi, senza tenere acceso un altro server solo per eseguire l?arbitro.

Attrezzatura consigliata

Dispositivo usato in questo progetto: GL.iNet GL-BE9300 Flint 3. Se ti serve, ecco dove trovarlo:

GL.iNet GL-BE9300 Flint 3 — Recensito nel video: AliExpress España · AliExpress desde Europa · AliExpress Oficial GL.iNet · Amazon

1. Ambiente utilizzato

2. Connettersi al Flint 3 tramite SSH

3. Verificare sistema, architettura, pacchetti e spazio disponibile

4. Perch? usare una Debian minimale all?interno di OpenWrt

5. Installare debootstrap sul Flint

6. Problema con GPG e Debian Bookworm

7. Creare Debian 12 ARM64 minbase

8. Aggiornare Debian e installare QNetd

9. /proc e /dev/pts durante l?installazione

10. Inizializzare i certificati di QNetd

11. Verificare l?utente coroqnetd

12. Provare QNetd manualmente

13. Il problema di LD_PRELOAD in OpenWrt

14. Creare il service QNetd in OpenWrt

15. Verificare che QNetd sia in esecuzione

16. Verificare il riavvio automatico del processo

17. Preparare Proxmox

18. Fare un backup prima di modificare QDevice

19. Creare un nuovo database NSS su Proxmox

20. Copiare la CA dal Flint a Proxmox

21. Creare il CSR del cluster

22. Inviare il CSR al Flint

23. Recuperare il certificato firmato

24. Importare il certificato del cluster

25. Esportare il certificato e la chiave privata in PKCS#12

26. Preparare il secondo nodo Proxmox

27. Preparare un database NSS definitivo

28. Sostituire le credenziali attive

29. Cambiare l?IP del vecchio QNetd

30. Riavviare solo QDevice

31. Verificare il quorum

32. Fare un backup completo del QNetd sul Flint

33. Scaricare il backup su Windows

34. Provare il sistema dopo il riavvio del Flint

35. Verificare che Proxmox si riconnetta automaticamente

36. Un problema curioso che abbiamo riscontrato

37. Diagnostica rapida se QNetd non si avvia

38. Diagnostica rapida da Proxmox

39. Valori da adattare alla propria installazione

Indirizzo del Flint

Nodi Proxmox

Nome del cluster

Architettura

UID e GID di coroqnetd

Percorso di Debian

Versione di Debian

TLS

config_version

40. Risultato finale

Attrezzatura consigliata

Video correlato

Attrezzatura consigliata

9. `/proc` e `/dev/pts` durante l?installazione

11. Verificare l?utente `coroqnetd`

UID e GID di `coroqnetd`

`config_version`