Salut,
J'utilise une Debian Buster avec systemd-networkd activé pour la configuration des adresses IP. Le serveur est une instance du public cloud d'OVH avec une adresse IP DHCP assignée d'office à l'instance. Je rajoute à cette adresse IP principale et à la même interface (ens3) 2 autres IP statiques failover. Je me retrouve donc normalement avec une adresse IP principale et 2 complémentaires. Dans un fonctionnement normal, Linux utilise l'adresse principale pour toutes les connexions sortantes. Les adresses supplémentaires failover sont utilisées uniquement en connexions entrantes quand l'adresse failover pointe sur ce serveur.
Or je viens de rebooter aujourd'hui le serveur après une mise à jour noyau et il semblerait que l'adresse principale (par défaut) est une des adresses failover et non pas l'adresse DHCP associée à l'instance. Cela a pour conséquence de limiter les connexions sortantes de la machine car les adresses IP failover configurées pointent ailleurs sur un autre serveur.
Du coup, comment dire à Linux que l'adresse principale est bien l'ip DHCP et pas les autres failover ? Je comprends que je pourrais mettre l'adresse IP DHCP en statique, mais je préfère l'éviter dans l'immédiat.
Quelques éléments de ma config...
$ cat /etc/systemd/network/50-default.network [Match] Name=ens3 [Network] DHCP=ipv4 [Address] Address=1.2.3.5/32 [Address] Address=1.2.3.4/32
$ ip a ... 2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether fa:16:3e:37:8c:8f brd ff:ff:ff:ff:ff:ff inet 1.2.3.5/32 scope global ens3 -> IP failover statique valid_lft forever preferred_lft forever inet 1.2.3.4/32 scope global ens3 -> IP failover statique valid_lft forever preferred_lft forever inet 2.3.4.5/32 scope global dynamic ens3 -> IP DHCP de l'instance valid_lft 83012sec preferred_lft 83012sec inet6 fe80::f816:3eff:fe37:8c8f/64 scope link valid_lft forever preferred_lft forever
$ ifconfig ens3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 1.2.3.5 netmask 255.255.255.255 broadcast 0.0.0.0 inet6 fe80::f816:3eff:fe37:8c8f prefixlen 64 scopeid 0x20<link> ether fa:16:3e:37:8c:8f txqueuelen 1000 (Ethernet) RX packets 10084 bytes 1125563 (1.0 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 31226 bytes 2859838 (2.7 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Je n'utilise pas les IP FO de la même manière que toi,
Mais j'aurais tendance a penser qu'il vaut mieux coller l'IP FO sur ens3:0 plutôt que sur ens3 afin de pouvoir faire ifup ens3:0 ou ifdown ens3:0
Kévin
-----Message d'origine----- De : FRsAG frsag-bounces@frsag.org De la part de Artur Envoyé : mercredi 25 septembre 2019 11:37 À : French SysAdmin Group frsag@frsag.org Objet : [FRsAG] @IP principale "par défaut" dans Debian Buster
Salut,
J'utilise une Debian Buster avec systemd-networkd activé pour la configuration des adresses IP. Le serveur est une instance du public cloud d'OVH avec une adresse IP DHCP assignée d'office à l'instance. Je rajoute à cette adresse IP principale et à la même interface (ens3) 2 autres IP statiques failover. Je me retrouve donc normalement avec une adresse IP principale et 2 complémentaires. Dans un fonctionnement normal, Linux utilise l'adresse principale pour toutes les connexions sortantes. Les adresses supplémentaires failover sont utilisées uniquement en connexions entrantes quand l'adresse failover pointe sur ce serveur.
Or je viens de rebooter aujourd'hui le serveur après une mise à jour noyau et il semblerait que l'adresse principale (par défaut) est une des adresses failover et non pas l'adresse DHCP associée à l'instance. Cela a pour conséquence de limiter les connexions sortantes de la machine car les adresses IP failover configurées pointent ailleurs sur un autre serveur.
Du coup, comment dire à Linux que l'adresse principale est bien l'ip DHCP et pas les autres failover ? Je comprends que je pourrais mettre l'adresse IP DHCP en statique, mais je préfère l'éviter dans l'immédiat.
Quelques éléments de ma config...
$ cat /etc/systemd/network/50-default.network [Match] Name=ens3 [Network] DHCP=ipv4 [Address] Address=1.2.3.5/32 [Address] Address=1.2.3.4/32
$ ip a ... 2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether fa:16:3e:37:8c:8f brd ff:ff:ff:ff:ff:ff inet 1.2.3.5/32 scope global ens3 -> IP failover statique valid_lft forever preferred_lft forever inet 1.2.3.4/32 scope global ens3 -> IP failover statique valid_lft forever preferred_lft forever inet 2.3.4.5/32 scope global dynamic ens3 -> IP DHCP de l'instance valid_lft 83012sec preferred_lft 83012sec inet6 fe80::f816:3eff:fe37:8c8f/64 scope link valid_lft forever preferred_lft forever
$ ifconfig ens3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 1.2.3.5 netmask 255.255.255.255 broadcast 0.0.0.0 inet6 fe80::f816:3eff:fe37:8c8f prefixlen 64 scopeid 0x20<link> ether fa:16:3e:37:8c:8f txqueuelen 1000 (Ethernet) RX packets 10084 bytes 1125563 (1.0 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 31226 bytes 2859838 (2.7 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Je comprends, mais dans ce cas-là, je suppose que tu n'utilises pas systemd-networkd. C'est l'approche "old school", non ?
Le 25/09/2019 à 11:47, Kevin CHAILLY | Service Technique a écrit :
Je n'utilise pas les IP FO de la même manière que toi,
Mais j'aurais tendance a penser qu'il vaut mieux coller l'IP FO sur ens3:0 plutôt que sur ens3 afin de pouvoir faire ifup ens3:0 ou ifdown ens3:0
Kévin
Tu peux il faut faire
[Address] Label=ens3:0 Address=1.2.3.4/5
-----Message d'origine----- De : Artur frsag@pydo.org Envoyé : mercredi 25 septembre 2019 12:30 À : Kevin CHAILLY | Service Technique kchailly@adeo-informatique.com; French SysAdmin Group frsag@frsag.org Objet : Re: [FRsAG] @IP principale "par défaut" dans Debian Buster
Je comprends, mais dans ce cas-là, je suppose que tu n'utilises pas systemd-networkd. C'est l'approche "old school", non ?
Le 25/09/2019 à 11:47, Kevin CHAILLY | Service Technique a écrit :
Je n'utilise pas les IP FO de la même manière que toi,
Mais j'aurais tendance a penser qu'il vaut mieux coller l'IP FO sur ens3:0 plutôt que sur ens3 afin de pouvoir faire ifup ens3:0 ou ifdown ens3:0
Kévin
Salut,
Le mer. 25 sept. 2019 à 11:38, Artur frsag@pydo.org a écrit :
Or je viens de rebooter aujourd'hui le serveur après une mise à jour noyau et il semblerait que l'adresse principale (par défaut) est une des adresses failover et non pas l'adresse DHCP associée à l'instance.
Tu as essayé d'ajouter un paramètre "PreferredLifetime" à 0 pour chaque IP failover ?
[Match] Name=ens3 [Network] DHCP=ipv4 [Address] Address=1.2.3.5/32 PreferredLifetime=0 [Address] Address=1.2.3.4/32 PreferredLifetime=0
Bravo ! Cela semble la bonne solution. J'ai lu la doc, mais ça m'a échappé.
Le 25/09/2019 à 12:51, Jonathan Leroy - Inikup via FRsAG a écrit :
Salut,
Le mer. 25 sept. 2019 à 11:38, Artur frsag@pydo.org a écrit :
Or je viens de rebooter aujourd'hui le serveur après une mise à jour noyau et il semblerait que l'adresse principale (par défaut) est une des adresses failover et non pas l'adresse DHCP associée à l'instance.
Tu as essayé d'ajouter un paramètre "PreferredLifetime" à 0 pour chaque IP failover ?
[Match] Name=ens3 [Network] DHCP=ipv4 [Address] Address=1.2.3.5/32 PreferredLifetime=0 [Address] Address=1.2.3.4/32 PreferredLifetime=0
Malheureusement j'arrive à reproduire le problème même avec ce paramétrage... Il faut que je continue à faire des tests.
Le 25/09/2019 à 14:52, Artur a écrit :
Bravo ! Cela semble la bonne solution. J'ai lu la doc, mais ça m'a échappé.
Le 25/09/2019 à 12:51, Jonathan Leroy - Inikup via FRsAG a écrit :
Salut,
Le mer. 25 sept. 2019 à 11:38, Artur frsag@pydo.org a écrit :
Or je viens de rebooter aujourd'hui le serveur après une mise à jour noyau et il semblerait que l'adresse principale (par défaut) est une des adresses failover et non pas l'adresse DHCP associée à l'instance.
Tu as essayé d'ajouter un paramètre "PreferredLifetime" à 0 pour chaque IP failover ?
[Match] Name=ens3 [Network] DHCP=ipv4 [Address] Address=1.2.3.5/32 PreferredLifetime=0 [Address] Address=1.2.3.4/32 PreferredLifetime=0
Sinon, tu peux virer systemd-networkd et installer ifupdown. au moins, ça juste marche. pas de conf bizarroïde, old school certes, mais fonctionnel.
Le 25/09/2019 à 15:43, Artur a écrit :
Malheureusement j'arrive à reproduire le problème même avec ce paramétrage... Il faut que je continue à faire des tests.
Le 25/09/2019 à 14:52, Artur a écrit :
Bravo ! Cela semble la bonne solution. J'ai lu la doc, mais ça m'a échappé.
Le 25/09/2019 à 12:51, Jonathan Leroy - Inikup via FRsAG a écrit :
Salut,
Le mer. 25 sept. 2019 à 11:38, Artur frsag@pydo.org a écrit :
Or je viens de rebooter aujourd'hui le serveur après une mise à jour noyau et il semblerait que l'adresse principale (par défaut) est une des adresses failover et non pas l'adresse DHCP associée à l'instance.
Tu as essayé d'ajouter un paramètre "PreferredLifetime" à 0 pour chaque IP failover ?
[Match] Name=ens3 [Network] DHCP=ipv4 [Address] Address=1.2.3.5/32 PreferredLifetime=0 [Address] Address=1.2.3.4/32 PreferredLifetime=0
Le 25 sept. 2019 à 18:22, Pierre DOLIDON sn4ky@sn4ky.net a écrit :
Sinon, tu peux virer systemd-networkd et installer ifupdown. au moins, ça juste marche. pas de conf bizarroïde, old school certes, mais fonctionnel.
Ouais je voudrais pas enfoncer une porte ouverte, mais quelqu’un peut me résumer les avantages de systemd-networkd ? Parce que ça me semble être une usine à gaz inutile, qui pourrait bien me faire larguer Debian pour autre chose.
Le 25/09/2019 à 18:26, David Ponzone a écrit :
Le 25 sept. 2019 à 18:22, Pierre DOLIDON sn4ky@sn4ky.net a écrit :
Sinon, tu peux virer systemd-networkd et installer ifupdown. au moins, ça juste marche. pas de conf bizarroïde, old school certes, mais fonctionnel.
Ouais je voudrais pas enfoncer une porte ouverte, mais quelqu’un peut me résumer les avantages de systemd-networkd ? Parce que ça me semble être une usine à gaz inutile, qui pourrait bien me faire larguer Debian pour autre chose.
Liste de diffusion du FRsAG http://www.frsag.org/
Ca me semble une mauvaise idée... De ce que j'en sais tu peux sur Debian :
- Utiliser la vieille méthode old-school avec ifupdown
- Utiliser la méthode systemd-networkd (dont je viens de faire la connaissance)
- Utiliser la méthode Network-Manager (et je conseille dans ce cas nmcli et sa command completion par <TAB> pour les interactions plutôt que toucher les fichiers à la "main")
C'est toi qui décide, je vois pas du coup pourquoi tu voudrais quitter....
A+
Le 25 sept. 2019 à 19:35, Jean-Yves LENHOF jean-yves@lenhof.eu.org a écrit :
Ca me semble une mauvaise idée... De ce que j'en sais tu peux sur Debian :
- Utiliser la vieille méthode old-school avec ifupdown
Bonne nouvelle. Et quand tu fais ça, tu retrouves ton bon vieux eth0 à la place de ensX ?
Le 25/09/2019 à 19:47, David Ponzone a écrit :
Le 25 sept. 2019 à 19:35, Jean-Yves LENHOF jean-yves@lenhof.eu.org a écrit :
Ca me semble une mauvaise idée... De ce que j'en sais tu peux sur Debian :
- Utiliser la vieille méthode old-school avec ifupdown
Bonne nouvelle. Et quand tu fais ça, tu retrouves ton bon vieux eth0 à la place de ensX ?
Hello,
Si tu veux vraiment jouer au vieux con (parce que dans 30 secondes je sens que tu vas parler de systemd qui pour moi est quelque chose de plutôt assez bien foutu et évolué même si cela change pas mal nos habitudes et qu'il faut s'y mettre et que l'on a tjs du mal au début avec le changement), cela n'a rien à voir avec ifupdown ou les autres solutions indiquées ici, c'est plus autour de biosdevname que tu dois chercher...
Un petit lien :
https://memo-linux.com/debian-9-retrouver-les-noms-des-interfaces-reseaux-et...
Maintenant j'ai eu par le passé beaucoup de tour avec des eth0 qui se transformaient en eth1 avec certains changements de kernel... du coup c'était pas toujours glop
Avec les nouvelles notations ensxxx et autres, normalement le nom ne change pas entre deux kernels parce qu'il dépend de l'emplacement physique dans la machine (carte réseau built-in ou PCI ne donnent pas les mêmes noms, etc)
Personnellement j'utilise encore ifupdown sur certaines machines et j'utilise sur d'autres Network-Manager, qui a plutôt bien muri (avant la version intégrée ds RHEL/CentOS 7 pour situer) et dont le nmcli est plutôt assez bien foutu une fois que l'on sait qu'il sait faire de la completion... Je découvre systemd-network qui me semble jeune par rapport aux autres solutions, mais je suis intéressé par des commentaires de terrain objectifs, avec des gens qui ont essayé et qui peuvent faire des comparaisons
Cordialement,
JYL
ethX, c'est bien
Ça nous apporte des choses futuristes, comme des noms d'interfaces réseaux predictibles.
On 09/25/2019 08:01 PM, Jean-Yves LENHOF wrote:
Le 25/09/2019 à 19:47, David Ponzone a écrit :
Le 25 sept. 2019 à 19:35, Jean-Yves LENHOF jean-yves@lenhof.eu.org a écrit :
Ca me semble une mauvaise idée... De ce que j'en sais tu peux sur Debian :
- Utiliser la vieille méthode old-school avec ifupdown
Bonne nouvelle. Et quand tu fais ça, tu retrouves ton bon vieux eth0 à la place de ensX ?
Hello,
Si tu veux vraiment jouer au vieux con (parce que dans 30 secondes je sens que tu vas parler de systemd qui pour moi est quelque chose de plutôt assez bien foutu et évolué même si cela change pas mal nos habitudes et qu'il faut s'y mettre et que l'on a tjs du mal au début avec le changement), cela n'a rien à voir avec ifupdown ou les autres solutions indiquées ici, c'est plus autour de biosdevname que tu dois chercher...
Un petit lien :
https://memo-linux.com/debian-9-retrouver-les-noms-des-interfaces-reseaux-et...
Maintenant j'ai eu par le passé beaucoup de tour avec des eth0 qui se transformaient en eth1 avec certains changements de kernel... du coup c'était pas toujours glop
Avec les nouvelles notations ensxxx et autres, normalement le nom ne change pas entre deux kernels parce qu'il dépend de l'emplacement physique dans la machine (carte réseau built-in ou PCI ne donnent pas les mêmes noms, etc)
Personnellement j'utilise encore ifupdown sur certaines machines et j'utilise sur d'autres Network-Manager, qui a plutôt bien muri (avant la version intégrée ds RHEL/CentOS 7 pour situer) et dont le nmcli est plutôt assez bien foutu une fois que l'on sait qu'il sait faire de la completion... Je découvre systemd-network qui me semble jeune par rapport aux autres solutions, mais je suis intéressé par des commentaires de terrain objectifs, avec des gens qui ont essayé et qui peuvent faire des comparaisons
Cordialement,
JYL
Liste de diffusion du FRsAG http://www.frsag.org/
Le 25/09/2019 à 20:05, frsag@jack.fr.eu.org a écrit :
ethX, c'est bien
Ça nous apporte des choses futuristes, comme des noms d'interfaces réseaux predictibles.
On s'éloigne de la question mais perso je trouve ceci :
1. Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: |eno1|) 2. Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: |ens1|) 3. Names incorporating physical/geographical location of the connector of the hardware (example: |enp2s0|) 4. Names incorporating the interfaces's MAC address (example: |enx78e7d1ea46da|)
plus prédictible qu'un eth0 qui pointe sur une carte ou une autre dans un serveur...
Cdlt,
Soyons sérieux :)
Prédictif signifie qu'il est possible de prédire le nom.
Ainsi, je peux te donner le mapping réseau de l'intégralité de mes serveurs, ce qui signifie que les divers outils le peuvent aussi.
En revanche, je suis bien incapable de te prédire enp4s0f1. Et toi, le peux-tu ?
Cordialement,
On 09/25/2019 08:09 PM, Jean-Yves LENHOF wrote:
Le 25/09/2019 à 20:05, frsag@jack.fr.eu.org a écrit :
ethX, c'est bien
Ça nous apporte des choses futuristes, comme des noms d'interfaces réseaux predictibles.
On s'éloigne de la question mais perso je trouve ceci :
- Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: |eno1|)
- Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: |ens1|)
- Names incorporating physical/geographical location of the connector of the hardware (example: |enp2s0|)
- Names incorporating the interfaces's MAC address (example: |enx78e7d1ea46da|)
plus prédictible qu'un eth0 qui pointe sur une carte ou une autre dans un serveur...
Cdlt,
Liste de diffusion du FRsAG http://www.frsag.org/
Le 25/09/2019 à 20:35, frsag@jack.fr.eu.org a écrit :
Soyons sérieux :)
Prédictif signifie qu'il est possible de prédire le nom.
Ainsi, je peux te donner le mapping réseau de l'intégralité de mes serveurs, ce qui signifie que les divers outils le peuvent aussi.
En revanche, je suis bien incapable de te prédire enp4s0f1. Et toi, le peux-tu ?
Cordialement,
Pourquoi le prédire ?
Un truc assez proche dans l'esprit du lsdev d'AIX :
root@rey:~# lshw -C network -sanitize -short Chemin matériel Périphérique Classe Description ========================================================== /0/100/1c/0 eno1 network NetXtreme II BCM5716 Gigabit Ethernet /0/100/1c/0.1 eno2 network NetXtreme II BCM5716 Gigabit Ethernet root@rey:~#
Je pense qu'avec un peu de shell derrière on fait assez facilement ce qu'on veut.... comme récupérer le nom du périphérique que tu as du mal à trouver
Après lorsque tu n'as que des VMs avec une seule interface il y a beaucoup moins d'intérêt....
Cordialement,
Le 25/09/2019 à 20:01, Jean-Yves LENHOF a écrit :
Bonne nouvelle.
Et quand tu fais ça, tu retrouves ton bon vieux eth0 à la place de ensX ?
pour ca, il suffit de modifier /etc/default/grub :
GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"
et de regénérer le grub.conf avec "update-grub"
Guéguerre du libre? Voir Devuan ?
Vaste débat...
Sinon systemd c'est une peu comme le svchost.exe de Windows...on ne sait pas trop ce qui s'y passe.
Sans polémiques aucunes, c'est sans doute l'ère du temps qui veut ça.
--
Confraternellement,
Philippe Beauchet Service informatique Laboratoire CNRS-MAP Marseille
Le 25/09/2019 à 18:26, David Ponzone a écrit :
Le 25 sept. 2019 à 18:22, Pierre DOLIDON sn4ky@sn4ky.net a écrit :
Sinon, tu peux virer systemd-networkd et installer ifupdown. au moins, ça juste marche. pas de conf bizarroïde, old school certes, mais fonctionnel.
Ouais je voudrais pas enfoncer une porte ouverte, mais quelqu’un peut me résumer les avantages de systemd-networkd ? Parce que ça me semble être une usine à gaz inutile, qui pourrait bien me faire larguer Debian pour autre chose.
Liste de diffusion du FRsAG http://www.frsag.org/
pour ma part, je reste sur Debian, mais à l'install du système, je remets sysv à la place de systemd
Le 26/09/2019 à 11:18, Philippe Beauchet a écrit :
Guéguerre du libre? Voir Devuan ?
Vaste débat...
Sinon systemd c'est une peu comme le svchost.exe de Windows...on ne sait pas trop ce qui s'y passe.
Sans polémiques aucunes, c'est sans doute l'ère du temps qui veut ça.
--
Confraternellement,
Philippe Beauchet Service informatique Laboratoire CNRS-MAP Marseille
Le 25/09/2019 à 18:26, David Ponzone a écrit :
Le 25 sept. 2019 à 18:22, Pierre DOLIDON sn4ky@sn4ky.net a écrit :
Sinon, tu peux virer systemd-networkd et installer ifupdown. au moins, ça juste marche. pas de conf bizarroïde, old school certes, mais fonctionnel.
Ouais je voudrais pas enfoncer une porte ouverte, mais quelqu’un peut me résumer les avantages de systemd-networkd ? Parce que ça me semble être une usine à gaz inutile, qui pourrait bien me faire larguer Debian pour autre chose.
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
On Thu, 26 Sep 2019 11:31:24 +0200 Guillaume Tournat via FRsAG frsag@frsag.org wrote:
pour ma part, je reste sur Debian, mais à l'install du système, je remets sysv à la place de systemd
Bonjour,
que pensez-vous de Gentoo et son spinoff Sabayon, avec OpenRC, en terme globalement d'utilisabilité, comportement général (IP et autres, j'essaie de rester dans le sujet) et de gestion des processus ?
Cordialement, Joyce MARKOLL
Le mer. 25 sept. 2019 à 15:44, Artur frsag@pydo.org a écrit :
Malheureusement j'arrive à reproduire le problème même avec ce paramétrage... Il faut que je continue à faire des tests.
Que te retournent les commandes "ip ro show" et "networkctl status ens3" dans ce cas ?
Salut !
Je viens de reproduire le problème :
$ ip ro show default via 2.3.4.1 dev ens3 default via 2.3.4.1 dev ens3 proto dhcp src 2.3.4.5 metric 1024 2.3.4.1 dev ens3 scope link 2.3.4.1 dev ens3 proto dhcp scope link src 2.3.4.5 metric 1024
$ networkctl status ens3 ● 2: ens3 Link File: /lib/systemd/network/99-default.link Network File: /etc/systemd/network/50-default.network Type: ether State: routable (configuring) Path: pci-0000:00:03.0 Driver: virtio_net Vendor: Red Hat, Inc. Model: Virtio network device HW Address: fa:16:3e:14:09:99 Address: 2.3.4.5 fe80::f816:3eff:fe14:999 Gateway: 2.3.4.5 2.3.4.5 DNS: 213.186.33.99
Les 2 default routes n'apparaissent que quand il y a le problème.
Le 26/09/2019 à 05:46, Jonathan Leroy - Inikup a écrit :
Le mer. 25 sept. 2019 à 15:44, Artur frsag@pydo.org a écrit :
Malheureusement j'arrive à reproduire le problème même avec ce paramétrage... Il faut que je continue à faire des tests.
Que te retournent les commandes "ip ro show" et "networkctl status ens3" dans ce cas ?
Sur une autre machine où bizarrement cela semble marcher avec une config identique :
$ ip ro show default via 51.68.80.1 dev ens3 proto dhcp src 2.3.4.5 metric 1024 51.68.80.1 dev ens3 proto dhcp scope link src 2.3.4.5 metric 1024
$ networkctl status ens3 ● 2: ens3 Link File: /lib/systemd/network/99-default.link Network File: /etc/systemd/network/50-default.network Type: ether State: routable (configured) Path: pci-0000:00:03.0 Driver: virtio_net Vendor: Red Hat, Inc. Model: Virtio network device HW Address: fa:16:3e:07:7f:7d Address: 2.3.4.5 1.2.3.4 1.2.3.5 fe80::f816:3eff:fe07:7f7d Gateway: 51.68.80.1 DNS: 213.186.33.99
Le lun. 30 sept. 2019 à 18:04, Artur frsag@pydo.org a écrit :
Sur une autre machine où bizarrement cela semble marcher avec une config identique :
$ ip ro show default via 51.68.80.1 dev ens3 proto dhcp src 2.3.4.5 metric 1024 51.68.80.1 dev ens3 proto dhcp scope link src 2.3.4.5 metric 1024
Je me demande si ça ne serait pas un souci lié au serveur DHCP OVH. Tu as essayé de passer dhclient en mode debug pour avoir le détail du bail DHCP proposé quand le problème se produit ?
Le 04/10/2019 à 22:29, Jonathan Leroy - Inikup via FRsAG a écrit :
Le lun. 30 sept. 2019 à 18:04, Artur frsag@pydo.org a écrit :
Sur une autre machine où bizarrement cela semble marcher avec une config identique :
$ ip ro show default via 51.68.80.1 dev ens3 proto dhcp src 2.3.4.5 metric 1024 51.68.80.1 dev ens3 proto dhcp scope link src 2.3.4.5 metric 1024
Je me demande si ça ne serait pas un souci lié au serveur DHCP OVH. Tu as essayé de passer dhclient en mode debug pour avoir le détail du bail DHCP proposé quand le problème se produit ?
Je vais regarder ça.
Hello !
Je pense avoir mis le doigt sur le problème grâce à ta suggestion. Avant d'avoir pu faire des tests complémentaires, lors de la dernière mise à jour de Debian je me suis rendu compte que sur certaines machines le process dhclient tournait et écoutait sur ens3 alors qu'il était absent sur d'autres. Pourtant l'interface principale ens3 est systématiquement configurée en DHCP. En vérifiant les configs, il se trouve que sur les systèmes avec dhclient le fichier /etc/network/interfaces était présent. Bien que systemd-networkd était activé la présence de /etc/network/interfaces semblait déclencher le lancement de dhclient. Dès que le fichier interfaces a été renommé et le système rebooté, le dhclient a disparu. Bien évidemment, l'interface ens3 obtient bien son adresse dynamique par DHCP par un autre moyen, certainement grâce à systemd-networkd.
J'ai encore une machine à rebooter, celle qui posait problème, mais je pense que le problème est résolu.
Je ne sais pas dans quel mesure ceci est un bug, il me semble que le fichier interfaces devrait être ignoré si systemd est configuré pour gérer le réseau par ailleurs (dans d'autres fichiers de config).
Le 04/10/2019 à 22:29, Jonathan Leroy - Inikup via FRsAG a écrit :
Le lun. 30 sept. 2019 à 18:04, Artur frsag@pydo.org a écrit :
Sur une autre machine où bizarrement cela semble marcher avec une config identique :
$ ip ro show default via 51.68.80.1 dev ens3 proto dhcp src 2.3.4.5 metric 1024 51.68.80.1 dev ens3 proto dhcp scope link src 2.3.4.5 metric 1024
Je me demande si ça ne serait pas un souci lié au serveur DHCP OVH. Tu as essayé de passer dhclient en mode debug pour avoir le détail du bail DHCP proposé quand le problème se produit ?
il me semble que Debian a un usage particulier de Systemd. Notamment dans la gestion du réseau.
Et que si le fichier /etc/network/interfaces, il est utilisé.
Pour ma part, je ne peux pas encadrer Systemd, donc je remets SysV à chaque install :-)
Le 08/10/2019 à 14:19, Artur a écrit :
Hello !
Je pense avoir mis le doigt sur le problème grâce à ta suggestion. Avant d'avoir pu faire des tests complémentaires, lors de la dernière mise à jour de Debian je me suis rendu compte que sur certaines machines le process dhclient tournait et écoutait sur ens3 alors qu'il était absent sur d'autres. Pourtant l'interface principale ens3 est systématiquement configurée en DHCP. En vérifiant les configs, il se trouve que sur les systèmes avec dhclient le fichier /etc/network/interfaces était présent. Bien que systemd-networkd était activé la présence de /etc/network/interfaces semblait déclencher le lancement de dhclient. Dès que le fichier interfaces a été renommé et le système rebooté, le dhclient a disparu. Bien évidemment, l'interface ens3 obtient bien son adresse dynamique par DHCP par un autre moyen, certainement grâce à systemd-networkd.
J'ai encore une machine à rebooter, celle qui posait problème, mais je pense que le problème est résolu.
Je ne sais pas dans quel mesure ceci est un bug, il me semble que le fichier interfaces devrait être ignoré si systemd est configuré pour gérer le réseau par ailleurs (dans d'autres fichiers de config).
Le 04/10/2019 à 22:29, Jonathan Leroy - Inikup via FRsAG a écrit :
Le lun. 30 sept. 2019 à 18:04, Artur frsag@pydo.org a écrit :
Sur une autre machine où bizarrement cela semble marcher avec une config identique :
$ ip ro show default via 51.68.80.1 dev ens3 proto dhcp src 2.3.4.5 metric 1024 51.68.80.1 dev ens3 proto dhcp scope link src 2.3.4.5 metric 1024
Je me demande si ça ne serait pas un souci lié au serveur DHCP OVH. Tu as essayé de passer dhclient en mode debug pour avoir le détail du bail DHCP proposé quand le problème se produit ?
Le mar. 8 oct. 2019 à 14:19, Artur frsag@pydo.org a écrit :
Je pense avoir mis le doigt sur le problème grâce à ta suggestion.
Merci de ton retour. Je vais prochainement mettre en place une conf similaire, chez OVH également, donc ton problème m'intéressait. :)
Je ne sais pas dans quel mesure ceci est un bug, il me semble que le fichier interfaces devrait être ignoré si systemd est configuré pour gérer le réseau par ailleurs (dans d'autres fichiers de config).
Pour moi c'est un bug à signaler sur le BTS Debian. #MonAvis
Salut
La configuration Debian privilégie /etc/network/interface à /etc/systemd/network. Pour qu'une interface soit gérée par systemd elle doit être absente de l'ancienne conf.
cf https://wiki.debian.org/SystemdNetworkd
Km
Merci pour le lien du wiki.
J'ai rapporté le "bug", mais j'ai eu une bonne explication pourquoi c'en est pas un et pourquoi ça restera en état.
Je vous laisse lire :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942042
Merci à tous les participants pour les conseils et suggestions.
Le 09/10/2019 à 19:45, cam.lafit@azerttyu.net a écrit :
La configuration Debian privilégie /etc/network/interface à /etc/systemd/network. Pour qu'une interface soit gérée par systemd elle doit être absente de l'ancienne conf.
-
Artur -
cam.lafit＠azerttyu.net -
contact＠orditux.org -
David Ponzone -
frsag＠jack.fr.eu.org -
Guillaume Tournat -
Jean-Yves LENHOF -
Jonathan Leroy - Inikup -
Kevin CHAILLY | Service Technique -
Philippe Beauchet -
Pierre DOLIDON