Services systemd ================ Quatre units, installées sous ``/opt/two/bin`` par ``deploy.sh``. Les deux units DHCP s'excluent : celle qui tourne dépend de ``dhcp.backend`` (voir :doc:`configuration`). .. list-table:: :header-rows: 1 :widths: 28 32 40 * - Unit - Instance ``%i`` - Rôle * - ``agent.service`` - — - processus principal : API, dispatcher, exécution, watchdog * - ``dnsmasq@.service`` - ``_`` - dnsmasq lancé dans le netns du VPC, un par subnet — backend ``dnsmasq`` * - ``dhcp@.service`` - ``_`` - serveur DHCP intégré, un par subnet — backend ``two`` * - ``metadata@.service`` - ```` - serveur de metadata cloud-init, un par VM Les instances sont créées et pilotées par l'agent au fil des créations de subnets et de VM : il n'y a pas à les démarrer à la main en fonctionnement normal. .. code-block:: bash systemctl status agent systemctl status 'dnsmasq@vp-admin_br-sn000001' # backend dnsmasq systemctl status 'dhcp@vp-admin_br-sn000001' # backend two systemctl status 'metadata@i-web' dnsmasq ------- Backend historique. Le script ``run-dnsmasq-in-netns.sh`` entre dans le netns puis exécute dnsmasq avec un fichier de configuration par subnet, généré par l'agent : .. list-table:: :widths: 40 60 * - Configuration - ``/etc/dnsmasq.d/_.conf`` * - Baux - ``/run/dnsmasq-_.leases`` * - Journal - ``/var/log/dnsmasq-_.log`` * - PID - ``/run/dnsmasq-_.pid`` Le fichier de baux et le journal sont les deux premiers endroits à regarder quand une VM n'obtient pas d'adresse. Serveur DHCP intégré -------------------- Backend ``two``. Le script ``run-dhcp-in-netns.sh`` entre dans le netns puis exécute le binaire ``dhcp``, à qui il passe le bridge à servir et ses deux chemins de fichiers — il ne déduit rien et ignore le netns dans lequel il tourne : .. code-block:: bash /opt/two/bin/dhcp -conf /etc/two/agent.yml \ -interface br-sn000001 \ -state /run/two/dhcp/vp-admin_br-sn000001.state \ -socket /run/two/dhcp/vp-admin_br-sn000001.sock .. list-table:: :widths: 40 60 * - Socket de contrôle - ``/run/two/dhcp/_.sock`` * - État - ``/run/two/dhcp/_.state`` * - Journal - ``journalctl -u 'dhcp@_'`` Il n'y a **ni fichier de configuration ni fichier de baux**. L'agent pousse l'état désiré sur la socket de contrôle : la configuration du subnet à sa création, une réservation par interface à chaque création ou suppression de VM. Les réservations sont statiques — une MAC inconnue n'obtient rien, et le serveur reste silencieux plutôt que de répondre par un refus. Le fichier d'état **appartient au processus**, qui l'écrit et le relit à son démarrage. L'agent ne l'écrit jamais ; il le supprime seulement, à la création du subnet pour écarter un résidu et à sa suppression après avoir arrêté l'unit. Il vit dans ``/run`` parce qu'il n'a aucun sens sans le netns, qui ne survit pas au redémarrage de l'host. Diagnostic : voir :doc:`diagnostic`, qui montre comment interroger la socket. QEMU n'est pas une unit ----------------------- Les processus QEMU sont lancés par ``systemd-run --scope``, **jamais** en unit transitoire. Un scope est exécuté par le processus appelant et hérite donc du network namespace posé par l'agent ; une unit transitoire, forkée par PID 1, démarrerait dans le netns racine et ne verrait pas le tap de la VM. Conséquence pratique : les VM n'apparaissent pas dans ``systemctl list-units`` mais dans ``systemd-cgls``, et elles ne survivent pas à un ``systemctl stop agent`` suivi d'un redémarrage — l'agent ne réattache pas les VM existantes. Sockets par VM -------------- .. code-block:: text /run/two/vms/serial/.sock console série /run/two/vms/monitor/.sock monitor QEMU /run/two/vms/qmp/.sock QMP (utilisé par l'agent) .. code-block:: bash socat -,raw,echo=0 UNIX-CONNECT:/run/two/vms/serial/i-web.sock Arrêt de l'agent ---------------- L'ordre d'arrêt est imposé : serveurs HTTP, puis drainage des workers, puis fermeture de la base. Si le budget d'arrêt est dépassé, la base **n'est pas fermée** — fermer Badger sous un écrivain concurrent est pire qu'un rejeu du journal au démarrage suivant. Un message à ce sujet dans le journal au moment d'un ``stop`` n'est donc pas une anomalie. Mise à jour ----------- ``deploy.sh`` relève les instances ``dnsmasq@``, ``dhcp@`` et ``metadata@`` actives **avant** d'arrêter les services, et les redémarre ensuite : c'est la seule façon de savoir lesquelles relancer. Arrêter les services à la main avant de lancer le script fait perdre cette liste.