Frage zu systemd-networkd Konfiguration

[nephilim]

Guten Morgen,

ich bin durch einen anderen Thread auf das Thema Netzverwaltung mit systemd gekommen und spiele damit gerade etwas herum. Ich benutze einen Pi3 und Debian 8. Ist eine Testmaschine, ich kann also nichts kaputtmachen.

Ich habe eine, vielleicht ganz banale, Frage zur Konfiguration (*,netwok). Ich versuche zu verstehen, was ich da mache und weiß nicht, woher der Eintrag hinter Name in der Sektion Match kommt:

Code: Alles auswählen

[Match]
Name=en*

Wa sich glaube herausgelesen zu haben, ist, dass das der jeweilige Interface-Name ist, in diesem Beispiel für alle gemeint. Aber wie finde ich die genauen Namen der einzelnen Interfaces auf meinen Maschinen heraus, um sie eindeutig zu identifizieren?

LG // neph

[TomL]

Das ist alles einfach:

Code: Alles auswählen

ip a

zeigt Dir die NICs und deren Status an. Zweimal UP heisst, NIC geöffnet und verbunden. Einmal UP heisst, NIC ist zwar geöffnet, aber nicht verbunden. Zweimal "DOWN" heisst NIC ist ausgeschaltet und nicht verbunden."ip" ist ein sehr vielseitiger Befehl, nicht nur zur Status-Anzeige, sondern auch zur Einrichtung von Interfaces und Routen... dazu gibts im Web sehr viele gute Beispiele, als das es sinnvoll wäre, die hier zu wiederholen.

https://www.freedesktop.org/wiki/Softwa ... faceNames/
Damit es bei mir mit Stretch wieder eth0 heisst:

Code: Alles auswählen

/etc/systemd/network/10-eth0.link

Code: Alles auswählen

[Match]
MACAddress=11:22:33:99:99:99

[Link]
Name=eth0

Für Jessie (also auch für den PI) würde die Umbenennung eines NICs nur mit einer UDEV-Rule funktionieren! Aber dort heisst sie sowieso noch eth?.

Und die Einstellung für systemd-networkd sieht so aus:

Code: Alles auswählen

cat /etc/systemd/network/eth0.network

Code: Alles auswählen

[Match]
Name=eth0

[Network]
DHCP=yes

Gateway=10.10.1.1
Gateway=fd00:1::123:123:123:123

IPv6PrivacyExtensions=true

BTW, Du darst jetzt hier nicht alles wörtlich nehmen.... es gibt zwischen Jessie und Stretch ein paar Unterschiede. Das findet man aber alles im Web heraus. So heisst es bei Jessie nicht DHCP=yes, sondern DHCP=v4, und die Privacy Extensions werden unter sysctl eingestellt. Tja... so isses halt bei einem Versionswechsel ..... aber die Änderungen sind imho sinnvoll.

Nachtrag, wenn Du systemd-networkd in Betrieb nehmen willst, musst Du allerdings vorher /etc/init.d/networking ausplanen.

Du solltest dabei aber nicht systemd-resolved vergessen.... in dem Zuge würde ich ntp und rsyslog auch noch deinstallieren. Für ntp nutzt Du systemd-timesyncd, und für rsyslog läuft sowieso schon systemd-journald. Und da es sich um einen PI handelt, solltest Du wirklich alle Schreibvorgänge auf die SD-Card des Regelbetriebs wie Logging komplett verlagern. Sonst schreibst Du Dir die SD-Card planmäßig kaputt.

[nephilim]

Hej Thomas,

wieder einmal vielen Dank:

(...) So heisst es bei Jessie nicht DHCP=yes, sondern DHCP=v4, und die (...)

Ich habe DHCP=yes in der Konfig stehen und das klappt (bisher).

Nachtrag, wenn Du systemd-networkd in Betrieb nehmen willst, musst Du allerdings vorher /etc/init.d/networking ausplanen.

Wie mache ich das?

(...) Und da es sich um einen PI handelt, solltest Du wirklich alle Schreibvorgänge auf die SD-Card des Regelbetriebs wie Logging komplett verlagern. Sonst schreibst Du Dir die SD-Card planmäßig kaputt.

Gerne. Leider muss ich auch hier fragen, wie ich das mache?

Danke im Voraus.

LG // neph

[jph]

Nachtrag, wenn Du systemd-networkd in Betrieb nehmen willst, musst Du allerdings vorher /etc/init.d/networking ausplanen.

Wie mache ich das?

Nicht networking ausplanen, sondern den standardmäßig aktiven NetworkManager:

Code: Alles auswählen

# systemctl disable NetworkManager.service

Dann brauchst du noch

Code: Alles auswählen

# systemctl enable systemd-resolved.service

und du musst /etc/resolv.conf löschen und als Symlink auf /run/systemd/resolve/resolv.conf neu anlegen.

Hier noch ein Beispiel, wie eine systemd-Unit bei statischer IP aussehen kann:

/etc/systemd/network/eth0.network:

Code: Alles auswählen

[Match]
Name=eth0

[Network]
DHCP=no
Address=192.168.178.2/24
Gateway=192.168.178.1
DNS=192.168.178.1

(...) Und da es sich um einen PI handelt, solltest Du wirklich alle Schreibvorgänge auf die SD-Card des Regelbetriebs wie Logging komplett verlagern. Sonst schreibst Du Dir die SD-Card planmäßig kaputt.

Gerne. Leider muss ich auch hier fragen, wie ich das mache?

Bspw. mit tmpfs. Ich lasse hier Apache seine Logs in eine RAM-Disk schreiben. Nach Neustart sind die Logs zwar weg, aber das ist m.E. zu verschmerzen.

/etc/fstab:

Code: Alles auswählen

tmpfs           /var/log/apache2        tmpfs   defaults,size=8M,mode=0750,uid=0,gid=4 0       0

Gegen das Kaputtschreiben der SD-Karte habe ich fstrim.timer eingeplant.

[TomL]

Nicht networking ausplanen, sondern den standardmäßig aktiven NetworkManager:

Code: Alles auswählen

# systemctl disable NetworkManager.service

Nein, der hat m.E. überhaupt nix damit zu tun. Den auszuplanen macht imho nur Sinn bei Verwendung statischer IPs, aber die würde ich lieber über den Router setzen. Wie gesagt, /etc/init.d/networking sollte daran gehindert werden, über die in /etc/network/interfaces vorhandenen Einstellungen eine Konflikt- oder Konkurrenzsituation zu systemd-networkd zu schaffen. Daher würde ich den Service auf jeden Fall ausplanen:

Code: Alles auswählen

systemctl disable networking

[TomL]

(...) Und da es sich um einen PI handelt, solltest Du wirklich alle Schreibvorgänge auf die SD-Card des Regelbetriebs wie Logging komplett verlagern. Sonst schreibst Du Dir die SD-Card planmäßig kaputt.

Gerne. Leider muss ich auch hier fragen, wie ich das mache?

http://www.forum-raspberrypi.de/Thread- ... #pid244564

[jph]

Ich muss dir widersprechen...

• networking.service solltest du nicht ausplanen, weil dir sonst bspw. lo verlorengeht, das in der /etc/network/interface konfiguriert ist. Natürlich müssen Konfigurationen für eth0 etc. in der interfaces auskommentiert werden, da hast du recht.
• NetworkManager muss ausgeplant werden, werden, wenn systemd-networkd die Interfaces verwalten soll, weil du sonst

  eine Konflikt- oder Konkurrenzsituation zu systemd-networkd

  schaffst. Du hast dann bspw. den Effekt, dass du in der systemd-Unit eine statische IP einstellst, das Gerät über NetworkManager aber trotzdem eine dynamische erhält. Das geht so weit, dass NetworkManager bei jedem Neustart eine neue Konfiguration für das Gerät erzeugt. BTDT.

Den auszuplanen macht imho nur Sinn bei Verwendung statischer IPs, aber die würde ich lieber über den Router setzen.

Die statische IP musst du im Client einstellen und nicht im Router.

Was du wahrscheinlich meinst, ist die Option, die bei einer Fritz!Box "diesem Client immer die gleiche IP zuweisen" o.ä. heißt. Dann nutzt man zwar DHCP, aber die Fritz!Box weist immer die gleiche IP zu, was unterm Strich wie eine statische IP wirkt. Der Client wird dabei anhand der MAC wiedererkannnt. Das ist aber was anderes als eine am Client statisch vorgegebene IP. (Bei letzterem sollte man vermeiden, eine IP aus dem Bereich, den der Router dynamisch vergibt, zu wählen. Bei einer Fritz!Box bieten sich in der Standardkonfiguration IPs zwischen 192.168.178.2 und 192.168.178.31 an, da diese nicht von der Fritz!Box per DHCP vergeben werden. Die sind explizit für statische IPs vorgesehen.)

[TomL]

Ich muss dir widersprechen...

• networking.service solltest du nicht ausplanen, weil dir sonst bspw. lo verlorengeht,

Warum weiss mein "lo" das nicht?

Code: Alles auswählen

# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> 

[dufty2]

Ich muss dir widersprechen...

• networking.service solltest du nicht ausplanen, weil dir sonst bspw. lo verlorengeht,

Warum weiss mein "lo" das nicht?

Code: Alles auswählen

# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> 

Bei Debian wird (via ifup?) automatisch das lo hochgenommen, auch wenn es z. B. in der "/etc/network/interfaces" auskommentiert ist.
Möglicherweise macht der networkmanager etwas ähnliches.

[TomL]

Bei Debian wird (via ifup?) automatisch das lo hochgenommen, auch wenn es z. B. in der "/etc/network/interfaces" auskommentiert ist.
Möglicherweise macht der networkmanager etwas ähnliches.

Bei mir wird das Netzwerk via systemd-networkd gestartet, ohne Networkmanager, den gibts bei mir gar nicht... und natürlich funktioniert auch das loopback-Device.... ganz ohne die '/etc/network/interfaces'. Ich wollte eigentlich nur aufzeigen, dass das Unsinn ist, zwei um die gleiche Hardware möglicherweise konkurrierenden Dienste zu starten. Wenn ich systemd-networkd nutze, sollte m.E. /etc/init.d/networking ausgeplant sein, und umgekehrt.

[nephilim]

(...) Und da es sich um einen PI handelt, solltest Du wirklich alle Schreibvorgänge auf die SD-Card des Regelbetriebs wie Logging komplett verlagern. Sonst schreibst Du Dir die SD-Card planmäßig kaputt.

Gerne. Leider muss ich auch hier fragen, wie ich das mache?

http://www.forum-raspberrypi.de/Thread- ... #pid244564

@TomL: In Deiner Anleitung beschreibst Du an einem Punkt, wie Du einen User hinzufügst:

Code: Alles auswählen

adduser thomas systemd-journal

Warum ist das notwendig? Kann der "root" user auf dem System das nicht von Haus aus?

LG // neph

[MSfree]

...solltest Du wirklich alle Schreibvorgänge auf die SD-Card des Regelbetriebs wie Logging komplett verlagern. Sonst schreibst Du Dir die SD-Card planmäßig kaputt.

Keine Panik verbreiten. Wenn die SD-Karte keinen Schlag durch statische Elektrizität bekommt, dauert das Kaputschreiben ca. 10 Jahren.

[detix]

@TomL: In Deiner Anleitung beschreibst Du an einem Punkt, wie Du einen User hinzufügst:
adduser thomas systemd-journal

Das ist falsch interpretiert.
Er ordnet damit dem schon vorhandenen user thomas nur die Gruppe systemd-journal zu,
soll heißen: auch der user thomas darf diese Logeinträge lesen.

[TomL]

...solltest Du wirklich alle Schreibvorgänge auf die SD-Card des Regelbetriebs wie Logging komplett verlagern. Sonst schreibst Du Dir die SD-Card planmäßig kaputt.

Keine Panik verbreiten. Wenn die SD-Karte keinen Schlag durch statische Elektrizität bekommt, dauert das Kaputschreiben ca. 10 Jahren.

Dazu gibt es halt unterschiedliche Meinungen.... insbesondere wird in den Raspi-Foren von Stammusern doch eher dazu geraten, die Schreibvorgänge bei einem 7/24-Betrieb zu minimieren. Und es gibt beispielsweise auch deutliche Aussagen über die Lebenszeit der SD-Cards bestimmter Hersteller.

Meine ganz persönliche Meinung dazu ist, wenn ich denen glaube, die die Schreibvorgänge minimieren, kann das keinesfalls einen vorzeitigen Schaden der SDC begünstigen, selbst wenn diese Unrecht hätten. Wenn ich jedoch denen glaube, die sagen, dass die Schreibvorgänge nicht limitiert werden müssten, so könnten diejenigen Recht haben, oder auch nicht. Aber wenn sie nicht recht haben, habe ich vielleicht den Schaden... oder eher gesagt die Mehrarbeit beim Neu-Aufsetzen des Systems. Also, ob das erstere was nutzt oder nicht, weiss ich nicht, aber es schadet definitiv nicht. Beim zweiten weiss ich auch auch nicht, ob die Aussage richtig oder falsch ist, aber es ist imho aber ein gewisses Risiko enthalten. Dann entscheide ich mich doch lieber für Variante 1 und minimiere die Schreibvorgänge.... zumal das gar keine Arbeit ist.

j.m.2.c .

[MSfree]

Dazu gibt es halt unterschiedliche Meinungen.... insbesondere wird in den Raspi-Foren von Stammusern doch eher dazu geraten, die Schreibvorgänge bei einem 7/24-Betrieb zu minimieren.

Die meisten Karten sterben durch Wackelkontakte und statische Elektrizität. Mir ist z.B. mal eine Karte verreckt, weil ich bei Raspi im vollen Betrieb versehentlich den Auswurfmechanismus der Kartenslots betätigt habe. Die Karte hatte hinterher nicht nur eine korruptes Dateisystem, sondern ein neues Image war gar nicht mehr drauf schreibbar.

Andererseits kann ich von mir klar behaupten, daß ich hier Rechner mir CF-Karten betreibe, die seit 10 Jahren mit der selben Karte im Einsatz sind. Und da wird nicht nur drauf gelogt sondern auch ein Squid-Cache drauf gehalten, ohne daß die 4GB-Karte mit fehldendem Wearlevelling und ohne besondere Schreibminimierung auch nur Ansätze von Schwäche zeigen würde.

Meine ganz persönliche Meinung dazu ist, wenn ich denen glaube, die die Schreibvorgänge minimieren, kann das keinesfalls einen vorzeitigen Schaden der SDC begünstigen, selbst wenn diese Unrecht hätten.

Man macht sicher nichts falsch, wenn man den üblichen Tipps folge leistet. Man sollte diese Tipps aber nicht überbewerten. In meinem Fall macht z.B. des Squid locker 90% der Schreibvorgänge aus, die Minimierungen wie Laptopmode und noatime reduzieren die Schreibvorgänge nur um wenige Prozentpunkte, was im Zweifelsfall eine 10 jährige Nutzung um ein halbes Jahr verlängert.