systemd-networkd - comment forcer une nouvelle configuration sans redémarrer?

Sur ma boîte Arch, j'avais un pont réseau. L'objectif était de supprimer le pont et de n'utiliser que la carte réseau non pontée. Pour ce faire, j'ai supprimé tous les fichiers de configuration * .netdev et * .network sous /etc/systemd/networket les ai remplacés par un fichier simple:

/etc/systemd/network/lan.network
--------------------------------
[Match]
eno*

[Network]
DHCP=ipv4

J'ai ensuite redémarré le service réseau en utilisant systemctl restart systemd-networkd, en supposant que cela me laisserait juste avec lol' eno*interface et. Malheureusement, cela n'a eu aucun effet. Un coup d'œil rapide a ip linkmontré que l'interface du pont était active et active.

Parce que la disponibilité dans ce cas particulier n'est pas cruciale, je viens de redémarrer la machine qui a résolu le problème. Pourtant, j'aimerais penser que les redémarrages ne devraient pas être nécessaires pour ce genre de chose. Qu'est-ce que j'ai manqué de faire?

systemd systemd-networkd vic
la source

v244 a networkctl reloadet reconfigure @ github.com / systemd

frostschutz

Réponses:

Si votre interface maître de pont est toujours active, ses interfaces esclaves liées le resteront même si de nouvelles configurations leur sont découvertes entre-temps. Alors perdez le pont.

ip link set down br0
ip link del dev br0
systemctl restart systemd-networkd

la source

Ne perdrais-je pas l'accès au réseau dans le processus?

vic

@vic - si votre accès réseau est acheminé via un pont auquel vous avez lié votre nic, alors oui, je m'y attend. je ne peux pas penser à un moyen simple de faire autrement, et les façons compliquées auxquelles je peux penser ne sont qu'à moitié cuites et impliquent des nics virtuels de conservation temporaires et un filtrage netfilter dans le noyau de tous les paquets sur le dev. laid et idiot. que ce soit ou voyage dans le temps. il y a peut-être une autre façon, mais tu ne l'apprendras pas de moi. de toute façon, le réseau n'est perdu qu'à la suite de la première commande et ensuite restauré à la suite de la troisième. probablement moins dt qu'un redémarrage.

@vic Je sais que je suis en retard à la fête, mais une façon pourrait être de chaîner les commandes en une seule ligne, comme ip link set down br0 && ip link del dev br0 && systemctl restart systemd-networkd. Votre connexion peut chuter, au moins momentanément, mais le service de mise en réseau de l'hôte doit être de nouveau en ligne et vous pouvez toujours créer une nouvelle session SSH tant que vous connaissez l'adresse IP que vous obtiendrez après le redémarrage.

code_dredd

Utilisez un point-virgule &&pour ne pas enchaîner ces commandes. Si l'un échoue, il peut toujours reconfigurer la connexion réseau de manière utilisable afin que vous n'ayez pas à vous lever et à visiter le serveur ...

Josef Kufner