Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Linux Autres OS Linux Interface vlan qui se renomme toute seule

Interface vlan qui se renomme toute seule

31 réponses
Avatar
Erwan David
Sur une debian 10 j'ai une interface bond0 (un lacp)
et je veux créer une sous interface pour le vlan 4011 sur ce bond 0

J'ai donc dans mon /etc/network/interfaces un

auto bond0.4011
iface bond0.4011 inet static
adresss xxxx

Malheureusement entre le moment o͹ l'interface est créée et sa
configuration elle est renommée en 'rename12'.

Comment éviter ça ? (d'autant que je vais avoir d'autres interfaces
semblables et vais donc être incapable de deviner le nom que udev leur
donnera).



--
Les simplifications c'est trop compliqué
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3 4
Avatar
Marc SCHAEFER
Pascal Hambourg wrote:
[ snip sur bug systemd et work-around ]

Ce n'est pas un bug de systemd si on lui demande de renommer une
interface identifiée par sa seule adresse MAC alors que plusieurs
interfaces ont la même. C'est une erreur de configuration.

Je relis:
systemd ayant lors d'une mise Í  jour changé le nom prétendu prévisible
de mes interfaces physiques, et donc foutu en l'air ma conf, j'ai nommé
moi même mes interfaces (lan0, lan1, wan0, wan1) Í  l'aide d'un .link qui
matchait sur l'adresse MAC uniquement.

Ici, on parle d'interface physique, donc je suppose avec adresses MAC
différentes. Mais sauf erreur, systemd ne travaille-t-il pas, lui, avec
les adresses du bus PCI? C'est peut-être ça qui a changé, pour une
raison étrange.
Dans tous les cas, ci-dessus exhibe un bug de systemd, Í  ma
connaissance.
Après, quand on parle ENSUITE de bond, oui, lÍ  il peut y avoir ambiguité
MAC, et c'est `normal' que systemd ait un problème, probablement.
Je dois toutefois constater que depuis le passage aux `noms
prétendument prévisibles', je n'ai jamais eu autant d'interfaces qui
changent subitement de noms, et donc j'ai dÍ» les fixer manuellement par
MAC ... depuis que je fais ça (aka comportement d'avant), plus jamais
eu aucun problème ...
Avatar
Marc SCHAEFER
Marc SCHAEFER wrote:
changent subitement de noms, et donc j'ai dÍ» les fixer manuellement par
MAC ... depuis que je fais ça (aka comportement d'avant), plus jamais
eu aucun problème ...

J'ajoute aussi que les seules machines qui font des bugs bizarres de
résolution de noms sont celles o͹ /etc/resolv.conf pointe sur
systemd-resolvd. La désactivation de ce service corrige en général le
problème.
Je ne dis pas que systemd est de la merde: je dis simplement que c'est
trop gros et complexe et que cela veut faire trop de choses.
Après, avec le temps, les choses vont se stabiliser. C'est d'ailleurs
pour ça que je suis passé directement de jessie (sans systemd) Í  buster
(avec systemd): mes tests préliminaires avec stretch ont montré trop de
bugs.
Et d'ici que ça se stabilise, un autre init remplacera probablement
systemd. C'est sauf erreur déjÍ  le cas dans certaines distributions.
Avatar
jp willm
Le 08/04/2021 Í  09:32, Marc SCHAEFER a écrit :
Je ne dis pas que systemd est de la merde: je dis simplement que c'est
trop gros et complexe et que cela veut faire trop de choses.

Systemd me fait penser Í  Windows.
J'ai changé de distribution Í  cause de cela.
--
jp willm
https://willms.pagesperso-orange.fr/
https://www.youtube.com/channel/UCJwHW5GwrK1fq16cxUoBOUw
Avatar
Marc SCHAEFER
jp willm wrote:
Systemd me fait penser Í  Windows.

Oui, UNIX a toujours été (hors navigateur web, traitement de texte
libreoffice et systemd) un logiciel pour une t͢che.
Toutefois, systemd *est* modularisé dans plusieurs daemons, mais ils ont
énormément de dépendances entre eux et avec dbus, et rien que ça:
:~# ldd /lib/systemd/systemd-logind
linux-vdso.so.1 (0x00007fffc4f25000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe3ddf51000)
libsystemd-shared-241.so => /lib/systemd/libsystemd-shared-241.so (0x00007fe3ddcc3000)
libacl.so.1 => /usr/lib/x86_64-linux-gnu/libacl.so.1 (0x00007fe3ddcb8000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe3de15a000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fe3ddcae000)
libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x00007fe3ddca6000)
libcryptsetup.so.12 => /lib/x86_64-linux-gnu/libcryptsetup.so.12 (0x00007fe3ddc4c000)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007fe3ddb2c000)
libip4tc.so.0 => /usr/lib/x86_64-linux-gnu/libip4tc.so.0 (0x00007fe3ddb22000)
libkmod.so.2 => /usr/lib/x86_64-linux-gnu/libkmod.so.2 (0x00007fe3ddb07000)
libmount.so.1 => /lib/x86_64-linux-gnu/libmount.so.1 (0x00007fe3ddaa8000)
libseccomp.so.2 => /usr/lib/x86_64-linux-gnu/libseccomp.so.2 (0x00007fe3dda5f000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fe3dd837000)
libidn.so.11 => /lib/x86_64-linux-gnu/libidn.so.11 (0x00007fe3dd601000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007fe3dd5d9000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007fe3dd5ba000)
libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x00007fe3dd565000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe3dd544000)
libattr.so.1 => /usr/lib/x86_64-linux-gnu/libattr.so.1 (0x00007fe3dd53c000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007fe3dd531000)
libdevmapper.so.1.02.1 => /lib/x86_64-linux-gnu/libdevmapper.so.1.02.1 (0x00007fe3dd4c5000)
libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007fe3dd433000)
libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007fe3dd14a000)
libargon2.so.1 => /usr/lib/x86_64-linux-gnu/libargon2.so.1 (0x00007fe3dd140000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe3dd13b000)
libjson-c.so.3 => /usr/lib/x86_64-linux-gnu/libjson-c.so.3 (0x00007fe3dd12b000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007fe3dd108000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fe3dd094000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007fe3dd06e000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe3dceeb000)
fait peur en terme de surface d'attaque ...
Est-ce composé par le confinement que systemd met en place? Je ne sais
pas.
J'ai changé de distribution Í  cause de cela.

Laquelle?
Avatar
Marc SCHAEFER
jp willm wrote:
Systemd me fait penser Í  Windows.

Oui, UNIX a toujours été (hors navigateur web, traitement de texte
libreoffice et systemd) un logiciel pour une t͢che.
Toutefois, systemd *est* modularisé dans plusieurs daemons, mais ils ont
énormément de dépendances entre eux et avec dbus, et rien que ça:
:~# ldd /lib/systemd/systemd-logind
linux-vdso.so.1 (0x00007fffc4f25000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe3ddf51000)
libsystemd-shared-241.so => /lib/systemd/libsystemd-shared-241.so (0x00007fe3ddcc3000)
libacl.so.1 => /usr/lib/x86_64-linux-gnu/libacl.so.1 (0x00007fe3ddcb8000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe3de15a000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fe3ddcae000)
libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x00007fe3ddca6000)
libcryptsetup.so.12 => /lib/x86_64-linux-gnu/libcryptsetup.so.12 (0x00007fe3ddc4c000)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007fe3ddb2c000)
libip4tc.so.0 => /usr/lib/x86_64-linux-gnu/libip4tc.so.0 (0x00007fe3ddb22000)
libkmod.so.2 => /usr/lib/x86_64-linux-gnu/libkmod.so.2 (0x00007fe3ddb07000)
libmount.so.1 => /lib/x86_64-linux-gnu/libmount.so.1 (0x00007fe3ddaa8000)
libseccomp.so.2 => /usr/lib/x86_64-linux-gnu/libseccomp.so.2 (0x00007fe3dda5f000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fe3dd837000)
libidn.so.11 => /lib/x86_64-linux-gnu/libidn.so.11 (0x00007fe3dd601000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007fe3dd5d9000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007fe3dd5ba000)
libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x00007fe3dd565000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe3dd544000)
libattr.so.1 => /usr/lib/x86_64-linux-gnu/libattr.so.1 (0x00007fe3dd53c000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007fe3dd531000)
libdevmapper.so.1.02.1 => /lib/x86_64-linux-gnu/libdevmapper.so.1.02.1 (0x00007fe3dd4c5000)
libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007fe3dd433000)
libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007fe3dd14a000)
libargon2.so.1 => /usr/lib/x86_64-linux-gnu/libargon2.so.1 (0x00007fe3dd140000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe3dd13b000)
libjson-c.so.3 => /usr/lib/x86_64-linux-gnu/libjson-c.so.3 (0x00007fe3dd12b000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007fe3dd108000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fe3dd094000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007fe3dd06e000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe3dceeb000)
fait peur en terme de surface d'attaque ...
Est-ce compensé par le confinement que systemd met en place? Je ne sais
pas.
J'ai changé de distribution Í  cause de cela.

Laquelle?
Avatar
jp willm
Le 08/04/2021 Í  10:51, Marc SCHAEFER a écrit :
jp willm wrote:
Systemd me fait penser Í  Windows.

Oui, UNIX a toujours été (hors navigateur web, traitement de texte
libreoffice et systemd) un logiciel pour une t͢che.

Oui, les corporations n'ont pas la même approche.
Toutefois, systemd *est* modularisé dans plusieurs daemons, mais ils ont
énormément de dépendances entre eux et avec dbus, et rien que ça:
.../...
fait peur en terme de surface d'attaque ...

Un système init n'est pas simple (surtout pour moi), mais lÍ , on atteint
des sommets...
Est-ce compensé par le confinement que systemd met en place? Je ne sais
pas.

Ce confinement ressemble Í  un "work around".
J'ai changé de distribution Í  cause de cela.

Laquelle?

Artix Linux basée sur Arch avec l'init open-rc (Gentoo), car il me faut
des applications récentes (autrement, j'aurais sans doute choisi Devuan).
Il y a une version Artix runit et Artix S6, mais l'init préconisé est
openrc.
--
jp willm
https://willms.pagesperso-orange.fr/
https://www.youtube.com/channel/UCJwHW5GwrK1fq16cxUoBOUw
Avatar
Pascal Hambourg
Le 08/04/2021 Í  09:29, Marc SCHAEFER a écrit :
Pascal Hambourg wrote:
[ snip sur bug systemd et work-around ]

Ce n'est pas un bug de systemd si on lui demande de renommer une
interface identifiée par sa seule adresse MAC alors que plusieurs
interfaces ont la même. C'est une erreur de configuration.

Je relis:
systemd ayant lors d'une mise Í  jour changé le nom prétendu prévisible
de mes interfaces physiques, et donc foutu en l'air ma conf, j'ai nommé
moi même mes interfaces (lan0, lan1, wan0, wan1) Í  l'aide d'un .link qui
matchait sur l'adresse MAC uniquement.


AMA le nommage "prévisible" est une grosse arnaque. D'une part il est
prévisible Í  condition de connaÍ®tre Í  l'avance les paramètres qui
influent sur le nommage ; d'autre part sa persistance dépend de celle
des paramètres en question, qui n'est pas garantie. Cas typique : la
carte mère qui renumérote les adresses du bus PCI en fonction des
périphériques présents et actifs.
Ici, on parle d'interface physique,

Non, si j'ai bien compris on parle d'une interface VLAN.
Mais sauf erreur, systemd ne travaille-t-il pas, lui, avec
les adresses du bus PCI?

Oui, mais pas seulement. Il peut aussi utiliser des informations
exportées par le firmware de la machine, si elles sont disponibles.
C'est peut-être ça qui a changé, pour une
raison étrange.
Dans tous les cas, ci-dessus exhibe un bug de systemd, Í  ma
connaissance.

De quoi parles-tu exactement ? Du nommage prévisible non persistant ou
du nommage basé sur l'adresse MAC qui foire quand plusieurs interfaces
ont la même ?
Avatar
Pascal Hambourg
Le 08/04/2021 Í  09:32, Marc SCHAEFER a écrit :
Marc SCHAEFER wrote:
changent subitement de noms, et donc j'ai dÍ» les fixer manuellement par
MAC ... depuis que je fais ça (aka comportement d'avant), plus jamais
eu aucun problème ...

J'ajoute aussi que les seules machines qui font des bugs bizarres de
résolution de noms sont celles o͹ /etc/resolv.conf pointe sur
systemd-resolvd. La désactivation de ce service corrige en général le
problème.

Quel rapport entre la résolution DNS et le nommage des interfaces ?
Avatar
Marc SCHAEFER
Pascal Hambourg wrote:
Quel rapport entre la résolution DNS et le nommage des interfaces ?

Aucun, puisque tu avais amene le sujet sur systemd, j'ai simplement
donne un exemple de plus ou systemd n'est pas (encore) parfait.
Avatar
Marc SCHAEFER
Pascal Hambourg wrote:
Ici, on parle d'interface physique,

Non, si j'ai bien compris on parle d'une interface VLAN.

pour le bug 2, oui, le bug 1 qui a amene au work-around qui a amene le
bug 1, concernait des interfaces physiques.
De quoi parles-tu exactement ? Du nommage prévisible non persistant ou
du nommage basé sur l'adresse MAC qui foire quand plusieurs interfaces
ont la même ?

Du premier cas, des le debut.
1 2 3 4