---
name: project_lab_freebsd_against
description: Le lab FreeBSD est l'hôte "against" (192.168.1.2) — versions, déploiement manuel du script de synchro, garde-fou kea-dhcp4 -t
metadata:
  type: project
---

Le lab FreeBSD de DHCPMan est la machine **`against`**, `192.168.1.2` (elle héberge aussi
MySQL et le serveur de synchro). Ce n'est pas la machine où je tourne — voir
[[feedback_dev_machine_is_not_lab]] et [[project_sync_ip]].

État au 10 août 2026 : FreeBSD 14.4-RELEASE-p8, **Kea 3.2.0**, **python3.12**
(3.11 retiré par la mise à jour système), `mysql-connector-python` présent pour 3.12.
`kea_enable="YES"` + `kea_sync_from_db_enable="YES"` dans `/etc/rc.conf`.

**Déploiement du serveur de synchro : manuel, pas automatisé.** `~/sync.sh` ne pousse que vers
le partage / le tar.gz (voir [[project_release_deploy]]) ; c'est l'utilisateur qui copie ensuite
`kea-sync-from-db.py` vers `/usr/local/sbin/kea-sync-from-db.py`, puis
`service kea_sync_from_db restart`. Donner un marqueur `grep -c <symbole nouveau>` pour qu'il
vérifie que le bon fichier est arrivé avant d'aller plus loin.

**Garde-fou avant toute application de config Kea** : `kea-dhcp4 -t <fichier>` valide sans
appliquer, et `kea-dhcp4` continue de servir les clients sur sa config en mémoire tant qu'on n'a
pas fait `service kea restart`. Kea signale ses refus **un champ à la fois** : prévoir plusieurs
allers-retours plutôt qu'un seul correctif. `-t` ne teste que la syntaxe, pas la capacité à binder
une adresse — vérifier séparément avec `ifconfig` que l'IP d'écoute est locale.

**Why:** les mises à jour système du lab sont faites par un agent d'infra distinct de moi ;
je découvre leurs effets après coup (python 3.11→3.12, puis suppression de kea-ctrl-agent en
Kea 3.1.8). Ces montées de version cassent l'appli sans prévenir, et la seule façon sûre d'y
répondre à distance est de guider l'utilisateur commande par commande.

**How to apply:** ne jamais faire redémarrer Kea sans un `-t` vert au préalable, et sauvegarder
`kea-dhcp4.conf` avant de le régénérer. La migration Kea 3.2 elle-même est documentée dans
CLAUDE.md, section « Canal de contrôle Kea ».

**Reprise du chantier** : `docs/superpowers/plans/2026-08-10-migration-kea-3.2.md` — état des
lieux complet, contrôle du schéma SQL (fait, RAS) et checklist d'anticipation pour la prod
AlmaLinux, qui n'est pas couverte par le correctif FreeBSD.