Zunächst einmal vielen Dank für Eure Hinweise.
micneu schrieb:
Bitte zeige uns den Inhalt von „/etc/netplan/“ (als codeblock)
Hier die Datei /etc/netplan/01-netcfg.yaml als code block:
1
2
3
4
5
6
7
8
9
10
11
12
13
14 | network:
version: 2
renderer: networkd
ethernets:
enp2s0:
dhcp4: no
dhcp6: no
addresses:
- 192.168.178.50/24
routes:
- to: default
via: 192.168.178.1
nameservers:
addresses: [192.168.178.1,8.8.8.8]
|
micneu schrieb:
Was spricht denn dagegen eine Feste IP per DHCP zuzuweisen, so mache ich es bei mir, hat den Vorteil, hänge ich den Rechner in ein anderes netzt bekommt er eine neue IP per DHCP.
Grundsätzlich nichts, es sei man hat eine Netzwerkumgebung, wo der Router lediglich als Gateway zum Internet und als DHCP-Server eine Vielzahl an Clients dient und neben anderen festen Nodes, wie z.B. Server grundsätzlich austauschbar ist. Machbar ist natürlich vieles, aber es geht hier auch um ein Konzept und dazu gehören auch feste IP-Adressen für bestimmte nodes außerhalb des DHCP-Adressbereiches aber innerhalb des gleichen Subnetzes.
micneu schrieb:
PS: hast du die Offizielle Dokumentation gelesen, da ist genau beschrieben wie die netplan aussehen soll?
Also, wenn wir davon ausgehen dürfen, dass ich mit https://netplan.readthedocs.io/en/stable/tutorial/ auch die offizielle Dokumentation erreicht habe, lässt sich die Frage mit Ja beantworten, diese gelesen zu haben. Und Nein, der konkrete Fall einer statischen IPv4-Adresse mit Route zum Gateway und zu DNS-Server, ist hier leider nicht explizit ausgeführt. Da muss man schon kreativ werden und kann allenfalls ableiten.
kB schrieb:
Es ist eine dumme Idee, die Netzwerkkonfiguration eines Rechners zu ändern, während man über das Netzwerk mit dem Rechner verbunden ist.
Dabei geschieht in der Regel genau das, was das alte Gleichnis vom Mann, der den Baumast absägt, auf dem er sitzt, ausdrücken will.
Mit Netplan selbst hat das eher nichts zu tun und Deine Datei ist ja, wie Du selbst schreibst, in Ordnung.
Nun, grundsätzlich gebe ich Dir da recht. Aber ich habe das Konzept von netplan eben genau dahingehend verstanden, dass es sehr wohl möglich sein soll, a.) die Netzwerkonkfiguration im laufenden Betrieb zu ändern, b.) vor der eigentlichen Änderungen mit Hilfe des netplan try sichergestellt werden kann, dass die Konfiguration zumindest keine syntaktischen Fehler beinhaltet. Der Fehler, den ich gemacht wird dahingehend gewesen sein, dass ich weder die Konfiguration bestätigt noch den Countdown haben durchlaufen lassen. Mit Strg-C habe ich das System wohl in einen undefinierten Zustand versetzt. Also meine eigene Doofheit, soviel ist schon klar.
Aber dennoch kursieren viele Dokumentationen und Beispiele, die mit Blick auf das Konzept von netplan vergleichbar mit dem Raussreissen von Kabel und Kurzschließen der Zündung bei einem PKW anmuten.
Hier nun die vollständige Auflösung, das dürfte evt. den ein oder anderen auch interessieren. Der Server war nach einem Soft-Reset wieder über das Netzwerk ansprechbar.
Ich habe unter /etc/netplan nun zwei Dateien. Die erste Datei wurde mit der Installation und der Übernahme des Vorschlags die Netzwerkkonfiguration via DHCP durchzuführen, "ausgeliefert".
50-cloud-init.yaml:
| # This file is generated from information provided by the datasource. Changes
# to it will not persist across an instance reboot. To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
ethernets:
enp2s0:
dhcp4: true
version: 2
|
und die zweite Datei habe ich neu erstellt. Wichtig ist hier dass der Eigner root ist und zusätzlich die Rechte für die Datei auf 0600 eingeschränkt sind.
01-netcfg-yaml:
1
2
3
4
5
6
7
8
9
10
11
12
13
14 | network:
version: 2
renderer: networkd
ethernets:
enp2s0:
dhcp4: no
dhcp6: no
addresses:
- 192.168.178.50/24
routes:
- to: default
via: 192.168.178.1
nameservers:
addresses: [192.168.178.1,8.8.8.8]
|
Das Ergebnis ist, dass der Server nun einmal über die feste und einmal über die DHCP-Adresse erreichbar ist. So habe ich das auch verstanden, konnte das aber mit Blick in die Dokumentation leider nicht verifizieren. Und dann kam der Punkt, dass ein Strg-C bei netplan try offensichtlich keine gute Idee ist. Jetzt bin ich etwas schlauer. Und nun könnte man natürlich die Nutzung via DHCP im zweiten Schritt deaktivieren.