YaST ou configuration directe sur SUSE : ce qui fonctionne encore en ligne de commande, et la répartition entre wicked et NetworkManager

Ce que c'est

YaST est l'outil de configuration système de SUSE ; sur un hôte SLES 15 SP6 sans interface graphique, il fonctionne dans une interface texte ncurses et pas seulement en mode GUI. sudo yast2 lance l'interface texte complète à menus ; yast --list (ou yast -l) affiche les noms de tous les modules installés pour le frontal YaST courant ; sudo yast <module_name> démarre directement l'interface interactive d'un module. Pour les scripts, les modules disposant d'une prise en charge en ligne de commande acceptent des sous-commandes, que l'on obtient avec sudo yast <module_name> help. Tous les modules ne proposent pas de ligne de commande, et l'ensemble des modules diffère entre les versions ncurses et GUI : un module présent dans l'une peut être absent de l'autre.

Sous la plupart des modules YaST se trouvent les mêmes fichiers qu'un administrateur pourrait modifier directement : /etc/sysconfig/network/ifcfg-* pour les interfaces, /etc/zypp/repos.d/*.repo pour les dépôts, etc. Pour les agents, cela signifie qu'il existe deux voies tout aussi valables pour un même paramètre : passer par la forme non interactive d'un module YaST, ou modifier le fichier sous-jacent puis l'appliquer avec la commande de rechargement appropriée (wicked ifreload, systemctl reload sshd, etc.).

Pourquoi c'est important

La documentation de SUSE indique explicitement que NetworkManager « is only supported by SUSE for desktop workloads with SLED or the Workstation extension » (n'est pris en charge par SUSE que pour les charges de travail de poste de travail avec SLED ou l'extension Workstation), et que toutes les certifications serveur sont réalisées avec wicked comme outil de configuration réseau. Autrement dit, un déploiement certifié suppose que wicked gère la configuration des interfaces, et passer à NetworkManager sur un serveur peut invalider cette certification. Modifier à la main les fichiers ifcfg-* pendant que wicked est actif est compatible ; le faire pendant que NetworkManager contrôle la même interface ne l'est pas, car NetworkManager conserve ses propres profils de connexion.

Comment l'appliquer

• Vérifier quel service gère le réseau avant toute modification : systemctl is-active NetworkManager et systemctl is-active wicked ; un seul des deux doit être le service réseau actif.
• Pour basculer, utiliser le module YaST Network Settings (onglet Global Options, champ « Network Setup Method ») : choisir « User Controlled with NetworkManager » ou « Controlled by wicked ». Changer de service réseau peut interrompre la connectivité ; il faut donc le faire depuis une console plutôt que par une session SSH dépendant de l'interface en cours de reconfiguration.
• Pour une configuration scriptée sur un serveur, privilégier la modification de /etc/sysconfig/network/ifcfg-* sous wicked, ce qui correspond à la base sur laquelle SUSE teste ses images serveur.
• Exécuter yast --list dans une nouvelle session pour découvrir ce qui est réellement disponible avant de supposer qu'un module existe.

Pièges

• Installer NetworkManager sur une image serveur « parce que c'est plus familier » sans vérifier qu'aucun autre outil (zones firewalld liées aux noms d'interface wicked, supervision) ne suppose la présence de wicked.
• Supposer que chaque paramètre a un équivalent YaST en ligne de commande ; lorsque ce n'est pas le cas, modifier directement le fichier sous-jacent et recharger le service concerné.
• Appliquer ces indications à la génération 16 : SLES 16 et openSUSE Leap 16 ne livrent plus wicked et remplacent YaST par d'autres outils d'administration. Cet article porte donc sur la branche 15 ; à vérifier sur la version utilisée.