Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • S sys
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 20
    • Issues 20
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 13
    • Merge requests 13
  • Deployments
    • Deployments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • CHEF
  • cookbooks
  • sys
  • Issues
  • #5

Closed
Open
Created Jul 02, 2019 by m.pausch@m.pauschMaintainer

sys::systemd vs sys::network vs sys::networkd

Aktueller Zustand

Es gibt im Moment 3 recipes, die das Netzwerk einer Maschine konfigurieren:

  1. sys::network für debian_version kleiner 9
  2. sys::systemd für jessie(?) aufwärts
  3. sys::networkd für stretch aufwärts

sys::systemd und sys::networkd überschneiden sich, bieten aber unterschiedliche features an. In sys::networkd muss man alles manuell angeben, es gibt einen eigenen Namespace für die Attribute und auch ein eigenes Recipe. sys::systemd bietet allerlei praktische Schalter, mit denen man die aktuelle Konfiguration persistent machen kann.

Problem

Die Konfiguration die von sys::systemd ist subtil kaputt, weil ipv6 nicht mit ausreichender Gründlichkeit abgeschaltet wird. Das führt dazu, dass systemd-networkd-wait-online.service auf die Konfiguration von ipv6 wartet und dadurch nicht erfolgreich ausgeführt wird. Das führt oft zu Problemen mit nslcd, autofs und sonstigem was auf auf das Netzwerk wartet. Ausserdem ist mir nicht klar, warum sys::systemd überhaupt das Netzwerk konfigurieren sollte. sys::networkd bringt zwar viel Flexibilität, ist aber umständlich zu benutzen.

Lösungsvorschlag

Da systemd-networkd mit aktuellem Debian alle Features hat die man braucht, um auch kompliziertere config wie die lxgws und Hypervisoren zu bauen, würde ich folgendes vorschlagen:

  1. sys::network kann man wohl einfach so lassen, solange das noch benutzt wird.
  2. sys::systemd konfiguriert nur systemd (Dateien unter /etc/systemd/system und /etc/systemd/system.conf).
  3. sys::networkd wird mit den Features aus sys::systemd erweitert

Offene Punkte

Netzwerk managen?

Soll das Netzwerk prinzipiell gemanagt werden oder nicht? Bei der Installation bekommt man ja von FAI eine default-Konfiguration die normalerweise passt. Diese Konfiguration muss auch normalerweise nie geändert werden. Unter neuen Debian-Versionen würde ich vorschlagen alles mit systemd-networkd zu machen. Dazu muss man allerdings alle anderen Mechanismen abklemmen, wahlweise mit einem der folgenden Schritte:

  1. /etc/default/networking anpassen, so dass ifupdown kein netzwerk mehr konfiguriert
  2. /etc/network löschen oder umbenennen
  3. Debian Paket ifupdown deinstallieren
  4. Ggf. dhcpd oder sonst was deinstallieren oder abschalten. Prinzipiell gibt es nicht besonders viele Maschinen bei denen das Netzwerk bisher gemanaged wird, was wohl auch erklärt warum sich die recipes überschneiden und in gsi-sys mit Attributen konfiguriert werden die teilweise gar keine Auswirkungen haben.

Namensschema

Mit den neuen Interface-Namen, bei denen der Steckplatz im Rechner im Namen kodiert ist, sorgt dafür, dass die Interfaces in allen Rechnern anders heißen, was viele Dinge umständlich machen kann. Debian ist so voreingestellt, dass weiterhin das alte Namensschema verwendet wird. Maschinen die nicht das alte Schema haben, müssen allerdings eine neue initramfs bekommen und gebootet werden.

Edited Jul 02, 2019 by m.pausch
Assignee
Assign to
Time tracking

https://git.gsi.de is provided by CIT-HPC | GSI Helmholtzzentrum fuer Schwerionenforschung GmbH | Imprint (in German) | Privacy policy