C'est pas vraiment le même cas d'usage imho... Il faudrait qu'il connaissent les deux... ici ifupdn pour les serveurs (simple, stable, complet). Toute "la pieuvre" y compris resolvd est jarretée (sauf systemd qui lui est utile) et on installe ifupdown. Pendant longtemps, systemd-networkd n'était pas sec et (plus trop cherché ces dernières années car OSEF), jamais réussi à réimplémenter pointopoint dans systemd-networkd (vers 2016, ça date :) Enfin, sur les servs, on fait tout à base de commande ip dans des scripts et interface est quasi vide. systemd-networkd (dynamique) pour les portables qui gèrent de l'eth, du bt, du wan, du wlan. c'est confort. Mais peut-être "confusionnant" pour des débutants. -- Stéphane Rivière Ile d'Oléron - France

Plutôt d'accord sur la diversité des techniques, ça leur apprend à être agnostiques : ils retrouvent leurs petits en lisant les clés de configuration dans un système ou dans l'autre. Plus largement je pense qu'on doit avoir un biais pédagogique du fait qu'on a tous plus ou moins grandi et vu croître les réseaux. Nous savons à quel point ça peut devenir complexe, et paradoxalement nous sommes tellement entrainés, ça fait partie de notre quotidien et nous ne nous rendons pas compte que les notions peuvent être si obscures à certain(e)s. Leur courbe d'apprentissage est raide désormais. Et leur investissement est essentiel, sinon ça en fait des pousse-bouton d'IA. Mais je pense qu'aujourd'hui, il faut effectivement les bousculer un peu car on n'a pas le choix ! L'informatique est devenu trop complexe et les techniques trop vastes pour le temps imparti à la formation. C'était déjà un métier de passionné il y a deux décennies, je crois que ça s'est largement aggravé. C'est en tout cas le constat que je fais avec mes étudiants : on voit les passionnés qui tentent des trucs et qui ont expérimenté (et donc besoin de réapprendre correctement les bases), et ceux qui sont partis d'une page vierge et pour qui c'est (très) difficile ! Je prends le parti de les confronter à la complexité et à la multiplicité des techniques rapidement pour qu'ils prennent conscience que ce n'est pas juste "taper sur un clavier" ou "prompter l'IA". Et aussi aux choix ! (ifupdown, networkd, nm, netplan, et autres pour notre sujet initial) Mais je constate aussi qu'il faut réadapter à la marge le niveau à chaque génération, et je le crains, tomber à un seuil infranchissable où il faudra expliquer à certain(e)s qu'ils ne pourront pas aller plus loin sans ces bases solides Le 01/11/2026 à 11:58, Jean Marc Pouchoulon par FRsAG a écrit :

J utilise netplan aussi pour les vm étudiantes. Mais l interaction de netplan avec systemd c est encore une autre histoire… La difficulté est que les étudiants embrassent l ensemble de ces technologies pour des apprentissages avec peu d’heures en admin système. Pour les pros pour ces mécanismes sont intégrés dans leurs circuits et ils ne comprennent pas qu il y a une progression de centaines d heures avant d’atteindre leur niveau quotidien d’admin système. J ai souvent des remarques sur l absence de formation sur le bonding en BUT réseaux . Mais j ai 30 heures de formation en tout sur l admin système en première année . Le bonding devient un détail vis à vis de systemd et j’ai la chance d’avoir plusieurs cartes reseaux par serveur mais c est en seconde année. Pour des pros en reconversion je suppose que la motivation sera plus forte et les heures plus orientées. pour conclure systemd et ses commandes comme resolvectl est central dans l apprentissage Linux mais les étudiants volent à 10000 pieds et ne voit pas les détails comme les pros les voient. J ai un peu divergé du sujet initial mais je pense que systemd-resolved est un bon exemple pour l apprentissage de systemd donc je fait un tp sur systemd et un autre sur la résolution dns. Mais sur debian if up est quand même la réf de beaucoup. C est bien que les étudiants voient les solutions mais il est illusoire de penser qu’en si peu de temps ils aient sauf exceptions ( c est cela que j’embaucherais ) un schéma d ensemble. Ca vient mais souvent en troisième année.

...

Le 1 nov. 2026 à 09:51, Nicolas Cuissard par FRsAG <frsag@frsag.org> a écrit :



...

Le 31/10/2026 à 15:44, Christophe De Natale – CDN Info par FRsAG a écrit : Bonjour à toutes et à tous, Je suis formateur et j'enseigne l'administration GNU/Linux sous Debian 13 à des adultes en reconversion, futurs techniciens systèmes et réseaux (titre pro TSSR). La plupart sont de vrais débutants. Je prépare la séance où ils installent leur premier serveur sans interface graphique et lui donnent une adresse IP fixe. Je me questionne sur le choix de l'outil réseau : - ifupdown (/etc/network/interfaces) : c'est ce que l'installateur de Debian 13 met en place ; - systemd-networkd (avec systemd-resolved) : plus actuel, mais il faut d'abord retirer la carte d'ifupdown, installer systemd-resolved et activer le service, ce qui ajoute des étapes pour des débutants. Mes questions : 1. Sur vos serveurs Debian en production, qu'utilisez-vous aujourd'hui, et que vous attendez-vous à rencontrer dans les prochaines années ? 2. À votre avis, vaut-il mieux former d'abord sur ifupdown, ce que les stagiaires trouveront sur une installation par défaut, ou les orienter directement vers systemd-networkd ? 3. Si systemd-networkd : quels pièges signaleriez-vous pour la bascule sur Debian 13, en particulier pour la gestion de /etc/resolv.conf ? 4. Sait-on déjà ce qui est prévu pour Debian 14 (forky) ? Sur nos serveurs on a mis Netplan partout, ça permet justement de s'affranchir d'une syntaxe spécifique à un gestionnaire de config réseau. Pour une formation débutants ça me paraît beaucoup plus didactique que de se lancer directement dans la conf ifupdown ou autre.

C'est particulière utile pour les serveurs physiques avec bonding + vlans + LACP + IPv6 où la conf Netplan est quand même hyper épurée par rapport à du NetworkManager.

-- Nicolas C.

_______________________________________________ Liste de diffusion du French Sysadmin Group https://www.frsag.org/

---

Liste de diffusion du French Sysadmin Group https://www.frsag.org/

Hello,

Aujourd'hui systemd veut tout faire, on se retrouve finalement comme devant un windows

Certaines distros ont valsé systemd: En mode non serveur il y a AntiX... Faut voir si c'est pareil pour d'autres distros Debian plus serverque client... -- --- Sébastien WILLEMIJNS

Bonjour Je développe un OS gratuit dédié à l'apprentissage du réseau/système/cybersecurité : LiveRaizo (https://sourceforge.net/projects/live-raizo/) [voilà pour la petite pub]. J'y utilise ifupdown et les scripts de configuration du réseau (fast-ip) sont basés dessus. Mais récemment, je me suis posé la même question : dois je migrer vers systemd-network ? je voulais préparer un TP sur VRF (Virtual Routing and Forwarding) En regardant, on voit que ifupdown n'est plus trop maintenu, qu'il y a ifupdown2 et ifupdown-ng.Et ces 3 solutions ne semblaient pas très adaptés. Pour mon problème, l'IA me conseillait d'utiliser "systemd-network". Je trouve quand même le fichier de configuration pour "systemd-network" plus long à appréhender que celui de /etc/network/interfaces. Lors d'un TP d'introduction au réseau, cela peut être pénalisant.... Et je n'ai pas vu de fichier officiel permettant de dire : "commencer par faire un "cp" avec d'éditer". Donc, dans un contexte d'apprentissage, j'hésite A la remarque de certain, c'est vrai que ce qui compte c'est de comprendre la théorie du réseau, et qu'ensuite, il suffit de l'adapter au système devant soit. Mais les débutants ne fonctionnent pas ainsi : Modifiez juste un détail et ils n'auront pas le réflexe d'utiliser ce que vous avez passé 4 heures à leur faire pratiquer. Et quoi qu'on en dise : le choix d'une technologie est important (malgré les guerres de clocher). Faite un mauvais choix et vous avez en environnement qui s'appuie sur une technologie qui risque de ne plus être présente : cela veut dire "scripts/config" à ré-écrire, et en attendant des serveurs bloquaient dans une vieille distribution avec les risques cyber qui en découlent... Cordialement David Dr David ANSART Formateur en Informatique : Réseau Système Cybersécurité Développement C/C++ https://github.com/Raizo62 david.ansart@seineetmarne.cci.fr 06 61 89 17 62 CFA UTEC INT<https://www.utec77.fr/> (https://www.utec77.fr<https://www.utec77.fr/>) 6 Boulevard Olof Palme CS 60150 Émerainville 77436 Marne-la-Vallée CEDEX 2 [cid:ae53d12b-dfe3-478f-b936-e15576a97c08]<https://www.utec77.fr/> [cid:df68e8b5-60c2-47f2-9231-27c784032bc0] <https://www.linkedin.com/school/utec77-ecole/?viewAsMember=true> [Une image contenant noir, Graphique, cercle, noir et blanc Le contenu généré par l’IA peut être incorrect.] [cid:0c609011-2dfc-4463-9353-c73c2d727ecf] <https://www.facebook.com/utec77.formations?locale=fr_FR> [cid:cba68366-b349-4168-ba5d-d4a4ed9c222e] <http://youtube.com/@cfautec7756> [Une image contenant texte, capture d’écran, Police, logo Le contenu généré par l’IA peut être incorrect.]<https://www.utec77.fr/> ________________________________ De : Stéphane Rivière par FRsAG <frsag@frsag.org> Envoyé : lundi 2 novembre 2026 09:00 À : frsag@frsag.org <frsag@frsag.org> Objet : [FRsAG] Re: [MISC]Debian 13 serveur : enseigner ifupdown ou systemd-networkd à des débutants ? Attention: Ce message provient de l’Extérieur de l’entreprise. Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe sans avoir vérifié l’expéditeur. Hello Jérôme et Al ! +1 sur ton mail. Le principe (pour les servs) : rester KISS. Y'a pas de négo. C'est pour ça qu'ici on est en ifupdn coté réseau. Là où j'ai du mal, c'est que je ne lis pas trop dans cette thread le distingo entre systemd (lui seul), qui est un progrès essentiel et (pour du serv) toute la merde qui gravite autour (qui lui vaut le nom de pieuvre). C'est ainsi que sur nos serveurs, on vire tout sauf systemd.

Pour troller, je dirais que rien ne sert de faire du systemd à fond, il devrait un jour ou l'autre disparaître, c'est du C++, hérésie !!! Son fork rust ne devrait pas tarder ...

:)))) Les rustacéens ont décrété : le monde doit être réécrit en Rust. Au fond de la classe, Toto a posé une question : pourquoi, dans sa runtime, les conteneurs Rust sont codés en Unsafe ? ;> -- Stéphane Rivière Ile d'Oléron - France _______________________________________________ Liste de diffusion du French Sysadmin Group https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.frsag.org%2F&data=05%7C02%7Cdavid.ansart%40seineetmarne.cci.fr%7Ca4d98e18b45748364fd608df38b773c0%7C07f2d2f9b1c947e8b00ca5903cc61e74%7C1%7C0%7C639292032703441518%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=xMcGsvu4bbDNhl82t5UJfMjr9khbYmJQNU2TsYSghQU%3D&reserved=0<https://www.frsag.org/> Ce message et toutes les pièces jointes sont confidentiels et/ou couverts par le secret professionnel et transmis à l'intention exclusive de ses destinataires. Toute modification, édition, utilisation ou diffusion non autorisée est interdite. Si vous avez reçu ce message par erreur, merci d'en informer son émetteur ou le signaler à cpdp@cci-paris-idf.fr. La CCI Paris-IdF décline toute responsabilité au titre de ce message s'il a été altéré, déformé, falsifié ou encore édité ou diffusé sans autorisation. Si l'objet de ce message est indiqué comme "privé", son contenu est sous la seule responsabilité de son auteur.

En fait, j'ai eu le raisonnement suivant pour ma conversion à networkd dans Debian : il est latent, il fait partie du paquet systemd de base, il n'a pas été sorti dans un paquet externe comme peuvent l'être resolved et timesyncd. Donc je me suis dit "bon, il est là, on va voir ce qu'il vaut". C'est parti de là. Dans l'intervalle, j'ai eu le même problème côté authentification "complexe" : j'ai trainé des pieds pendant longtemps en utilisant des paquets KISS (nslcd, nscd, quelques libpam). Bon ça marchotait pas trop mal... Et puis un premier truc a arrêté d'être maintenu, puis un autre. Donc j'ai fini par me mettre malgret(*) moi à SSSD. Bilan : il m'a fait balayer tout un tas de trucs "mal" (comprendre "peu", et aussi "peu utilisé / audité" d'ailleurs) ou qui baignaient dans leurs jus depuis 4 ou 5 majeures de Debian. Donc peut-être plus lourd, mais pour une infra qui doit passer à l'échelle et doit s'adapter à des situations un peu plus "à la con" que la moyenne, c'est plus confortable, car plus prévisible dans son principe... et dans ses pannes ! Pour le sujet initial, je reconnais que pour les cas simples, un ifupdown suffit bien largement. Et qu'il a assez peu de raison d'évoluer à vrai dire. Pour élargir un poil ma réflexion, je me dis que, si un jour je ne veux plus de systemd, je pense qu'il faudra que j'aille directement sur une BSD. Et j'y retrouverai du KISS bien à l'ancienne ! Dans tous les échanges que j'ai pu lire (et qui sont intéressants, et je tiens à vous en remercier, c'est éclairant !) je remarque qu'à la fin des fins, nous avons chacun nos habitudes, nos expériences, et que d'une certaine manière il est pas évident de trouver un consensus tant les possibilités sont importantes. C'est à la fois le plus bel avantage et le pire inconvénient de nos pingouins^Wmanchots ! (Réplique de Matrix : "le problème, c'est le choix !") J'ai une crainte pour netplan (et là je lance une bouée pour du retex) : j'ai peur qu'il fasse comme upstart et qu'il finisse par être abandonné au profit d'un autre truc qui aura plus la "hype" (ce qui est arrivé à feu wicd quand on cherchait à esquiver la lourdeur du network-manager) (*) - Ce midi on mange du malgré de canard - Euh... on dit "magret" ! - Nan !! Le canard voulait pas !! Le 02/11/2026 à 12:47, Stéphane Rivière par FRsAG a écrit :

...

Je trouve quand même le fichier de configuration pour "systemd-network" plus long à appréhender que celui de /etc/network/interfaces.

Quand j'ai commencé à regarder/tester la chose il y a ~ 10 ans, j'ai eu la même réaction... me disant "avant je n'avais qu'un fichier et maintenant, j'en ai (potentiellement) plusieurs".

Depuis, j'ai modéré ça autrement : le fichier interfaces est quasi vide (hormis l'interface de base du serveur/hyperviseur).

Tout est dans un script unique (start/stop/restart/status), contrôle par systemd, et comprenant les VPN, le firewalling par interface, les routes, les bridges, etc.

Ce script étant généré automatiquement par le gestionnaire de cluster.

...

A la remarque de certain, c'est vrai que ce qui compte c'est de comprendre la théorie du réseau, et qu'ensuite, il suffit de l'adapter au système devant soit.

+1

...

Mais les débutants ne fonctionnent pas ainsi : Modifiez juste un détail et ils n'auront pas le réflexe d'utiliser ce que vous avez passé 4 heures à leur faire pratiquer.

+1000

Pratique d'abord, compréhension fine ensuite et enfin "grande théorie" quand les concepts de base et les mécanismes sont compris et testés.

...

Et quoi qu'on en dise : le choix d'une technologie est important (malgré les guerres de clocher). Faite un mauvais choix et vous avez en environnement qui s'appuie sur une technologie qui risque de ne plus être présente : cela veut dire "scripts/config" à ré-écrire, et en attendant des serveurs bloquaient dans une vieille distribution avec les risques cyber qui en découlent...

C'est un peut quand on a abandonné les commandes classiques pour la commande "ip".

À force (de pratique, de scaling), préférer le script au fichier de config s'impose (au moins chez nous)... Je ne sais pas si c'est un bien ou pas mais c'est devenu naturel...

-- Stéphane Rivière Ile d'Oléron - France

_______________________________________________ Liste de diffusion du French Sysadmin Group https://www.frsag.org/

Le 02/11/2026 à 12:23, Dominique Rousseau par FRsAG a écrit : Bonjour à tous, Merci pour vos réponses, toutes constructives : elles m'ont aidé à trancher, et j'ai appris pas mal de choses en vous lisant. Le choix de Debian car c'est mon os depuis plusieurs années (les autres familles ont été présentées lors de l'introduction en précisant qu'on pouvait les croiser également un jour ou l'autre). J'avais oublié de préciser le contexte. Mes stagiaires sont des adultes en reconversion, pour la plupart débutants qui ont entre 20 et 50 ans, une vie de famille, et le temps est compté : une demi-journée dure 3 h 30, mais une fois la pause et l'émargement retirés (plus sur papier, un qr-code à flasher dans deux outils différents deux fois par jour), il reste 3 h de cours effectif. J'ai construit mes cours autour d'un fil rouge : une petite entreprise fictive (humain.internal), les stagiaires installent d'abord le poste d'accueil, puis le serveur. Chaque séance prolonge la précédente : - *2 journées* de GNU/Linux côté poste, sous Debian 13 avec Xfce, donc avec NetworkManager (aucunes manips en interface graphique, enfin c'était la consigne :D ), donc découverte du terminal à ce moment et certains ont eu besoin d'ouvrir le gestionnaire de fichiers afin de constater visuellement le résultat des commandes de création de répertoires, c'était fun mais ils se débrouillent très bien. - *7 journées* côté serveur, soit 14 demi-journées :   1. installation de Debian sans interface graphique et adresse IP fixe   2. administration à distance (SSH, scp, comptes administrateurs)   3. services, processus et journaux   4. disques et systèmes de fichiers   5. LVM   6. tâches planifiées (cron, logrotate)   7. SSH par clés et durcissement   8. DHCP et synchronisation de l'heure   9. DNS avec BIND, zone directe   10. DNS, zone inverse et dépannage   11. serveur web Apache   12. pile LAMP et déploiement d'une application (dolibarr comme cela on reste dans le contexte)   13. partage Samba avec un poste Windows   14. mise en situation de synthèse (diagnostic d'incident) Vu ce temps limité, j'ai choisi de rester sur ce que Debian fournit par défaut : ifupdown pour le serveur, en présentant systemd-networkd, netplan et NetworkManager pour qu'ils sachent que ces outils existent et où trouver leur documentation. L'essentiel reste qu'ils comprennent ce qu'ils configurent et sachent localiser une panne. Encore merci à chacun pour le temps consacré à me répondre, c'est très instructif car chaque réponse correspond aussi à des besoins et/ou préférences. Bonne fin de journée. -- Christophe De Natale