Zainstalowałem Ubuntu 17.10 z najnowszymi aktualizacjami na maszynie wirtualnej VMware. Netplan nie konfiguruje moich 2 eternetów.
Oto mój /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
Wróciłem do przewidywalnych urządzeń, takich jak eth0, a po uruchomieniu wszystkie urządzenia mają prawidłowe nazwy, ale nie są skonfigurowane.
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
Po zalogowaniu i uruchomieniu systemctl uruchom ponownie systemd-networkd urządzenia są skonfigurowane. Netplan Apply również spełnia swoje zadanie.
Tak dużo grałem z systemd-networkd.service i systemd-networkd.timer, ale nic nie pomogło.
Konfigurowanie sieci po każdym ponownym uruchomieniu jest dość frustrujące. Czy ktoś wie jak to rozwiązać?
networking
systemd
netplan
Thomas Aichinger
źródło
źródło
Odpowiedzi:
Myślę, że trafiłeś na LP: # 1770082 - „systemd-networkd nie zmienia nazwy urządzeń przy starcie”.
Zasadniczo, gdy system się uruchamia, urządzenie sieciowe pojawi się jako
eth0
/eth1
itp. Kolejność nie jest przewidywalna, więc udev zmienia nazwy urządzeń na rzeczy takie jakens3
lubenp2s0
w początkowej fazie rozruchu. (Powinieneś być w stanie to zobaczyć, przechwytując dane wyjściowedmesg
.)Masz
set-name
w swojej sieci YAML zwrotkę. Później podczas rozruchuset-name
generuje regułę zmiany nazwy w systemowym pliku łącza , który jest odczytywany przez udev. Jednak plik linku nie spowoduje zmiany nazwy urządzenia, jeśli zostało ono już zmienione. W takim przypadku nazwa urządzenia nie zostanie zmieniona, ponieważ prawdopodobnie została zmieniona wcześniej w initrd.Otworzyłem błąd dotyczący systemd ( problem # 9006 - „udev: nazwa interfejsu w pliku linku nie zastosowano”) na ten temat. Zaproponowałem także zmianę w netplan ( PR # 31 - „Generowanie plików reguł udev w celu zmiany nazw urządzeń”), która spowoduje utworzenie pliku reguł systemowych oraz pliku łącza, ponieważ plik reguł jest honorowany, nawet jeśli urządzenie ma został już przemianowany.
Aby obejść ten problem, spróbuj uruchomić z
net.ifnames=0
wiersza polecenia jądra. Aby uzyskać długoterminowe rozwiązanie, spodziewaj się, że moja zmiana w netplan zostanie przeniesiona do Bionic i wydana w ciągu najbliższego miesiąca.źródło
set-name
dyrektywy, nie wypróbowałemnet.ifnames=0
cmdline jądra. Dziękiset-name
, urządzenia zostały przemianowane, ale nie wychowany.Mam dokładnie ten sam problem na Ubuntu 18.04, ale rozwiązanie R. Pietscha go nie rozwiązuje :(
Próbowałem także włączyć użytkownika root, który jest domyślnie wyłączony na Ubuntu, ale bez powodzenia.
Jedynym sposobem na uzyskanie łączności jest:
Jeśli nie „sudo netplan Apply”, nie mam połączenia z maszyną. Jak można wprowadzić do wersji LTS tak zepsuty kawałek oprogramowania?
Chciałbym dodać więcej szczegółów na temat mojego scenariusza, aby były przydatne dla innych osób w rozpoznawaniu zjawisk, o których mówimy. Tak było w moim przypadku:
Myślę, że netplan to dobra poprawa w porównaniu do / etc / network / interfaces, ale takie zachowanie powinno zostać naprawione jak najszybciej :)
AKTUALIZACJA:
Rozwiązałem problem przy użyciu następujących poleceń:
Wygląda na to, że kolidował z nim panel Network Managera w LXDE. Nawet jeśli połączenia były wyświetlane jako „niezarządzane”, odznaczyłem „Włącz obsługę sieci” i wydaje się, że to rozwiązało problem.
Możemy to zamknąć :)
źródło
Próbowałem teraz z Ubuntu 18.04 i myślę, że ten błąd został naprawiony.
Teraz działa dla mnie.
źródło
Rozwiązałem ten problem, wstawiając
do crontab roota. Nie prawdziwe rozwiązanie problemu, ale obejście, które go rozwiązało.
źródło
Wraz z Ubuntu 18.04 netplan był dla mnie całkiem nowy, postępowałem zgodnie z instrukcjami, aby utworzyć
/etc/netplan/01-netcfg.yaml
plik i uruchomić gosudo netplan apply
i tak jak ty, przy każdym ponownym uruchomieniu łączność zniknęła.Ręczne uruchamianie
sudo netplan apply
sprawiło, że znów działało. Ale to było denerwujące.W moim przypadku rozwiązaniem było edytowanie
/etc/network/interfaces
i komentowanie wszystkich zwrotek enp0 ** (sprawdź, jak są one wywoływane w twoim systemie).Następnie uruchom ponownie.
Zasadniczo stara konfiguracja w / etc / nwtwork / interfaces była w konflikcie z netplan.
źródło
Miałem problem, w którym musiałem ponownie uruchomić zdarzenia. Zasadniczo netplan poprawnie wykonał konfigurację, ale networkd to zignorował. Naprawienie tego spowodowałoby zastąpienie urządzeń „netplan Apply”.
Tak więc dla niektórych rozwiązaniem może być coś takiego
Może to pomaga niektórym szukającym tego problemu.
Ponieważ uważam, że jest to rzeczywiście błąd, zgłosiłem ten błąd .
źródło
Ok, lepsza odpowiedź. Naprawiłem to, wracam do ifupdown, aż netplan zostanie naprawiony. sudo apt install ifupdown następnie skonfiguruj interfejs sudo nano / etc / network / interfaces
auto enp3s0 iface enp3s0 inet adres statyczny 192.168.1.100 maska sieci 255.255.255.0 sieć 192.168.1.0 broadcast 192.168.1.255 brama 192.168.1.1 dns-nameservers 192.168.1.0,8.8.8.8
a ktokolwiek zaimplementował to w wydaniu serwera LTS, oczywiście tego nie przetestował
źródło
Ponieważ jest to ciągły problem, mam inne podejście do rozwiązania tego problemu:
Utwórz systemowy zegar i zastosuj ustawienia sieciowe po uruchomieniu.
Oto skrypt: check_network. Musisz wymienić interfejs ens32 na swój.
Jest to jednostka usługowa check_network.service
I to jest zegar systemowy check_network.timer o nazwie 30 sekund po rozruchu, a następnie co godzinę
Skopiuj check_network do / root / jobs
Skopiuj check_network.service do / etc / systemd / system
Skopiuj check_network.timer do / etc / systemd / system
A następnie włącz usługę i timer
źródło
użytkownik netplan w dniu 18.04.1 Założenie, że konfiguracja netplan jest czytana przy ponownym uruchomieniu sieci - to samo w sobie stanowiło pewien problem, ponieważ istnieje około 10 różnych usług sieciowych, które zna systemctl. Żaden z nich nie przyniósł pożądanego rezultatu, więc postanowiłem zrestartować całą maszynę. Bez skutku. W końcu dowiedziałem się, że „netplan Apply” pomaga tutaj nie tylko w stosowaniu, ale także w wskazywaniu błędów składniowych. Więc po zmianie wydaje się, że musisz zrobić Netplan, a potem gotowe. Nie jest to opisane w instrukcji, chyba że mi tego brakowało, więc dołączam to tutaj dla innych biednych małych robaków, takich jak ja.
źródło
Wszystko w pliku / etc / netplan jest generowane przez rzeczy inicjujące chmurę (termin techniczny, który znam)
Edytuj /etc/cloud/cloud.cfg/50-curtin-networking.cfg tak samo, jak edytowałeś plik /etc/netplan/*.yaml.
Następnie uruchom cloud-init clean cloud-init init sudo netplan Apply
Zrezygnowałem z rzeczy związanych z Wi-Fi dzięki netplan i wróciłem do ifupdown. Powodzenia dla wszystkich, którzy próbują to zrobić za pomocą Netplana, ponieważ przeczytałem, że Ubuntu naprawdę spieprzyło 18.04, kiedy nie całkowicie wyrzucili śmieci, jeśli nie działali, i nie w pełni wspierali chmurę. :( Może będzie lepiej w 19.04. Mam nadzieję, że informacje podane powyżej pomagają komuś.
źródło