Systemd-portabled: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
(Die Seite wurde neu angelegt: „=Links= *https://www.freedesktop.org/software/systemd/man/portablectl.html“)
 
 
Zeile 1: Zeile 1:
 +
=Exemplarische Vorgehensweise Portable Service=
 +
*systemd v239 enthält eine große Anzahl neuer Funktionen.
 +
*Einer davon ist der erstklassige Support für Portable Services.
 +
=Was sind „Portable Services“?=
 +
*Das „Portable Service“-Konzept lässt sich von klassischen chroot()-Umgebungen sowie dem Container-Management inspirieren
 +
*Es bringt zudemeine Reihe ihrer Funktionen in das regulärere Systemdienst-Management ein.
 +
*Das Konzept "Container" bietet hauptsächlich zwei Hauptmerkmale:
 +
=Ressourcenbündelung=
 +
*Ein Container bringt im Allgemeinen seinen eigenen Dateisystembaum mit
 +
*Diese werden gebündelt alle gemeinsam genutzten Bibliotheken und andere Ressourcen, die er möglicherweise benötigt, zusammen mit den ausführbaren Hauptdienstdateien.
 +
=Isolation und Sandboxing=
 +
*Ein Container arbeitet in einer Namespace-Umgebung, die relativ losgelöst vom Host ist.
 +
*Abgesehen davon, dass es in einem eigenen Dateisystem-Namensraum lebt, hat es normalerweise auch eine eigene Benutzerdatenbank, einen eigenen Prozessbaum und so weiter.
 +
*Der Zugriff vom Container auf den Host wird durch verschiedene Sicherheitstechnologien eingeschränkt.
 +
=Chroot=
 +
*Von diesen beiden Konzepten ist das erste auch das, worum es bei traditionellen UNIX-chroot()-Umgebungen geht.
 +
*Sowohl Ressourcenbündelung als auch Isolierung/Sandboxing sind Konzepte, die systemd seit längerem in unterschiedlichem Maße implementiert.
 +
*Insbesondere RootDirectory= und RootImage= gibt es schon seit langer Zeit, ebenso wie die verschiedenen Sandboxing-Funktionen, die systemd bereitstellt.
 +
*Das Konzept der Portable Service baut darauf auf und kombiniert diese Funktionen auf eine neue, integrierte Weise, um sie zugänglicher und benutzerfreundlicher zu machen.
 +
=Was genau ist ein "Portable Service"?=
 +
*Ähnlich wie ein Container-Image kann ein portabler Dienst auf der Festplatte nur ein Verzeichnisbaum sein,
 +
*Diese ausführbare Dienstdateien und alle ihre Abhängigkeiten in einer Hierarchie enthält, die der normalen Linux-Verzeichnishierarchie ähnelt.
 +
*Ein portabler Dienst kann auch ein Raw-Disk-Image sein, das ein Dateisystem enthält, das einen solchen Baum enthält (das über ein Loopback-Blockgerät gemountet werden kann),
 +
*Oder mehrere Dateisysteme (in diesem Fall müssen sie der Spezifikation für erkennbare Partitionen folgen und in einer GPT-Partitionstabelle befinden).
 +
*Unabhängig davon, ob der portable Dienst auf der Festplatte ein einfacher Verzeichnisbaum oder ein Raw-Disk-Image ist, nennen wir dieses Konzept das portable Service-Image.
 +
*Solche Images können mit jedem Tool generiert werden, das normalerweise zum Installieren von Betriebssystemen in einem bestimmten Verzeichnis verwendet wird,
 +
*beispielsweise dnf --installroot= oder debootstrap.
 +
*An diese Bäume werden nur sehr wenige Anforderungen gestellt, mit Ausnahme der folgenden beiden:
 +
*Der Baum sollte systemd-Unit-Dateien für relevante Dienste enthalten.
 +
*Der Baum sollte /usr/lib/os-release (oder /etc/os-release) OS-Versionsinformationen enthalten.
 +
*Natürlich, qualifizieren sich OS-Bäume, die von einer der heutigen großen Distributionen generiert wurden, im Allgemeinen für diese beiden Anforderungen ohne weitere Modifikationen,
 +
*Da so ziemlich alle von ihnen /usr/lib/os-release übernommen haben und dazu neigen, ihre Hauptdienste bereitzustellen mit systemd-Unit-Dateien.
 +
*Ein so generiertes portables Service-Image kann von einem Host „angehängt“ oder „getrennt“ werden:
 +
 +
*Das „Anhängen“ eines Bildes an einen Host erfolgt über den neuen Befehl „portablectl attach“.
 +
*Dieser Befehl zerlegt das Image, liest die OS-Release-Informationen und sucht darin nach Unit-Dateien.
 +
*Es kopiert dann relevante Unit-Dateien aus den Images und in /etc/systemd/system/.
 +
*Danach werden alle kopierten Service-Unit-Dateien auf zwei Arten erweitert:
 +
*Ein Drop-In fügt eine RootDirectory=- oder RootImage=-Zeile hinzu, sodass die Unit-Dateien, obwohl sie jetzt auf dem Host verfügbar sind, beim Start die referenzierten Binärdateien von ausführen Bild. Es enthält auch symbolische Links in einem zweiten Drop-In, das als "Profil" bezeichnet wird und zusätzliche Sicherheitseinstellungen enthalten soll, um die angehängten Dienste durchzusetzen, um das richtige Maß an Sandboxing sicherzustellen.
 +
 +
*Das „Trennen“ eines Bildes vom Host erfolgt durch portables Trennen.
 +
*Es kehrt die obigen Schritte um:
 +
*Die herauskopierten Unit-Dateien werden wieder entfernt, ebenso wie die beiden Drop-in-Dateien, die dafür generiert werden.
 +
 +
*Während ein portabler Dienst angehängt wird, werden seine relevanten Unit-Dateien wie alle anderen auf dem Host verfügbar gemacht:
 +
*Sie erscheinen in systemctl list-unit-files,
 +
*Sie können sie aktivieren und deaktivieren,
 +
*Sie können sie starten und stoppen.
 +
*Sie können sie mit systemctl edit erweitern.
 +
*Sie können sie introspizieren.
 +
*Sie können die Ressourcenverwaltung auf sie wie auf jeden anderen Dienst anwenden, und Sie können ihre Protokolle wie jeden anderen Dienst verarbeiten und so weiter.
 +
*Das liegt daran, dass es sich wirklich um native systemd-Dienste handelt, außer dass sie, wenn Sie so wollen, einen „Twist“ haben: Sie haben standardmäßig eine strengere Sicherheit und speichern ihre Ressourcen in einem Stammverzeichnis oder Image.
 +
*Und das ist bereits die Essenz dessen, was Portable Services sind.
 +
 +
Ein paar interessante Punkte:
 +
 +
Auch wenn der Schwerpunkt auf dem Versand von Service-Unit-Dateien in portablen Service-Images liegt, können Sie tatsächlich Timer-Units, Socket-Units, targ
 +
 +
 
=Links=
 
=Links=
 
*https://www.freedesktop.org/software/systemd/man/portablectl.html
 
*https://www.freedesktop.org/software/systemd/man/portablectl.html

Aktuelle Version vom 3. Januar 2023, 12:49 Uhr

Exemplarische Vorgehensweise Portable Service

  • systemd v239 enthält eine große Anzahl neuer Funktionen.
  • Einer davon ist der erstklassige Support für Portable Services.

Was sind „Portable Services“?

  • Das „Portable Service“-Konzept lässt sich von klassischen chroot()-Umgebungen sowie dem Container-Management inspirieren
  • Es bringt zudemeine Reihe ihrer Funktionen in das regulärere Systemdienst-Management ein.
  • Das Konzept "Container" bietet hauptsächlich zwei Hauptmerkmale:

Ressourcenbündelung

  • Ein Container bringt im Allgemeinen seinen eigenen Dateisystembaum mit
  • Diese werden gebündelt alle gemeinsam genutzten Bibliotheken und andere Ressourcen, die er möglicherweise benötigt, zusammen mit den ausführbaren Hauptdienstdateien.

Isolation und Sandboxing

  • Ein Container arbeitet in einer Namespace-Umgebung, die relativ losgelöst vom Host ist.
  • Abgesehen davon, dass es in einem eigenen Dateisystem-Namensraum lebt, hat es normalerweise auch eine eigene Benutzerdatenbank, einen eigenen Prozessbaum und so weiter.
  • Der Zugriff vom Container auf den Host wird durch verschiedene Sicherheitstechnologien eingeschränkt.

Chroot

  • Von diesen beiden Konzepten ist das erste auch das, worum es bei traditionellen UNIX-chroot()-Umgebungen geht.
  • Sowohl Ressourcenbündelung als auch Isolierung/Sandboxing sind Konzepte, die systemd seit längerem in unterschiedlichem Maße implementiert.
  • Insbesondere RootDirectory= und RootImage= gibt es schon seit langer Zeit, ebenso wie die verschiedenen Sandboxing-Funktionen, die systemd bereitstellt.
  • Das Konzept der Portable Service baut darauf auf und kombiniert diese Funktionen auf eine neue, integrierte Weise, um sie zugänglicher und benutzerfreundlicher zu machen.

Was genau ist ein "Portable Service"?

  • Ähnlich wie ein Container-Image kann ein portabler Dienst auf der Festplatte nur ein Verzeichnisbaum sein,
  • Diese ausführbare Dienstdateien und alle ihre Abhängigkeiten in einer Hierarchie enthält, die der normalen Linux-Verzeichnishierarchie ähnelt.
  • Ein portabler Dienst kann auch ein Raw-Disk-Image sein, das ein Dateisystem enthält, das einen solchen Baum enthält (das über ein Loopback-Blockgerät gemountet werden kann),
  • Oder mehrere Dateisysteme (in diesem Fall müssen sie der Spezifikation für erkennbare Partitionen folgen und in einer GPT-Partitionstabelle befinden).
  • Unabhängig davon, ob der portable Dienst auf der Festplatte ein einfacher Verzeichnisbaum oder ein Raw-Disk-Image ist, nennen wir dieses Konzept das portable Service-Image.
  • Solche Images können mit jedem Tool generiert werden, das normalerweise zum Installieren von Betriebssystemen in einem bestimmten Verzeichnis verwendet wird,
  • beispielsweise dnf --installroot= oder debootstrap.
  • An diese Bäume werden nur sehr wenige Anforderungen gestellt, mit Ausnahme der folgenden beiden:
  • Der Baum sollte systemd-Unit-Dateien für relevante Dienste enthalten.
  • Der Baum sollte /usr/lib/os-release (oder /etc/os-release) OS-Versionsinformationen enthalten.
  • Natürlich, qualifizieren sich OS-Bäume, die von einer der heutigen großen Distributionen generiert wurden, im Allgemeinen für diese beiden Anforderungen ohne weitere Modifikationen,
  • Da so ziemlich alle von ihnen /usr/lib/os-release übernommen haben und dazu neigen, ihre Hauptdienste bereitzustellen mit systemd-Unit-Dateien.
  • Ein so generiertes portables Service-Image kann von einem Host „angehängt“ oder „getrennt“ werden:
  • Das „Anhängen“ eines Bildes an einen Host erfolgt über den neuen Befehl „portablectl attach“.
  • Dieser Befehl zerlegt das Image, liest die OS-Release-Informationen und sucht darin nach Unit-Dateien.
  • Es kopiert dann relevante Unit-Dateien aus den Images und in /etc/systemd/system/.
  • Danach werden alle kopierten Service-Unit-Dateien auf zwei Arten erweitert:
  • Ein Drop-In fügt eine RootDirectory=- oder RootImage=-Zeile hinzu, sodass die Unit-Dateien, obwohl sie jetzt auf dem Host verfügbar sind, beim Start die referenzierten Binärdateien von ausführen Bild. Es enthält auch symbolische Links in einem zweiten Drop-In, das als "Profil" bezeichnet wird und zusätzliche Sicherheitseinstellungen enthalten soll, um die angehängten Dienste durchzusetzen, um das richtige Maß an Sandboxing sicherzustellen.
  • Das „Trennen“ eines Bildes vom Host erfolgt durch portables Trennen.
  • Es kehrt die obigen Schritte um:
  • Die herauskopierten Unit-Dateien werden wieder entfernt, ebenso wie die beiden Drop-in-Dateien, die dafür generiert werden.
  • Während ein portabler Dienst angehängt wird, werden seine relevanten Unit-Dateien wie alle anderen auf dem Host verfügbar gemacht:
  • Sie erscheinen in systemctl list-unit-files,
  • Sie können sie aktivieren und deaktivieren,
  • Sie können sie starten und stoppen.
  • Sie können sie mit systemctl edit erweitern.
  • Sie können sie introspizieren.
  • Sie können die Ressourcenverwaltung auf sie wie auf jeden anderen Dienst anwenden, und Sie können ihre Protokolle wie jeden anderen Dienst verarbeiten und so weiter.
  • Das liegt daran, dass es sich wirklich um native systemd-Dienste handelt, außer dass sie, wenn Sie so wollen, einen „Twist“ haben: Sie haben standardmäßig eine strengere Sicherheit und speichern ihre Ressourcen in einem Stammverzeichnis oder Image.
  • Und das ist bereits die Essenz dessen, was Portable Services sind.

Ein paar interessante Punkte:

Auch wenn der Schwerpunkt auf dem Versand von Service-Unit-Dateien in portablen Service-Images liegt, können Sie tatsächlich Timer-Units, Socket-Units, targ


Links