docs: build de df6c90d216

_sources/exploitation/diagnostic.rst

@@ -0,0 +1,148 @@
+Diagnostic
+==========
+
+Symptôme, cause probable, vérification. Les causes listées sont celles réellement rencontrées.
+
+La ressource part en ``error`` juste après le 202
+-------------------------------------------------
+
+``Execute`` a échoué : la cause est dans le journal de l'agent, pas dans la réponse HTTP.
+
+.. code-block:: bash
+
+   journalctl -u agent -n 100
+
+Cas fréquents :
+
+* subnet en mode ``public_ip`` — la mise en place host n'est pas implémentée, l'échec est attendu ;
+* ``vxlan_id`` déjà utilisé sur l'host ;
+* bridge cible absent : ``iface_type`` inconnu retombé sur ``default_interface``, lui-même
+  inexistant.
+
+Avant toute recréation, émettre un ``DELETE`` : il n'y a pas de rollback, les objets système
+partiellement créés subsistent.
+
+La VM démarre mais n'a pas d'adresse
+------------------------------------
+
+Le DHCP est servi par une instance dédiée au subnet. Quelle unit selon ``dhcp.backend`` :
+
+**Backend ``dnsmasq``**
+
+.. code-block:: bash
+
+   systemctl status 'dnsmasq@<netns>_<bridge>'
+   tail -50 /var/log/dnsmasq-<netns>_<bridge>.log
+   cat /run/dnsmasq-<netns>_<bridge>.leases
+   cat /etc/dnsmasq.d/<netns>_<bridge>.conf
+
+**Backend ``two``**
+
+.. code-block:: bash
+
+   systemctl status 'dhcp@<netns>_<bridge>'
+   journalctl -u 'dhcp@<netns>_<bridge>' -n 50
+
+   # Ce que le serveur a réellement en mémoire
+   echo '{"verb":"get-state"}' \
+     | socat - UNIX-CONNECT:/run/two/dhcp/<netns>_<bridge>.sock | jq .
+
+   # Ce qu'il enverrait à une MAC donnée, sans effet de bord
+   echo '{"verb":"probe","mac":"00:22:33:00:00:0A"}' \
+     | socat - UNIX-CONNECT:/run/two/dhcp/<netns>_<bridge>.sock | jq .lease
+
+``probe`` est le point de départ le plus rapide : il montre l'adresse, le masque, le routeur, les
+DNS et les routes classless tels qu'ils partiraient. Une réponse ``"served": false`` signifie que
+la MAC n'est pas réservée — l'ordre ``set-host`` n'a jamais atteint le serveur, ou la VM n'a pas
+été créée par cet agent.
+
+Le watchdog signale ces écarts de lui-même, à chaque tick, en comparant l'état servi à la base :
+``dhcp reservation missing on the server``, ``stale dhcp reservation``, ``dhcp reservation
+diverges``. Regarder ses notifications avant de sonder à la main.
+
+Si le serveur ne voit passer aucune requête, le problème est en amont : tap absent, bridge non
+raccordé, VM dans le mauvais netns.
+
+La VM a une adresse mais cloud-init n'applique rien
+---------------------------------------------------
+
+Deux causes distinctes, à écarter dans cet ordre.
+
+**1. La VM porte déjà cet ``instance-id``.** ``instance-id`` vaut le nom de la VM : sur un disque
+déjà provisionné sous le même nom, cloud-init considère l'instance connue et ne rejoue pas le
+user-data. Vérification dans le guest :
+
+.. code-block:: bash
+
+   cloud-init query instance-id
+   ls /var/lib/cloud/instances/
+
+**2. Le serveur de metadata est injoignable.** Depuis le guest :
+
+.. code-block:: bash
+
+   ip route
+   curl -s http://169.254.169.254/latest/meta-data/
+
+La route ``169.254.169.254/32`` doit être présente, avec l'``interface_ip`` du subnet comme
+next-hop. Si elle est absente ou pointe ailleurs, la DNAT posée en ``PREROUTING`` dans le netns
+n'est jamais traversée : la trame est commutée en L2 et le serveur reste injoignable. Voir
+:doc:`/concepts/modes-reseau`.
+
+Depuis l'host, l'instance correspondante :
+
+.. code-block:: bash
+
+   systemctl status 'metadata@<vm>'
+   ls -l /run/two/metadata/<vm>/
+
+Le user-data est servi vide
+---------------------------
+
+Un document fourni explicitement vide est servi vide — ce n'est pas la même chose qu'un document
+absent, qui retombe sur le template. Vérifier le contenu réellement écrit :
+
+.. code-block:: bash
+
+   cat /run/two/metadata/<vm>/user-data
+
+Un base64 invalide, lui, aurait été rejeté en 400 à la création.
+
+La VM ne démarre pas (UEFI)
+---------------------------
+
+``uefi: true`` exige les fichiers OVMF déclarés dans la configuration :
+
+.. code-block:: bash
+
+   ls -l /usr/share/OVMF/OVMF_CODE.fd /usr/share/OVMF/OVMF_VARS.fd
+   ls -l /run/two/vms/efi/
+
+Sur Debian et Ubuntu, le paquet est ``ovmf``.
+
+Le ``DELETE`` renvoie 409
+-------------------------
+
+La suppression n'est autorisée que depuis ``running`` ou ``error``. Depuis ``creating`` ou
+``deleting``, attendre l'état stable. Pour un VPC, tous les subnets doivent être supprimés
+d'abord.
+
+La base et le système ont divergé
+---------------------------------
+
+Le watchdog signale une ressource ``running`` absente du système. Il ne répare rien : la
+correction est un ``DELETE`` explicite suivi d'une recréation. Après un redémarrage de l'agent,
+les ressources restées transitoires sont basculées en ``error`` par la migration de démarrage —
+elles n'ont pas forcément échoué, elles ont été interrompues.
+
+L'agent ne redémarre pas après un arrêt brutal
+----------------------------------------------
+
+Badger rejoue son journal au démarrage : c'est normal et attendu, notamment si le budget d'arrêt
+précédent a été dépassé et que la base n'a pas été fermée. Si le démarrage échoue vraiment, le
+message se trouve dans ``journalctl -u agent``.
+
+.. note::
+
+   Les VM ne sont pas réattachées au redémarrage de l'agent : un processus QEMU survivant à
+   l'agent n'est plus piloté par lui.