Comment transformer un GL.iNet Flint 3 avec OpenWrt en QNetd pour un cluster Proxmox

1. Environnement utilisé

Dans mon installation :

Código

Routeur :
GL.iNet Flint 3 / GL-BE9300
IP : 192.168.1.1
OpenWrt 23.05-SNAPSHOT
Architecture ARM64

Cluster :
Nom : hectormox

Nœud 1 :
miniproxmox
192.168.1.6

Nœud 2 :
zimaproxmox
192.168.1.7

Debian minimal était installé dans :

/opt/debian-qnetd

QNetd écoute sur le port standard :

TCP 5403

2. Se connecter au Flint 3 par SSH

Sous Windows, nous pouvons utiliser directement le client SSH fourni avec PowerShell :

ssh root@192.168.1.1

Nous saisissons le mot de passe administrateur du routeur.

Une fois connectés, nous verrons quelque chose de similaire à ceci :

Código

BusyBox
OpenWrt
root@GL-BE9300:~#

Avant toute installation, il est utile de découvrir ce qui est réellement disponible.

3. Vérifier le système, l’architecture, les paquets et l’espace disponible

Nous exécutons :

bash

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

uname -a
uname -m

command -v opkg
command -v apk

opkg print-architecture

df -h

Sur mon Flint, j’ai obtenu le système suivant :

OpenWrt 23.05-SNAPSHOT

aarch64

et opkg comme gestionnaire de paquets.

J’ai également vérifié quels outils étaient disponibles :

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

Et surtout, si OpenWrt proposait déjà Corosync :

bash

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

Dans mon firmware, corosync-qnetd n’était pas présent.

Nous ne pouvions donc pas simplement exécuter :

opkg install corosync-qnetd

comme nous le ferions avec un paquet natif d’OpenWrt.

4. Pourquoi utiliser un Debian minimal dans OpenWrt

Au lieu d’essayer de compiler Corosync et toutes ses dépendances directement pour OpenWrt, j’ai choisi une solution bien plus simple :

créer un Debian ARM64 minimal dans un répertoire et exécuter QNetd avec chroot.

OpenWrt reste le système d’exploitation du routeur. Nous n’installons pas un autre noyau, nous ne virtualisons rien et nous ne remplaçons pas le firmware.

La structure est simplement la suivante :

Código

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

Le Flint continue donc de fonctionner comme routeur OpenWrt, mais dispose d’un petit environnement Debian depuis lequel nous pouvons exécuter des logiciels absents de ses dépôts.

5. Installer debootstrap sur le Flint

Nous commençons par actualiser les index :

opkg update

Nous installons debootstrap:

opkg install debootstrap

Nous vérifions qu’il est disponible :

bash

command -v debootstrap
debootstrap --version

Et nous vérifions l’espace disponible :

df -h /overlay

Dans mon cas, plusieurs gigaoctets étaient libres, suffisamment pour un Debian minimal.

6. Problème avec GPG et Debian Bookworm

C’est l’ qu’est apparu l’un des premiers problèmes propres à ma version d’OpenWrt.

debootstrap doit vérifier les signatures des dépôts Debian, mais le gpgv initialement disponible sur le routeur était trop ancien pour certaines signatures utilisées par Bookworm.

La solution a été d’installer :

opkg install gpgv2

Nous pouvons le vérifier avec :

gpgv2 --version

Nous avons également besoin des clés officielles de Debian.

Nous préparons un répertoire temporaire :

bash

BASE="/tmp/qnetd-bootstrap"

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

Nous téléchargeons le paquet debian-archive-keyring correspondant à Debian Bookworm.

Il est préférable de vérifier quelle est la version actuelle du paquet au moment de suivre ce guide, plutôt que de conserver une URL précise en dur.

Une fois le téléchargement terminé :

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

Nous en extrayons le contenu :

bash

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

La clé est disponible ici :

bash

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

Pour nous assurer que debootstrap utilise gpgv2, nous créons temporairement un petit override :

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

Cela ne concerne que le PATH utilisé pour lancer debootstrap.

7. Créer Debian 12 ARM64 minbase

Nous définissons l’emplacement de l’installation :

TARGET="/opt/debian-qnetd"

Nous exécutons :

bash

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

Cela télécharge et installe un Debian 12 minimal dans :

/opt/debian-qnetd

Nous pouvons vérifier son contenu :

ls -la /opt/debian-qnetd

Et entrer manuellement dans l’environnement :

chroot /opt/debian-qnetd /bin/bash

Pour revenir à OpenWrt :

exit

8. Mettre Debian à jour et installer QNetd

Depuis OpenWrt, nous pouvons lancer directement des commandes dans le chroot :

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

Avant l’installation, nous vérifions que le paquet est disponible :

bash

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

Dans mon cas, Debian proposait :

corosync-qnetd 3.0.3-1

La première installation a révélé quelques dépendances manquantes dans l’environnement minbase.

J’ai d’abord réparé la base de paquets avec :

bash

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

J’ai ensuite installé :

bash

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

Parmi les dépendances finalement installées par Debian figuraient des bibliothèques NSS, Perl, netbase et d’autres paquets nécessaires.

9. `/proc` et `/dev/pts` pendant l’installation

Pendant l’installation, quelques avertissements sont apparus au sujet de /proc et /dev/pts.

J’ai temporairement monté :

bash

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

Et :

bash

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

Cela nous a aidés à préparer Debian.

Nous avons ensuite vérifié que QNetd n’a pas besoin de ces bind mounts pour fonctionner normalement, ils ne font donc pas partie du service définitif.

10. Initialiser les certificats de QNetd

QNetd utilise une base NSS pour gérer ses certificats.

Dans notre Debian, nous disposons de l’utilitaire suivant :

corosync-qnetd-certutil

Nous l’initialisons depuis OpenWrt :

bash

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

Depuis OpenWrt, la base NSS se trouve dans :

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

Nous pouvons la vérifier avec :

bash

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

Dans le chroot, ce même chemin est :

/etc/corosync/qnetd/nssdb

La CA publique se trouve dans :

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

11. Vérifier l’utilisateur `coroqnetd`

Le paquet Debian crée un utilisateur dédié à l’exécution de QNetd.

Nous vérifions ses identifiants :

chroot /opt/debian-qnetd id coroqnetd

Dans mon installation, j’ai obtenu :

UID 100

GID 101

C’est important, car j’exécuterai ensuite QNetd avec :

--userspec=100:101

Ne recopiez pas ces nombres sans les avoir vérifiés.

Chaque installation doit exécuter :

chroot /opt/debian-qnetd id coroqnetd

et utiliser les valeurs obtenues.

Nous vérifions également les permissions de la base NSS :

bash

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

Dans mon cas, j’ai d’ ajuster :

bash

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

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

Dans mon installation aussi, 101 était le GID utilisé.

12. Tester QNetd manuellement

Avant d’en faire un service, il est important de vérifier que le daemon démarre réellement.

J’ai testé :

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

Voici la signification des paramètres utilisés :

-f: l’exécuter au premier plan.
-4: utiliser IPv4.
-l 192.168.1.1: adresse d’écoute de QNetd.
-p 5403: port.
-s req: imposer TLS dans la version utilisée.

Avant de reprendre ces options, il est préférable de vérifier l’aide de la version installée :

bash

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

13. Le problème de LD_PRELOAD d’OpenWrt

Lors du lancement de programmes Debian depuis OpenWrt, des avertissements concernaient une variable du firmware appelée LD_PRELOAD.

Pour empêcher le processus du chroot d’hériter des variables propres à OpenWrt, j’ai fini par le lancer dans un environnement vierge :

bash

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

Ce détail a été intégré au service définitif.

14. Créer le service QNetd dans OpenWrt

C’est l’une des principales différences par rapport à un Debian classique.

Sous Debian, nous utiliserions systemd.

Sous OpenWrt, nous utilisons procd et des scripts dans :

/etc/init.d/

Nous créons le fichier :

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

Nous définissons ses permissions :

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

Nous activons le démarrage automatique :

/etc/init.d/qnetd-debian enable

Nous pouvons vérifier les liens créés :

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

Sur mon Flint, les liens suivants ont été créés :

/etc/rc.d/S98qnetd-debian

/etc/rc.d/K10qnetd-debian

Nous démarrons le service :

/etc/init.d/qnetd-debian start

15. Vérifier que QNetd fonctionne

Nous recherchons d’abord le processus :

pidof corosync-qnetd

Nous vérifions ensuite le port :

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

Nous devrions voir :

192.168.1.1:5403 LISTEN

Nous pouvons aussi vérifier le processus complet :

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

Et nous interrogeons directement procd:

bash

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

Un état correct contient :

"running": true

Dans mon cas, nous pouvions également voir :

Código

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

16. Vérifier le redémarrage automatique du processus

Le service comprend :

procd_set_param respawn 3600 5 5

Cela permet à procd de relancer QNetd si le processus s’arrête inopinément.

Pendant les essais, nous avons arrêté manuellement le processus et vérifié qu’il réapparaissait avec un autre PID et écoutait de nouveau sur :

192.168.1.1:5403

17. Préparer Proxmox

Passons maintenant au premier nœud du cluster :

ssh root@192.168.1.6

Nous vérifions l’état actuel :

pvecm status

Et :

corosync-qdevice-tool -s

Mon cluster s’appelle :

hectormox

Auparavant, un autre QNetd était hébergé à l’adresse :

192.168.1.5:5403

Le nouveau sera à l’adresse :

192.168.1.1:5403

18. Faire une sauvegarde avant de modifier QDevice

Avant de toucher aux certificats, j’ai sauvegardé :

/etc/corosync/qdevice

/etc/pve/corosync.conf

Par exemple :

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"

Je déconseille de continuer sans cette sauvegarde.

19. Créer une nouvelle base NSS sur Proxmox

Sur 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. Copier la CA du Flint vers Proxmox

Depuis miniproxmox:

bash

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

Nous importons la CA :

bash

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

Nous vérifions :

bash

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

Nous devrions voir :

QNet CA CT,c,c

21. Créer le CSR du cluster

Nous générons un peu d’entropie :

bash

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

Nous créons le 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"

Il faut remplacer :

hectormox

par le véritable nom du cluster.

Nous pouvons le vérifier avec :

pvecm status

22. Envoyer le CSR au Flint

Depuis Proxmox :

bash

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

Nous nous reconnectons au Flint :

ssh root@192.168.1.1

Et nous signons le CSR :

bash

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

Le certificat signé se trouve ici :

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

23. Récupérer le certificat signé

Depuis miniproxmox:

bash

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

Nous pouvons le convertir en PEM :

bash

cd /root/qnetd-migration

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

Et le vérifier :

bash

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

Le résultat attendu est :

OK

24. Importer le certificat du cluster

Nous ajoutons le certificat signé à NSS :

bash

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

Nous vérifions :

bash

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

Nous devrions maintenant voir :

QNet CA CT,c,c

Cluster Cert u,u,u

25. Exporter le certificat et la clé privée au format PKCS#12

Nous générons :

bash

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

Résultat attendu :

PKCS12 EXPORT SUCCESSFUL

Ce fichier contient une clé privée. Il ne doit être ni publié ni partagé.

26. Préparer le deuxième nœud Proxmox

Nous copions le fichier sur le deuxième nœud :

bash

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

Et :

bash

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

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

Nous importons la CA :

bash

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

Nous importons PKCS#12 :

bash

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

Le résultat attendu est :

PKCS12 IMPORT SUCCESSFUL

Et nous vérifions :

bash

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

27. Préparer une base NSS définitive

Avant de modifier la base réellement utilisée par QDevice, j’ai préparé un autre répertoire :

/root/qnetd-migration/nssdb-ready

Sur chaque nœud :

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"

Nous vérifions :

bash

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

Et nous pouvons vérifier l’identité :

bash

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

Dans mon cas :

subject=CN=hectormox

issuer=CN=QNet CA

28. Remplacer les identifiants actifs

Nous avons effectué cette étape nœud par nœud.

Nous arrêtons uniquement QDevice :

systemctl stop corosync-qdevice

Nous n’arrêtons pas Corosync.

Nous sauvegardons l’ancienne base :

bash

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

Nous copions la nouvelle :

bash

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

Nous ajustons les permissions :

bash

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

Nous vérifions :

bash

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

Et nous démarrons QDevice :

systemctl start corosync-qdevice

Nous répétons la même procédure sur l’autre nœud.

29. Modifier l’adresse IP de l’ancien QNetd

Dans mon cas, QDevice était déjà configuré pour utiliser un autre serveur :

192.168.1.5

et devait passer sur le Flint :

192.168.1.1

J’ai d’abord fait une autre sauvegarde :

bash

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

La modification était la suivante :

- host: 192.168.1.5

+ host: 192.168.1.1

Nous avons également augmenté :

- config_version: 3

+ config_version: 4

Le bloc correspondant est alors devenu similaire à ceci :

bash

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

Notez que config_version doit être incrémenté par rapport à la valeur de chaque installation.

Il ne faut pas reprendre littéralement 3 → 4.

30. Redémarrer uniquement QDevice

Après la modification, Corosync a adopté la nouvelle configuration, mais le processus QDevice continuait à utiliser l’ancienne adresse jusqu’à son redémarrage.

Nous exécutons :

systemctl restart corosync-qdevice

Nous vérifions :

corosync-qdevice-tool -s

Le résultat attendu était :

Cluster name: hectormox

QNetd host: 192.168.1.1:5403

Algorithm: Fifty-Fifty split

State: Connected

Nous redémarrons QDevice de la même manière sur le deuxième nœud.

31. Vérifier le quorum

Nous exécutons :

pvecm status

Dans notre cas, le résultat final était :

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

Et dans les informations sur les membres :

0x00000001 1 A,V,NMW 192.168.1.6

0x00000002 1 A,V,NMW 192.168.1.7

0x00000000 1 Qdevice

Cela signifie :

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

Total :

3 votes

Le quorum requis reste donc :

2

32. Faire une sauvegarde complète du QNetd du Flint

Une fois toute la configuration terminée, j’ai fait une sauvegarde complète de l’environnement.

Nous définissons :

bash

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

Nous arrêtons brièvement QNetd :

"$SERVICE" stop

Nous créons la sauvegarde :

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

Nous redémarrons ensuite le service :

"$SERVICE" start

Nous vérifions l’intégrité :

bash

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

Ma sauvegarde finale occupait environ :

157 MB

33. Télécharger la sauvegarde sur Windows

Depuis PowerShell :

bash

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

Nous calculons ensuite le hash :

bash

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

La valeur doit correspondre exactement à celle obtenue précédemment sur le Flint.

La sauvegarde contient des certificats et des clés privées, elle doit donc être conservée en lieu sûr.

34. Tester le système après le redémarrage du Flint

Je ne voulais pas considérer le projet terminé simplement parce qu’il fonctionnait après un démarrage manuel.

J’ai redémarré le Flint 3 depuis son interface Web.

Lorsqu’il a été de nouveau disponible, je me suis reconnecté :

ssh root@192.168.1.1

J’ai d’abord vérifié que le script était toujours présent :

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

Ensuite :

pidof corosync-qnetd

J’ai vérifié le port :

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

Y finalmente procd:

bash

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

Lors du test final, j’ai obtenu :

23 /etc/init.d/qnetd-debian

un PID valide :

28139

le port :

192.168.1.1:5403 LISTEN

et :

"running": true

Cela démontrait que QNetd avait démarré automatiquement après le redémarrage du routeur.

35. Vérifier que Proxmox se reconnecte automatiquement

Sur miniproxmox:

corosync-qdevice-tool -s

L’état est automatiquement revenu à :

QNetd host: 192.168.1.1:5403 State: Connected

Et :

pvecm status

affichait de nouveau :

Expected votes: 3

Total votes: 3

Quorum: 2

Quorate: Yes

Si nous redémarrons le Flint, les nœuds Proxmox perdent temporairement le vote de QDevice. Dès que QNetd redémarre, les QDevice se reconnectent automatiquement.

36. Un problème étonnant rencontré pendant les essais

Lors d’un essai, quelque chose d’étrange s’est produit.

Le service était indiqué comme activé :

/etc/init.d/qnetd-debian enabled

mais QNetd ne fonctionnait pas.

Nous avons vérifié :

pidof corosync-qnetd

Aucun PID n’était renvoyé.

Rien n’écoutait non plus sur le port :

bash

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

Nous avons alors examiné le script :

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

Et nous avons découvert :

0 /etc/init.d/qnetd-debian

Le fichier était devenu vide.

Pourtant, les liens suivants existaient toujours :

/etc/rc.d/S98qnetd-debian

/etc/rc.d/K10qnetd-debian

OpenWrt pouvait donc indiquer que le service était activé alors qu’il n’y avait réellement rien à exécuter.

Nous avons recréé le script et repris entièrement le test après redémarrage.

Depuis, le démarrage s’est déroulé correctement.

La conclusion est importante :

Il ne suffit pas de vérifier qu’un service est activé.

Il convient également de vérifier :

bash

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

37. Diagnostic rapide si QNetd ne démarre pas

Nous vérifions d’abord que le script existe et qu’il n’est pas vide :

bash

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

Ensuite :

/etc/init.d/qnetd-debian enabled

Nous recherchons le processus :

pidof corosync-qnetd

Port :

bash

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

état dans procd:

bash

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

Et si nous voulons tester QNetd en dehors de 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=$?"

Si la commande renvoie :

124

cela signifie que le daemon fonctionnait encore lorsque timeout l’a arrêté.

Dans ce cas, le problème vient probablement du service procd, et non de QNetd.

38. Diagnostic rapide depuis Proxmox

Nous vérifions d’abord les services :

bash

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

Ensuite :

corosync-qdevice-tool -s

Le résultat attendu est :

State: Connected

Et :

pvecm status

doit afficher :

Total votes: 3

Quorate: Yes

Si le message suivant apparaît :

Cannot initialize CMAP service

cela ne signifie pas nécessairement que QNetd est en panne.

Vérifions d’abord :

systemctl is-active corosync

Pendant mes essais, nous avons rencontré exactement ce type d’incident. Il s’agissait finalement d’un problème indépendant de QNetd, lié à des montages NFS sur l’hôte Proxmox.

39. Valeurs à adapter à votre installation

Ne reprenez pas littéralement toutes les valeurs de ce guide.

Adresse du Flint

Dans mon cas :

192.168.1.1

Nœuds Proxmox

192.168.1.6

192.168.1.7

Nom du cluster

hectormox

Vérifiez-le avec :

pvecm status

Architecture

Mon Flint est en :

ARM64

mais il faut vérifier avec :

uname -m

UID et GID de `coroqnetd`

Dans mon installation :

100:101

Mais vérifiez avec :

bash

chroot /opt/debian-qnetd \
    id coroqnetd

Chemin de Debian

J’ai choisi :

/opt/debian-qnetd

Ce chemin n’est pas obligatoire.

Version de Debian

Dans ce guide :

Debian 12 Bookworm

TLS

Ma version utilisait :

-s req

Vérifiez avec :

bash

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

`config_version`

Ne reprenez pas :

3 → 4

Il faut incrémenter de un la valeur actuelle dans notre corosync.conf.

40. Résultat final

Une fois toutes les étapes terminées, le Flint 3 fonctionne ainsi :

Código

OpenWrt
└── Debian 12 ARM64 dans chroot
    └── corosync-qnetd

QNetd :

192.168.1.1:5403

TLS

procd

redémarrage automatique

démarrage automatique

Et le cluster :

Código

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

Nous pouvons vérifier le résultat final avec :

corosync-qdevice-tool -s

le résultat est :

QNetd host: 192.168.1.1:5403

State: Connected

Et avec :

pvecm status

nous obtenons :

Expected votes: 3

Total votes: 3

Quorum: 2

Quorate: Yes

L’intérêt de cette solution est que nous n’avons pas transformé le Flint 3 en serveur Debian ni remplacé OpenWrt.

Le Flint reste notre routeur OpenWrt.

Nous avons simplement tiré parti d’un appareil ARM64 toujours allumé, disposant d’un espace de stockage suffisant et prenant en charge chroot, pour créer un Debian minimal dédié à l’exécution de QNetd.

Nous disposons ainsi d’un troisième vote physiquement indépendant pour un cluster Proxmox à deux nœuds, sans devoir laisser un autre serveur allumé uniquement pour exécuter l’arbitre.

Materiel recommande

Appareil utilise dans ce projet : GL.iNet GL-BE9300 Flint 3. Si vous en avez besoin, voici ou le trouver :

GL.iNet GL-BE9300 Flint 3 — Teste dans la video: AliExpress España · AliExpress desde Europa · AliExpress Oficial GL.iNet · Amazon

1. Environnement utilisé

2. Se connecter au Flint 3 par SSH

3. Vérifier le système, l’architecture, les paquets et l’espace disponible

4. Pourquoi utiliser un Debian minimal dans OpenWrt

5. Installer debootstrap sur le Flint

6. Problème avec GPG et Debian Bookworm

7. Créer Debian 12 ARM64 minbase

8. Mettre Debian à jour et installer QNetd

9. /proc et /dev/pts pendant l’installation

10. Initialiser les certificats de QNetd

11. Vérifier l’utilisateur coroqnetd

12. Tester QNetd manuellement

13. Le problème de LD_PRELOAD d’OpenWrt

14. Créer le service QNetd dans OpenWrt

15. Vérifier que QNetd fonctionne

16. Vérifier le redémarrage automatique du processus

17. Préparer Proxmox

18. Faire une sauvegarde avant de modifier QDevice

19. Créer une nouvelle base NSS sur Proxmox

20. Copier la CA du Flint vers Proxmox

21. Créer le CSR du cluster

22. Envoyer le CSR au Flint

23. Récupérer le certificat signé

24. Importer le certificat du cluster

25. Exporter le certificat et la clé privée au format PKCS#12

26. Préparer le deuxième nœud Proxmox

27. Préparer une base NSS définitive

28. Remplacer les identifiants actifs

29. Modifier l’adresse IP de l’ancien QNetd

30. Redémarrer uniquement QDevice

31. Vérifier le quorum

32. Faire une sauvegarde complète du QNetd du Flint

33. Télécharger la sauvegarde sur Windows

34. Tester le système après le redémarrage du Flint

35. Vérifier que Proxmox se reconnecte automatiquement

36. Un problème étonnant rencontré pendant les essais

37. Diagnostic rapide si QNetd ne démarre pas

38. Diagnostic rapide depuis Proxmox

39. Valeurs à adapter à votre installation

Adresse du Flint

Nœuds Proxmox

Nom du cluster

Architecture

UID et GID de coroqnetd

Chemin de Debian

Version de Debian

TLS

config_version

40. Résultat final

Materiel recommande

Video associee

Materiel recommande

9. `/proc` et `/dev/pts` pendant l’installation

11. Vérifier l’utilisateur `coroqnetd`

UID et GID de `coroqnetd`

`config_version`