Cours Ubuntu 26.04 / Distinguer Netplan, NetworkManager et systemd-networkd

Netplan décrit la configuration réseau et la transmet à un moteur d’application, appelé renderer, comme NetworkManager ou systemd-networkd. Avant de modifier Ubuntu, identifiez pour chaque interface le service qui la gère réellement et la source persistante de sa configuration ; le nom de l’image Server ou Desktop ne suffit pas.

Distinguer configuration, gestion des interfaces et résolution DNS

YAML est un format de données textuel dont l’indentation organise les propriétés. Une adresse Internet Protocol, ou IP, permet d’identifier une interface sur un réseau ; le Domain Name System, ou DNS, sert à résoudre des noms. Avoir une adresse et une route ne prouve pas qu’un nom se résout correctement.

L’explication Ubuntu de Netplan présente la relation entre configuration et moteurs. Un système mis à niveau, une image cloud et une VM personnalisée peuvent s’écarter des habitudes de l’installation initiale. Deux moteurs actifs ne prouvent pas un conflit s’ils gèrent des interfaces différentes.

Relever les interfaces, adresses et routes sans appliquer de changement

Utilisez une console ou une session existante sur le serveur que vous souhaitez inventorier. Conservez ses données réseau dans vos notes d’administration, sans publier des détails internes inutiles. Commencez par les informations du noyau :

ip -br link
ip -br address
ip route
ip -6 route
systemctl is-active NetworkManager systemd-networkd systemd-resolved

La première sortie distingue les interfaces et leur état de liaison ; la deuxième présente leurs adresses. Les commandes route décrivent séparément IPv4 et IPv6. Notez aussi les interfaces sans adresse et les routes par défaut, sans supposer qu’il n’en existe qu’une.

is-active indique l’état des unités, pas la propriété de chaque interface. Son code de sortie peut être non nul lorsqu’un des services est inactif : lisez chaque ligne. N’activez pas un moteur absent ou arrêté uniquement pour obtenir davantage de colonnes de diagnostic.

Interroger le moteur déjà actif pour l’interface visée

Si NetworkManager est déjà actif, consultez ses périphériques et ses profils actifs :

nmcli device status
nmcli connection show --active

Rapprochez DEVICE, STATE et CONNECTION du nom d’interface relevé avec ip. Un profil de connexion porte un nom distinct du périphérique ; deux profils peuvent concerner le même matériel à des moments différents. Le manuel nmcli distingue consultation, activation et modification. Ici, n’utilisez ni connection up ni connection modify.

Si systemd-networkd est déjà actif, consultez sa vue :

networkctl list
networkctl status --all

Dans cette sortie, unmanaged signifie que networkd ne prend pas en charge le lien. Cela peut être normal si NetworkManager le gère. La documentation de networkctl distingue l’état opérationnel du lien et l’état de sa configuration ; routable ne garantit pas qu’un service extérieur précis soit accessible.

Sur un système où networkd est déjà actif et dont vous acceptez cette inspection, vous pouvez compléter avec :

sudo netplan status --all

Ce n’est pas une commande à lancer indistinctement sur tous les systèmes pour une consultation sans effet. La documentation de netplan status indique sa dépendance à networkd et sa tentative de démarrage lorsque celui-ci n’est pas masqué. Sur un hôte géré par NetworkManager avec networkd arrêté, restez aux informations du noyau, à nmcli et à la lecture des fichiers plutôt que de changer cet état.

Retrouver la source YAML et comprendre sa fusion

Inventoriez les définitions présentes sans présumer qu’un seul fichier /etc/netplan fait autorité :

for netplan_dir in /lib/netplan /etc/netplan /run/netplan; do
    if [ -d "$netplan_dir" ]; then
        sudo find "$netplan_dir" -maxdepth 1 -type f -name '*.yaml' -print
    fi
done
sudo netplan get

netplan get renvoie la configuration fusionnée sur disque, pas nécessairement l’état actuellement appliqué. Une modification peut avoir été enregistrée sans être appliquée ; inversement, un changement temporaire peut apparaître dans ip sans exister dans le YAML. Le manuel de netplan get permet aussi de demander une sous-arborescence au lieu de tout afficher.

Le YAML complet peut contenir des mots de passe Wi-Fi, des clés ou d’autres valeurs confidentielles. Consultez-le localement et masquez les secrets avant toute aide publique. Évitez également l’option nmcli --show-secrets pour un simple relevé d’état.

Pour un même nom de fichier, /run/netplan masque /etc/netplan, qui masque /lib/netplan. Avec des noms différents, l’ordre lexicographique s’applique à l’ensemble : un fichier situé dans un autre répertoire peut encore apporter une définition plus tardive. Les valeurs simples peuvent être remplacées, tandis que des listes sont concaténées. Ajouter un fichier tardif n’efface donc pas nécessairement une liste d’adresses ou de routes préexistante.

Les règles de fusion et de génération Netplan expliquent ces différences. Lisez le résultat fusionné et les fichiers d’origine ensemble avant de choisir une modification.

Séparer les fichiers produits de leur véritable gestionnaire

Les fichiers de moteur créés sous /run sont des résultats générés, qui peuvent être remplacés à la régénération ou au redémarrage. Modifier un fichier .network généré sans retrouver sa source risque de produire une correction éphémère. Le chemin affiché par le moteur aide à retrouver la chaîne de génération ; il ne constitue pas automatiquement l’endroit à éditer.

Dans le YAML, renderer peut être défini globalement ou pour un type ou une interface. Ses valeurs sont networkd et NetworkManager, avec une casse précise pour cette dernière. Ne déduisez pas le propriétaire d’un seul renderer global si une définition plus spécifique intervient.

Sur Desktop, l’intégration NetworkManager et Netplan peut faire persister des profils sous forme de YAML. La présence d’un profil NetworkManager n’implique donc pas toujours un fichier traditionnel à modifier séparément. Identifiez l’intégration réellement utilisée avant d’éditer plusieurs couches à la fois.

Un fichier nommé 50-cloud-init.yaml ou son en-tête signale qu’il faut examiner la provenance. cloud-init peut produire la configuration réseau à partir des données du fournisseur ou de la configuration système. Une automatisation d’infrastructure peut aussi réécrire les paramètres.

Si une valeur revient après un démarrage, cherchez le gestionnaire qui la produit, ses journaux et la procédure du fournisseur. N’effacez pas le YAML et ne désactivez pas cloud-init sans connaître l’autre moyen de configurer le réseau et de retrouver l’accès console.

Contrôler le DNS et fixer une seule méthode de modification

Lorsque systemd-resolved est déjà actif, relevez ses paramètres sans changer les serveurs :

resolvectl status

Le manuel resolvectl décrit les paramètres DNS globaux et par lien. Identifiez le serveur DNS et les domaines de recherche de l’interface. Si resolved n’est pas utilisé, examinez le résolveur réellement choisi et la provenance de /etc/resolv.conf ; ne forcez pas ce service uniquement pour reproduire la commande.

Consignez pour chaque interface : nom et adresse matérielle, adresses IP, routes, moteur actif, profil ou fichier source, éventuel générateur externe, DNS et accès de secours. Par exemple, « interface du réseau interne gérée par networkd, définition dans un YAML administré localement, sans route par défaut » est plus exploitable que « réseau géré par Ubuntu ».

Le laboratoire Server peut ensuite utiliser un YAML Netplan rendu par networkd si cet état a été confirmé. Sur une interface réellement gérée par NetworkManager ou un fournisseur cloud, conservez son parcours de gestion. Cet inventaire ne demande ni netplan apply, ni changement de renderer, ni redémarrage des services ; il prépare un changement ciblé avec sauvegarde et console de récupération.