J'ai installé Ubuntu 17.10 avec les dernières mises à jour sur une machine virtuelle vmware. Netplan ne configure pas mes 2 ethernets.
Voici mon /etc/netplan/01-netcfg.yaml
network:
version: 2
renderer: networkd
ethernets:
lan:
match:
macaddress: 00:12:34:a8:29:e8
set-name: lan
dhcp4: false
dhcp6: false
accept-ra: false
addresses:
- 10.10.0.48/24
- 1701:5740:5000:3301::48/64
failover:
match:
macaddress: 00:45:57:89:27:e8
set-name: failover
dhcp4: false
dhcp6: false
accept-ra: false
addresses:
- 17.25.111.30/27
- 1701:5740:5000:3300::30/64
gateway4: 17.25.111.1
gateway6: 1701:5740:5000:3300::1
nameservers:
search:
- example.at
- intern.example.at
addresses:
- 10.10.0.1
- 1701:5740::66
Je suis revenu à des appareils prévisibles comme eth0, et après le démarrage, tous les appareils sont nommés correctement, mais pas configurés.
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: lan: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 00:12:34:a8:29:e8 brd ff:ff:ff:ff:ff:ff
3: failover: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 00:45:57:89:27:e8 brd ff:ff:ff:ff:ff:ff
Après la connexion et le déclenchement de systemctl, les périphériques systemd-networkd sont configurés. Netplan Apply fait également l'affaire.
J'ai tellement joué avec systemd-networkd.service et systemd-networkd.timer mais rien n'y fait.
Il est assez frustrant de configurer le réseau manuellement après chaque redémarrage. Quelqu'un sait-il comment résoudre ceci?
networking
systemd
netplan
Thomas Aichinger
la source
la source
Réponses:
Je pense que vous avez frappé LP: # 1770082 - "systemd-networkd ne renomme pas les périphériques au démarrage".
Fondamentalement, lorsque votre système démarre, le périphérique réseau apparaîtra comme
eth0
/eth1
etc. L'ordre n'est pas prévisible, donc udev renomme les périphériques en des choses commeens3
ouenp2s0
dans la phase initrd de démarrage. (Vous devriez pouvoir voir cela en saluant la sortie dedmesg
.)Vous avez une
set-name
strophe dans votre netplan YAML. Plus tard au démarrage, celaset-name
génère une règle de changement de nom dans un fichier de lien systemd , qui est lu par udev. Cependant, un fichier de lien n'entraînera pas le renommage d'un périphérique s'il a déjà été renommé. Dans votre cas, le périphérique ne sera pas renommé car il a probablement été renommé plus tôt dans initrd.J'ai ouvert un bogue contre systemd ( problème # 9006 - "udev: nom d'interface dans le fichier de lien non appliqué") à ce sujet. J'ai également proposé une modification de netplan ( PR # 31 - "Générer des fichiers de règles udev pour renommer les périphériques") qui entraînera la création d' un fichier de règles systemd ainsi qu'un fichier de liens, car un fichier de règles est respecté même si le périphérique a déjà renommé.
Pour contourner le problème, essayez de démarrer avec
net.ifnames=0
sur la ligne de commande du noyau. Pour une solution à long terme, attendez-vous à ce que mon changement de netplan soit rétroporté sur Bionic et publié dans le mois prochain.la source
set-name
directives pour l'instant, je n'ai pas essayé lanet.ifnames=0
cmdline du noyau. Avecset-name
, les appareils ont été renommés, mais pas affichés.J'ai exactement le même problème sur Ubuntu 18.04, mais la solution de R. Pietsch ne le résout pas :(
J'ai également essayé d'activer l'utilisateur root, qu'il est désactivé par défaut sur Ubuntu, mais pas de chance.
La seule façon de gagner en connectivité est de:
Si je n'applique pas "sudo netplan", je n'ai pas de connexion sur la machine. Comment est-il possible de mettre dans une version LTS un tel logiciel cassé?
Je voudrais ajouter plus de détails sur mon scénario, pour être utile à d'autres personnes pour reconnaître les phénomènes dont nous parlons. C'est ce qui se passait dans mon cas:
Je pense que netplan est une bonne amélioration par rapport à / etc / network / interfaces, mais ce comportement devrait être corrigé dès que possible :)
MISE À JOUR:
J'ai débogué le problème à l'aide des commandes suivantes:
Il semble que ce soit le panneau Network Manager dans LXDE qui interfère avec lui. Même si les connexions étaient affichées comme "non gérées", j'ai décoché la case "Activer la mise en réseau" et il semble que cela ait résolu le problème.
Nous pouvons fermer celui-ci :)
la source
Je l'ai maintenant essayé avec Ubuntu 18.04 et je pense que ce bug a été corrigé.
Ça marche pour moi maintenant.
la source
J'ai résolu ce problème en insérant
dans la crontab de racine. Pas la vraie solution au problème, mais une solution de contournement qui l'a résolu.
la source
Avec Ubuntu 18.04, Netplan était également assez nouveau pour moi, j'ai suivi un guide pour créer le
/etc/netplan/01-netcfg.yaml
fichier et exécutersudo netplan apply
et comme vous, à chaque redémarrage, la connectivité avait disparu.L'exécution manuelle l'a
sudo netplan apply
fait fonctionner à nouveau. Mais c'était ennuyeux.Dans mon cas, la solution était d'éditer
/etc/network/interfaces
et de commenter toutes les strophes enp0 ** (vérifiez comment elles sont appelées dans votre système).Redémarrez ensuite.
Fondamentalement, l'ancienne configuration dans / etc / nwtwork / interfaces était en conflit avec netplan.
la source
J'ai eu un problème où je devais relancer les événements. Essentiellement, netplan a tout fait correctement, mais networkd l'a ignoré. Le fait de rebrancher les appareils en tant que "netplan applique" le corrigerait.
Donc, pour certains, la solution pourrait être de faire comme
Peut-être que cela aide certains à rechercher ce problème.
Puisque je pense que c'est en fait un bug, j'ai déposé ce bug à ce sujet.
la source
Ok meilleure réponse, je l'ai corrigé, revenez à ifupdown jusqu'à ce que netplan soit corrigé. sudo apt installe ifupdown puis configurez l'interface sudo nano / etc / network / interfaces
auto enp3s0 iface enp3s0 adresse statique inet 192.168.1.100 masque de réseau 255.255.255.0 réseau 192.168.1.0 diffusion 192.168.1.255 passerelle 192.168.1.1 dns-nameservers 192.168.1.0,8.8.8.8
et celui qui a implémenté cela dans une version de serveur LTS n'a évidemment pas testé
la source
Comme il s'agit d'un problème permanent, j'ai une autre approche pour résoudre ce problème:
Créez une minuterie systemd et appliquez les paramètres réseau après le démarrage.
Voici le script: check_network. Vous devez remplacer l'interface ens32 par la vôtre.
Il s'agit de l'unité de service check_network.service
Et ceci est la minuterie systemd check_network.timer appelée 30 secondes après le démarrage, puis toutes les heures
Copiez le check_network dans / root / jobs
Copiez check_network.service dans / etc / systemd / system
Copiez check_network.timer dans / etc / systemd / system
Et puis activez le service et le minuteur
la source
utilisateur de netplan le 18.04.1 Hypothèse que la configuration de netplan est lue au redémarrage de networkd - cela en soi était un peu un problème car il existe 10 services réseau différents que systemctl connaît. Aucun d'eux n'a apporté le résultat souhaité, j'ai donc dû redémarrer toute la machine. En vain. Finalement, j'ai découvert que «netplan apply» aide ici non seulement à appliquer mais aussi à indiquer les défauts de syntaxe. Donc, après le changement, il semble que vous devez appliquer Netplan et vous avez terminé. Ce n'est pas décrit dans le manuel, sauf si je l'ai manqué, donc je l'inclus ici pour d'autres pauvres petits vers comme moi.
la source
Tout dans le fichier / etc / netplan est généré par le truc cloud-init (terme technique que je connais)
Modifiez /etc/cloud/cloud.cfg/50-curtin-networking.cfg de la même manière que vous éditiez le fichier /etc/netplan/*.yaml.
Ensuite, exécutez cloud-init clean cloud-init init sudo netplan apply
J'ai abandonné les trucs wifi avec netplan, et je suis juste revenu à ifupdown. Bonne chance à tous ceux qui essaient de le faire avec netplan car j'ai lu qu'Ubuntu a vraiment merdé le 18.04 quand ils n'ont pas complètement mis à la poubelle ifupdown et ne prennent pas pleinement en charge cloud-init. :( Peut-être que les choses iront mieux en 19.04. J'espère que les informations que j'ai données ci-dessus aident quelqu'un.
la source