# tripoli-netctl

Labo pédagogique un-seul-poste sur les network namespaces Linux et la
crate `rtnetlink`. **Ne pilote aucun service de production** :
tripoli-edge et tripoli-api continuent de tourner nativement sur l'hôte,
dans le namespace racine. Ce n'est pas un CNI, pas un orchestrateur -
juste une démonstration, sur une seule machine, de ce qui se passe sous
le capot quand un outil comme Docker ou Kubernetes isole un service en
réseau.

## Ce que fait `create <name>`

1. Crée un network namespace nommé `<name>` (`rtnetlink::NetworkNamespace::add`,
   équivalent de `ip netns add` - fork + `unshare(CLONE_NEWNET)` +
   bind-mount de `/proc/self/ns/net` sur `/run/netns/<name>`).
2. Crée une paire veth (`tv-<name>h` / `tv-<name>p`, noms tronqués à 6
   caractères alphanumériques pour respecter la limite de 15 caractères
   des interfaces Linux).
3. Déplace `tv-<name>p` dans le namespace créé (`setns_by_fd`).
4. Adresse le côté hôte (`10.200.<subnet-id>.1/30`) et l'active.
5. Depuis un thread OS dédié qui fait `setns()` vers le namespace cible,
   adresse le côté namespace (`10.200.<subnet-id>.2/30`), l'active, et
   active `lo` (qui démarre toujours *down* dans un namespace neuf -
   détail facile à oublier, source classique de "ça ne marche pas" dans
   ce genre de labo).

Chaque étape est journalisée en JSON sur stderr et dans
`/var/log/tripoli-netctl/audit.log`.

## Pourquoi un thread dédié, pas `tokio::task::spawn_blocking`

`setns()` change la namespace réseau du **thread appelant**, pour toute
sa durée de vie. Les threads de `spawn_blocking` sont mis en pool et
réutilisés par tokio pour d'autres tâches bloquantes : y laisser un
thread « coincé » dans un namespace réseau casserait silencieusement
n'importe quelle tâche bloquante ultérieure qui tomberait dessus. Un
`std::thread::spawn` dédié, jamais réutilisé, élimine le risque.

## `destroy <name>`

Supprime le côté hôte de la veth - le noyau supprime automatiquement le
pair, même déplacé dans un autre namespace, dès qu'un des deux bouts
disparaît - puis démonte/supprime le fichier de namespace.

## `list`

Énumère `/run/netns` et vérifie, pour chacun, la présence de la veth
hôte associée.

## Utilisation

```bash
sudo ./tripoli-netctl create demo --subnet-id 5
sudo ./tripoli-netctl list
sudo ./tripoli-netctl destroy demo
```

Root est requis (namespaces + netlink privilégié) - vérifié explicitement
au démarrage plutôt que de laisser échouer la première opération avec un
message obscur.

## Limites assumées (v1)

- Pas d'allocation automatique de sous-réseau : `--subnet-id` est
  explicite, une collision entre deux services donnerait une erreur
  claire plutôt qu'une allocation silencieuse qui la masquerait.
- IPv4 uniquement.
- Un seul veth par service - pas de topologie plus complexe (bridge,
  plusieurs interfaces).

## Vérifié

```
$ sudo tripoli-netctl create demo1 --subnet-id 5
service 'demo1' prêt :
  hôte  : tv-demo1h 10.200.5.1/30 (namespace racine)
  ns    : tv-demo1p 10.200.5.2/30 (namespace demo1, /run/netns/demo1)

$ ping -c 2 10.200.5.2        # depuis la racine, vers le namespace
2 packets transmitted, 2 received, 0% packet loss

$ sudo tripoli-netctl destroy demo1
service 'demo1' détruit        # veth et namespace bien supprimés, vérifié
```