25 Sep
2019
25 Sep
'19
11:36 a.m.
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
--
Cordialement,
Artur.
25 Sep
25 Sep
11:47 a.m.
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(a)frsag.org> De la part de Artur
Envoyé : mercredi 25 septembre 2019 11:37
À : French SysAdmin Group <frsag(a)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
--
Cordialement,
Artur.
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
12:30 p.m.
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
--
Cordialement,
Artur.
5:08 p.m.
Tu peux il faut faire
[Address]
Label=ens3:0
Address=1.2.3.4/5
-----Message d'origine-----
De : Artur <frsag(a)pydo.org>
Envoyé : mercredi 25 septembre 2019 12:30
À : Kevin CHAILLY | Service Technique <kchailly(a)adeo-informatique.com>om>; French
SysAdmin Group <frsag(a)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
--
Cordialement,
Artur.
12:51 p.m.
New subject: [FRsAG] @IP principale "par défaut" dans Debian Buster
Salut,
Le mer. 25 sept. 2019 à 11:38, Artur <frsag(a)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
--
Jonathan Leroy
2:52 p.m.
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(a)pydo.org> a écrit :
--
Cordialement,
Artur.
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
3:43 p.m.
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(a)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
>
--
Cordialement,
Artur.
6:22 p.m.
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(a)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
>>
6:26 p.m.
Le 25 sept. 2019 à 18:22, Pierre DOLIDON
<sn4ky(a)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.
7:35 p.m.
Le 25/09/2019 à 18:26, David Ponzone 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
- 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 à 18:22, Pierre DOLIDON <sn4ky(a)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/
7:47 p.m.
Le 25 sept. 2019 à 19:35, Jean-Yves LENHOF
<jean-yves(a)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 ?
8:01 p.m.
Le 25/09/2019 à 19:47, David Ponzone a écrit :
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-e…
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
Le 25 sept.
2019 à 19:35, Jean-Yves LENHOF <jean-yves(a)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 ? 
8:05 p.m.
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 :
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-e…
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/
--
"UNIX was not designed to stop its users from doing stupid things, as
that would also stop them from doing clever things." – Doug Gwyn
Le 25
sept. 2019 à 19:35, Jean-Yves LENHOF <jean-yves(a)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 ?
8:09 p.m.
Le 25/09/2019 à 20:05, frsag(a)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,
8:35 p.m.
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(a)jack.fr.eu.org a écrit :
--
"UNIX was not designed to stop its users from doing stupid things, as
that would also stop them from doing clever things." – Doug Gwyn
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,
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
8:59 p.m.
Le 25/09/2019 à 20:35, frsag(a)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,
26 Sep
26 Sep
2:46 p.m.
Le 25/09/2019 à 20:01, Jean-Yves LENHOF a écrit :
Bonne nouvelle.
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"
Et quand tu fais ça, tu retrouves ton bon vieux
eth0 à la place de
ensX ?
11:18 a.m.
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(a)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/
11:31 a.m.
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 :
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
Le 25 sept. 2019 à 18:22, Pierre DOLIDON
<sn4ky(a)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/
11:43 a.m.
New subject: @IP principale "par défaut" dans Debian Buster - SystemD, SysV, OpenRC ?
On Thu, 26 Sep 2019 11:31:24 +0200
Guillaume Tournat via FRsAG <frsag(a)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
--
Orditux Informatique
https://orditux.org
https://orditux.org/aol
26 Sep
26 Sep
5:46 a.m.
New subject: [FRsAG] @IP principale "par défaut" dans Debian Buster
Le mer. 25 sept. 2019 à 15:44, Artur <frsag(a)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 ?
--
Jonathan Leroy
30 Sep
30 Sep
5:42 p.m.
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(a)pydo.org> a écrit :
--
Cordialement,
Artur.
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 ?
6:04 p.m.
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
--
Cordialement,
Artur.
4 Oct
4 Oct
10:29 p.m.
New subject: [FRsAG] @IP principale "par défaut" dans Debian Buster
Le lun. 30 sept. 2019 à 18:04, Artur <frsag(a)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 ?
--
Jonathan Leroy
5 Oct
5 Oct
2:31 p.m.
Le 04/10/2019 à 22:29, Jonathan Leroy - Inikup via FRsAG a écrit :
Le lun. 30 sept. 2019 à 18:04, Artur
<frsag(a)pydo.org> a écrit :
Je vais regarder ça.
--
Cordialement,
Artur.
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 ?
8 Oct
8 Oct
2:19 p.m.
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(a)pydo.org> a écrit :
--
Cordialement,
Artur.
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 ?
3:29 p.m.
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(a)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 ?
9:27 p.m.
New subject: [FRsAG] @IP principale "par défaut" dans Debian Buster
Le mar. 8 oct. 2019 à 14:19, Artur <frsag(a)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
--
Jonathan Leroy
9 Oct
9 Oct
7:45 p.m.
New subject: [FRsAG] @IP principale "par défaut" dans Debian Buster
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
10:05 p.m.
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(a)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.
cf https://wiki.debian.org/SystemdNetworkd
--
Cordialement,
Artur.
1216
days inactive
1230
days old
32 comments
11 participants
participants (11)
-
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