Agent d'hôte

L'agent tourne sur chaque hôte géré. Il ouvre lui-même toutes les connexions (aucun port en écoute), s'enregistre auprès de la console avec un jeton d'amorçage et l'empreinte sha256 de l'autorité de la console, puis envoie battements, informations et métriques et exécute les tâches de la console une par une. Le protocole, les types de tâches et les règles de sécurité figurent dans navin-manager/CONTRACT.md, sections 8 et 9.

Quel agent installer

Agent	Paquet	Quand
Agent Go (livré)	navin-manager-agent-go (RPM x86_64 et aarch64, DEB amd64 et arm64, tar.gz)	Tous les hôtes. Un seul binaire statique : ni Python, ni OpenSSL, ni bibliothèque partagée. Systèmes certifiés : RHEL 8/9/10, Rocky Linux 8/9/10, AlmaLinux 8/9/10, Oracle Linux 8/9, CentOS Stream 9/10, Ubuntu 22.04/24.04, Debian 12, Arch Linux (rolling). Il démarre aussi sur un système en fin de vie comme RHEL 7 pour remonter ses informations, mais les vérifications préalables y bloquent toute installation.
Agent Python (référence)	navin-manager-agent (RPM noarch, DEB all, tar.gz)	Conservé pour la compatibilité et comme implémentation de référence. Exige Python 3.9 ou plus récent (RHEL 8 : dnf install python39).

Les deux agents utilisent la même commande (/usr/bin/nm-agent), le même fichier de configuration (/etc/navin-manager-agent/agent.json), le même répertoire d'état (/var/lib/navin-manager-agent) et la même unité systemd (navin-manager-agent.service). Les paquets Go déclarent Provides et Conflicts sur navin-manager-agent : installer l'un remplace l'autre, et un hôte enregistré garde son identité car le répertoire d'état est conservé.

L'agent Go indique agent_impl: "go" dans ses informations. Son information python est la version du python3 du système (ou null) : Python n'est utile que sur les hôtes qui portent un composant python.venv.

Systèmes compatibles

La liste unique est dans navin_manager/os_support.py et publiée par GET /api/v1/system/supported-os (tout utilisateur connecté) ; la page Système du Manager l'affiche dans la carte « Systèmes compatibles ». Systèmes certifiés : RHEL 8/9/10, Rocky Linux 8/9/10, AlmaLinux 8/9/10, Oracle Linux 8/9, CentOS Stream 9/10, Ubuntu 22.04/24.04, Debian 12, Arch Linux (rolling). Paquets : dnf sur la famille RHEL, apt sur la famille Debian, pacman sur la famille Arch Linux.

Verdict	Exemple	Vérification préalable
certifié	Rocky Linux 10	validé
non certifié (version plus récente ou autre distribution d'une famille connue)	Ubuntu 26.04, Fedora	avertissement, jamais bloquant
fin de vie	CentOS 7, RHEL 7, Ubuntu 20.04, Debian 11	bloquant
non pris en charge (famille inconnue)	SUSE Linux Enterprise Server	bloquant

Proxy d'entreprise

Quand les hôtes accèdent aux dépôts de paquets par un proxy, renseignez-le dans Paramètres, carte « Proxy d'entreprise » (paramètre proxy de PUT /api/v1/settings : http_proxy, https_proxy, no_proxy). Les URL sont en http:// ou https:// uniquement, sans nom d'utilisateur, mot de passe ni chemin ; une valeur incorrecte est refusée avec l'erreur proxy_invalid (422). L'installation de l'agent par SSH l'applique :

• gestionnaire de paquets : apt-get -o Acquire::http::Proxy=... -o Acquire::https::Proxy=..., dnf --setopt=proxy=... (le proxy https s'il est renseigné, sinon le proxy http) ;
• unité de l'agent : Environment="HTTP_PROXY=...", Environment="HTTPS_PROXY=..." et Environment="NO_PROXY=...". NO_PROXY contient toujours localhost, 127.0.0.1, ::1 et l'adresse du Manager : l'agent ne passe jamais par le proxy pour joindre son Manager.

Des champs vides signifient un accès direct : l'unité n'a alors aucune ligne de proxy.

Informations (facts)

nm-agent facts affiche, et le heartbeat des informations envoie, les informations de la section 9 de CONTRACT.md : os, kernel, arch, cpu_count, cpu_model, memory_mb, swap_mb, disks, network, selinux, firewall, time_sync, timezone, python, podman, systemd, listening_ports, sysctl, ulimits, gpus, platform, binaries, fs_prefix, rootless, agent_user, service_driver.

platform indique où tourne la machine : virtualization (none sur une machine physique, sinon le nom donné par systemd-detect-virt : kvm, vmware, microsoft, xen, amazon, wsl, docker...), container, cloud.provider (aws, azure, gcp, ibm, ovh, openstack, oracle, alibaba, scaleway, outscale, hetzner, digitalocean, exoscale, none sur site, unknown) avec cloud.source (dmi, virt, none), instance_type (EC2 Nitro, par exemple m5.large), ainsi que vendor, product, bios_vendor et chassis_asset_tag du DMI. Les deux agents donnent la même réponse à partir de fichiers locaux uniquement (/sys/class/dmi/id, systemd-detect-virt avec un délai de 2 s s'il existe, /proc) : ils n'appellent jamais un service de métadonnées d'instance. OVHcloud Public Cloud apparaît comme openstack ; les labels d'hôte provider, region et zone (par exemple provider=ovh region=gra) complètent l'inventaire, et les labels du manager priment.

Propriétés de sécurité

• Aucun shell distant. command.run, les contrôles command de health.check, preflight.run et smoke.run, ainsi que le pilote de processus, n'exécutent qu'un argv[0] absolu présent dans allowed_commands ou dont le chemin réel se trouve dans les racines autorisées. Le programme est lancé à partir de sa liste d'arguments, jamais par un shell : /bin/sh -c ... est refusé avec command_not_allowed.
• Garde des chemins. Les racines autorisées sont résolues une fois au démarrage. Sous une racine, un chemin dont un composant est un lien symbolique, qui contient .. ou qui sort de toutes les racines échoue avec path_not_allowed. Les fichiers sont ouverts relativement à un descripteur de répertoire obtenu par openat2(RESOLVE_NO_SYMLINKS | RESOLVE_BENEATH), ou par un parcours openat(O_NOFOLLOW) sur les noyaux sans openat2 (RHEL 7 et 8), et l'ouverture finale utilise O_NOFOLLOW.
• Archives. Les noms absolus, .., les périphériques, les FIFO et les liens dont la cible sort de la destination sont refusés avec archive_unsafe avant toute écriture ; une archive qui déclare plus de 200 000 entrées ou plus de 64 Gio est refusée avec archive_too_large.
• Téléchargements. Un fichier n'est utilisé qu'une fois son sha256 vérifié (sinon checksum_mismatch) ; rien de non vérifié n'atteint sa destination ni le cache. Un téléchargement s'arrête au-delà de 64 Gio (download_too_large) ou avant que le disque soit plein (disk_space_low).
• Identité. Une clé EC P-256 et une demande de certificat sont créées sur l'hôte ; la clé ne le quitte jamais. Après l'enregistrement, chaque appel utilise le certificat client (TLS mutuel) et une signature NM-HMAC de la requête.
• Secrets. Les valeurs de sensitive_env, de secrets (tests fonctionnels) et les clés de certificat sont remplacées par ****** dans chaque ligne de journal et chaque résultat.

Installer depuis les paquets

Copiez le paquet de l'architecture de l'hôte (depuis packaging/dist/agent-go/ ou le bundle hors ligne) et vérifiez-le avec SHA256SUMS, puis installez-le et enregistrez l'hôte avec la commande affichée par la console :

sha256sum -c --ignore-missing SHA256SUMS
dnf install ./navin-manager-agent-go-1.0.0-1.x86_64.rpm
nm-agent register --server https://<manager-host>:8460 --token <token> --ca-sha256 <fingerprint>
systemctl enable --now navin-manager-agent

Sur aarch64, utilisez navin-manager-agent-go-1.0.0-1.aarch64.rpm ; sur Ubuntu, apt install ./navin-manager-agent-go_1.0.0_amd64.deb (ou _arm64.deb). Sur un hôte sans gestionnaire de paquets, décompressez le tar.gz à la racine : tar -xzf navin-manager-agent-go-1.0.0-linux-x86_64.tar.gz -C /, puis systemctl daemon-reload.

Hors ligne

L'agent n'a besoin de rien sur Internet : les paquets contiennent tout le programme. Pour le livrer dans le bundle hors ligne, construisez les paquets puis donnez leur répertoire au constructeur de bundle :

navin-manager/packaging/build-packages.sh agent-go
python3 navin-manager/packaging/offline/build-bundle.py --agent-dir navin-manager/packaging/dist/agent-go ...

build-packages.sh agent-go exige Go 1.26 ou plus récent (NM_GO choisit le binaire) et le cache de modules ou un proxy Go de la banque (GOPROXY) ; il construit x86_64 et aarch64 (NM_AGENT_GO_ARCHES), vérifie que chaque binaire est lié statiquement et écrit SHA256SUMS. Les composants tiers et leurs licences sont listés dans /usr/share/doc/navin-manager-agent/THIRD_PARTY_LICENSES.

Commandes

nm-agent --version
nm-agent [--config FILE] [--lang en|fr] register --server URL --token TOKEN --ca-sha256 HEX [--ca-file FILE]
nm-agent [--config FILE] run
nm-agent [--config FILE] status
nm-agent [--config FILE] facts

Les messages suivent --lang, sinon LC_ALL ou LANG. Codes de sortie : 0 succès, 1 status d'un hôte non enregistré, 2 erreur (configuration invalide, enregistrement refusé, mauvaise empreinte de l'autorité : rien n'est stocké).

Configuration

/etc/navin-manager-agent/agent.json reprend les clés de l'agent Python : server_url, agent_url, state_dir, log_dir, fs_prefix, allowed_roots, allowed_commands, service_driver (systemd ou process), heartbeat_interval_s, poll_wait_s, health_interval_s, stop_timeout_s, log_level, ca_file. Le journal est écrit dans /var/log/navin-manager-agent/agent.log (20 Mo, 5 sauvegardes).

Chaque clé, son type et sa valeur par défaut figurent dans la référence de configuration de l'agent. L'installation sur chaque système, la sécurité, l'exploitation courante et le dépannage figurent dans la rubrique Agent Navin.