BEZEICHNUNG
systemd-resolved.service, systemd-resolved - Verwalter für die Auflösung von NetzwerknamenÜBERSICHT
systemd-resolved.service /lib/systemd/systemd-resolvedBESCHREIBUNG
systemd-resolved ist ein Systemdienst, der Netzwerknamensauflösung für lokale Anwendungen anbietet. Er implementiert einen zwischenspeichernden und prüfenden DNS/DNSSEC-Stub-Resolver sowie einen LLMNR- und MulticastDNS-Resolver und -Beantworter. Lokale Anwendungen können Netzwerknamensauflösungsanfragen über drei Schnittstellen einreichen:•systemd-resolved legt das
native, vollfunktionale API auf dem Bus offen. Siehe
org.freedesktop.resolve1(5) und org.freedesktop.LogControl1(5)
für Details. Die Verwendung dieser API wird Clients im allgemeinen
empfohlen, da sie asynchron und vollfunktional ist (sie liefert beispielsweise
DNSSEC-Überprüfungsstatus und Schnittstellengeltungsbereiche,
wie dies für die Unterstützung link-lokaler Vernetzung notwendig
ist).
•Das Glibc getaddrinfo(3)-ABI
wie in RFC3493[1] definiert sowie verwandte Resolver-Funktionen,
einschließlich gethostbyname(3). Das API wird breit
unterstützt, auch über die Linux-Plattform hinaus. In seiner
aktuellen Form legt es allerdings
DNSSEC-Überprüfungsstatusinformationen nicht offen und ist nur
synchron. Diesem API unterliegt der Glibc Name Service Switch (
nss(5)). Die Verwendung des Glibc-NSS-Moduls nss-resolve(8) wird
benötigt, um den NSS-Resolverfunktionen von Glibc zu erlauben,
Rechnernamen mittels systemd-resolved aufzulösen.
•Zusätzlich stellt
systemd-resolved einen lokalen DNS-Stub bereit, der auf den IP-Adressen
127.0.0.53 und 127.0.0.54 auf der lokalen Loopback-Schnittstelle auf Anfragen
wartet. Programme, die DNS-Anfragen direkt stellen und sämtliche API
umgehen, können auf diesen Stub gerichtet werden, um sie mit
systemd-resolved zu verbinden. Beachten Sie, dass nachdrücklich
empfohlen wird, dass lokale Programme stattdessen das Glibc-NSS oder die
Bus-API (wie oben beschrieben) verwenden, da verschiedene
Netzwerk-Auflösungskonzepte (wie linklokale Adressierung oder
LLMNR-Unicode-Domains) nicht auf das unicast DNS-Protokoll abgebildet werden
können.
Der DNS-Stub-Resolver auf 127.0.0.53 stellt den vollständigen
Funktionalitätsumfang des lokalen Resolvers bereit,
einschließlich LLMNR/MulticastDNS-Auflösung. Der
DNS-Stub-Resolver auf 127.0.0.54 stellt einen begrenzteren Resolver bereit,
der nur im »Proxy«-Modus arbeitet, d.h. er wird die meisten
DNS-Nachrichten recht unverändert an den aktuellen vorgelagerten
DNS-Server weitergeben (und zurück), abernicht versuchen, die
Nachrichten lokal zu verarbeiten und damit nicht die Gültigkeit von
DNSSEC zu überprüfen oder LLMNR/MulticastDNS anzubieten. (Falls
notwendig wird er aber auf DNS-über-TLS-Kommunikation
übersetzen.)
Die kontaktierten DNS-Server werden aus den globalen Einstellungen in
/etc/systemd/resolved.conf, den linkabhängigen statischen Einstellungen
in »/etc/systemd/network/*.network«-Dateien (falls
systemd-networkd.service(8) verwandt wird), den über DHCP
empfangenen linkabhängigen dynamischen Einstellungen, über
resolvectl(1) bereitgestellte Informationen und sämtlichen
DNS-Server-Informationen, die durch andere Systemdienste verfügbar
gemacht werden, bestimmt. Siehe resolved.conf(5) und
systemd.network(5) für Details über Systemds eigene
Konfigurationsdateien für DNS-Server. Zur Verbesserung der
Kompatibilität wird /etc/resolv.conf gelesen, um konfigurierte
System-DNS-Server zu entdecken, aber nur falls sie kein Symlink auf
/run/systemd/resolve/stub-resolv.conf, /usr/lib/systemd/resolv.conf oder
/run/systemd/resolve/resolv.conf ist (siehe unten).
SYNTHETISCHE DATENSÄTZE
systemd-resolved synthetisiert DNS-Ressourcendatensätze (RR) für die folgenden Fälle:•Der lokale, konfigurierte Rechnername
wird auf alle lokal konfigurierten IP-Adressen, sortiert nach ihrem
Geltungsbereich, oder, falls keine konfiguriert sind, die IPv4-Adresse
127.0.0.2 (die auf der lokalen Loopback-Schnittstelle ist) und die
IPv6-Adresse ::1 (die auf dem lokalen Rechner ist), aufgelöst.
•Die Rechnernamen
»localhost« und »localhost.localdomain« sowie alle
auf ».localhost« oder ».localhost.localdomain«
endenden Rechnernamen werden auf die IP-Adressen 127.0.0.1 und ::1
aufgelöst.
•Der Rechnername
»_gateway« wird auf alle aktuellen
Standard-Routing-Gateway-Adressen, sortiert nach ihrer Metrik,
aufgelöst. Dies weist dem aktuellen Gateway einen stabilen Rechnernamen
zu, was zur Referenzierung unabhängig von dem aktuellen
Netzwerkkonfigurationszustand nützlich ist.
•Der Rechnername
»_outbound« wird auf die lokalen IPv4- und IPv6-Adressen
aufgelöst, die am wahrscheinlichsten für die Kommunikation mit
anderen Rechnern verwandt werden. Dies wird bestimmt, indem vom Kernel eine
Routing-Entscheidung für die konfigurierten Vorgabe-Gateways erbeten
wird und dann die lokale IP-Adresse durch diese Entscheidung ausgewählt
wird. Dieser Rechnername ist nur verfügbar, falls es mindestens ein
konfiguriertes lokales Vorgabe-Gateway gibt. Dies weist der lokalen,
auswärtsgerichteten IP-Adresse einen stabilen Rechnernamen zu. Das ist
nützlich, um diesen Namen unabhängig vom Zustand der aktuellen
Netzwerkkonfiguration zu referenzieren.
•Die in /etc/hosts definierten
Abbildungen werden zu ihren konfigurierten Adressen und zurück
aufgelöst, sie werden aber nicht Auflösungen für Typen,
die keine Adressen sind (wie MX), beeinflussen. Die Unterstützung
für /etc/hosts kann mit ReadEtcHosts=no deaktiviert werden,
siehe resolved.conf(5).
PROTOKOLLE UND ROUTING
Die von systemd-resolved.service empfangenen Auflösungsanfragen werden an die verfügbaren DNS-Server und LLMNR- und MulticastDNS-Schnittstellen gemäß den folgenden Regeln weitergeleitet:•Namen, für die
künstliche Datensätze erstellt werden (der lokale Rechnername,
»localhost« und »localdomain«, das lokale Gateway,
wie im vorherigen Abschnitt dargestellt), und in /etc/hosts konfigurierte
Adressen werden niemals zu dem Netzwerk geleitet und es wird sofort eine
Antwort gesandt.
•Freistehende Namen werden mittels
LLMNR auf allen lokalen Schnittstellen aufgelöst, auf denen LLMNR
aktiviert ist. Abfragen für IPv4-Adressen werden nur mittels LLMNR auf
IPv4 gesandt und Abfragen für IPv6-Adressen werden nur mittels LLMNR
auf IPv6 gesandt. Beachten Sie, dass Abfragen für freistehende
synthetisierte Namen nicht an LLMNR, MulticastDNS oder unicast DNS gesandt
werden.
•Anfragen für
Adressdatensätze (A und AAAA) von freistehenden, nicht-synthetisierte
Namen werden über Unicast-DNS mittels Such-Domains aufgelöst.
Für jede Schnittstelle, für die Such-Domains definiert sind,
werden solche Abfragen zu für diese Schnittstelle definierten Servern
geleitet, wobei jeder diese Such-Domains angehängt wird. Wenn globale
Such-Domains definiert sind, werden solche Abfragen an alle die globalen
Server geleitet. Für jede Such-Domain werden die Abfrage der Reihe nach
durch Anhängen der Such-Domain an den Namen durchgeführt.
Zusätzlich kann das Abfragen von freistehenden Namen mittels unicast
DNS mit der Einstellung ResolveUnicastSingleLabel=yes aktiviert werden.
Die Details, welche Server abgefragt und wie die abschließende Antwort
ausgewählt werden, ist nachfolgend beschrieben. Beachten Sie, dass dies
bedeutet, dass Adressabfragen für freistehende Namen
standardmäßig niemals an ferne DNS-Server gesandt werden und
fehlschlagen werden, falls keine Such-Domains definiert sind.
•Mehrgliedrige Namen mit der
Domain-Endung ».local« werden mittels MulticastDNS auf allen
lokalen Schnittstellen, auf denen MulticastDNS aktiviert ist,
aufgelöst. Wie bei LLMNR werden IPv4-Adressabfragen mittels IPv4 und
IPv6-Adressabfragen mittels IPv6 gesandt.
•Abfragen für mehrgliedrige
Namen werden mittels Unicast-DNS auf lokalen Schnittstellen weitergeleitet,
die einen DNS-Server konfiguriert haben, sowie den global konfigurierten
DNS-Servern, falls vorhanden. Welche Schnittstellen verwandt werden wird durch
die Routing-Logik, basierend auf den Such- und Nur-Route-Domains, bestimmt,
wie nachfolgend beschrieben. Beachten Sie, dass standardmäßig
Abfragen für Domains mit der Endung ».local« nicht an
DNS-Server weitergeleitet werden, außer die Domain wird explizit als
Routing- oder Such-Domain für den DNS-Server und die -Schnittstelle
festgelegt. Das bedeutet, dass explizite Such- und Routing-Domains bei
Netzwerken, bei denen die Domain ».local« in einem
Site-spezifischen DNS-Server definiert ist, konfiguriert werden müssen,
damit Abfragen innerhalb dieser DNS-Domain funktionieren. Beachten Sie, dass
heutzutage es im Allgemeinen empfohlen wird, die Definition von
».local« in einem DNS-Server zu vermeiden, da RFC 6762[2]
diese Domain für die exklusive MulticastDNS-Verwendung
reserviert.
•Adressabfragen (inverse Abfragen)
werden ähnlich wie bei mehrgliedrigen Namen weitergeleitet,
außer dass Adressen von linklokalen Adressbereichen niemals zu
Unicast-DNS weitergeleitet und nur mittels LLMNR und MulticastDNS (falls
aktiviert) aufgelöst werden.
Falls Abfragen über mehrere Schnittstellen geroutet werden, wird die
erste erfolgreiche Antwort zurückgeliefert (und damit die Abfragezonen
auf allen passenden Schnittstellen effektiv zusammengeführt). Falls die
Abfrage auf allen Schnittstellen fehlschlug, wird die letzte fehlgeschlagene
Antwort zurückgeliefert.
Das Routing von Abfragen wird durch die schnittstellenbezogenen Routing-Domains
(Such und Nur-Route) und globale Such-Domains bestimmt. Siehe
systemd.network(5) und resolvectl(1) für eine
Beschreibung, wie diese Einstellungen dynamisch gesetzt werden und der
Diskussion von Domains= in resolved.conf(5) für eine
Beschreibung von global konfigurierten DNS-Einstellungen.
Die folgende Anfrage-Routing-Logik gilt für Unicast-DNS-Verkehr, der von
systemd-resolved.service veranlasst wird:
•Falls ein abzufragender Name auf eine
der konfigurierten Weiterleitungs-Domains (Such- oder nur-Weiterleitung) eines
Links oder auf die global konfigurierten DNS-Einstellungen passt (das
bedeutet, er ist identisch zu oder hat eine Endung), dann wird die am
»besten passende« Weiterleitungs-Domain bestimmt: die passende
mit den meisten Anteilen. Die Abfrage wird dann an alle DNS-Server jedes Links
oder dem global konfigurierten DNS-Server, der dieser »am besten
passenden«-Weiterleitungs-Domain zugeordnet ist, gesandt. (Beachten
Sie, dass mehr als ein Link die gleiche »am besten passende«
Weiterleitungs-Domain konfiguriert haben kann. In diesem Fall wird die Anfrage
parallel an alle davon gesandt.)
Im Falle von freistehenden Namen wird die gleiche Logik angewandt, wenn
Such-Domains definiert sind, außer dass dem Namen der Reihe nach jede
Such-Domain angehängt wird. Beachten Sie, dass diese Suchlogik auf
keinen Namen angewandt wird, der mindestens einen Punkt enthält. Lesen
Sie auch die Diskussion über die Kompatibilität zu dem
traditionellen Glibc-Resolver weiter unten.
•Falls eine Abfrage auf keine
konfigurierte Routing-Domain passt (weder linklokal noch global) wird sie an
alle DNS-Server, die auf Links mit gesetzter Option DefaultRoute=
konfiguriert sind, sowie an alle global konfigurierten DNS-Server
versandt.
•Falls kein Link als
DefaultRoute= und kein globaler DNS-Server konfiguriert ist, wird einer
der einkompilierten Ausweich-DNS-Server verwandt.
•Andernfalls schlägt die
Unicast-DNS-Anfrage fehl, da keine geeigneten DNS-Server ermittelt werden
konnten.
Die Option DefaultRoute= ist eine logische Einstellung, die mit
resolvectl oder in .network-Dateien konfiguriert werden kann. Falls
nicht gesetzt, wird sie implizit basierend auf den für einen Link
konfigurierten DNS-Domains bestimmt: falls es eine nur-routbare Domains
außer »~.« gibt, ist die Vorgabe falsch, andernfalls
wahr.
Effektiv bedeutet dies: Um nicht künstlich erzeugte freistehende Namen zu
unterstützen, definieren Sie geeignete Such-Domains. Um bevorzugt alle
DNS-Anfragen weiterzuleiten, die nicht explizit auf eine bestimmte
Routing-Domain, die für einen bestimmten Link konfiguriert ist, passen,
konfigurieren Sie eine nur-routbare »~.« darauf. Dies stellt
sicher, dass andere Links für diese Abfragen nicht
berücksichtigt werden (außer auch sie tragen eine solche
Routing-Domain). Um alle solchen DNS-Anfragen zu einem bestimmten Link zu
routen, nur falls kein anderer Link bevorzugt wird, setzen Sie die Option
DefaultRoute= für den Link auf wahr und konfigurieren Sie keine
nur-routbare Domain »~.« darauf. Um schließlich
sicherzustellen, dass ein bestimmter Link niemals irgendwelchen DNS-Verkehr,
der nicht auf seine konfigurierten Routing-Domains passt, erhält,
setzen sie für ihn die Option DefaultRoute= auf falsch.
Siehe org.freedesktop.resolve1(5) für Information über die
D-Bus-APIs, die Systemd-resolved bereitstellt.
KOMPATIBILITÄT ZU DEM TRADITIONELLEN GLIBC-STUB-RESOLVER
Dieser Abschnitt stellt eine kurze Zusammenfassung der Unterschiede zwischen dem in nss-resolve(8) zusammen mit systemd-resolved implementierten Stub-Resolver und dem traditionellen, in nss-dns implementierten Stub-Resolver bereit.•Einige Namen werden immer intern
aufgelöst (siehe Synthetische Datensätze oben). Traditionell
würden sie durch nss-files aufgelöst, falls sie in /etc/hosts
bereitgestellt würden. Beachten Sie aber, dass die Details der
Zusammenstellung der Abfrage der Steuerung der Client-Bibliothek unterliegt.
nss-dns wird zuerst versuchen, Namen mittels Such-Domains aufzulösen,
und selbst wenn diese Anfragen an systemd-resolved geleitet werden, wird
dieser sie an das Netzwerk gemäß den normalen Regeln für
das Routen von mehrgliedrigen Namen senden [3].
•Freistehende Namen werden für
A- und AAAA-Datensätze nicht mittels Unicast-DNS aufgelöst
(außer dies wurde mit ResolveUnicastSingleLabel= außer
Kraft gesetzt, siehe resolved.conf(5)). Dies ist ähnlich der in
resolv.conf(5) gesetzten Option no-tld-query.
•Such-Domains werden nicht zum
Anhängen bei mehrgliedrigen Namen benutzt. (Trotzdem werden
Such-Domains für das Routing von Abfragen und für Namen,
die ursprünglich als freistehend oder mehrgliedrig festgelegt wurden,
verwandt.) Jeder Name, der mindestens einen Punkt enthält, wird immer
als FQDN interpretiert. Nss-dns würde Namen sowohl als relative
(mittels Such-Domains) und absolute FQDN-Namen auflösen. Einige Namen
würden zuerst als relativ aufgelöst und nachdem die Anfrage
fehlschlug, als absolut, während andere Namen in der umgekehrten
Reihenfolge aufgelöst würden. Die Option ndots in
/etc/resolv.conf wurde verwandt, um zu steuern, wie viele Punkte der Name
haben muss, damit er zuerst als relativer Name aufgelöst würde.
Dieser Stub-Resolver implementiert dies überhaupt nicht: mehrgliedrige
Namen werden nur als FQDNs aufgelöst.[4]
•Dieser Resolver kennt das Konzept der
besonderen Domain ».local«, die für MulticastDNS verwandt
wird, und wird keine Abfragen mit dieser Endung an Unicast-DNS-Server
weiterleiten, außer dies wird explizit konfiguriert, siehe oben. Auch
werden inverse Abfragen für linklokale Adressen nicht an
Unicast-DNS-Server gesandt.
•Dieser Resolver liest /etc/hosts und
speichert es intern zwischen. (Mit anderen Worten, nss-resolve ersetzt
nss-files zusätzlich zu nss-dns). Einträge in /etc/hosts haben
die höchste Priorität.
•Dieser Resolver implementiert
zusätzlich zum klassischen Unicast-DNS-Protokoll auch LLMNR und
MulticastDNS und wird freistehende Namen mittels LLMNR (wenn aktiviert) und
auf ».local« endende Namen mittels MulticastDNS (wenn aktiviert)
auflösen.
•Die in resolv.conf(5)
beschriebenen Umgebungsvariablen $LOCALDOMAIN und $RES_OPTIONS
werden derzeit nicht unterstützt.
/ETC/RESOLV.CONF
Es werden vier Modi beim Umgang mit /etc/resolv.conf (siehe resolv.conf(5)) unterstützt:•systemd-resolved verwaltet die
Datei /run/systemd/resolve/stub-resolv.conf zur Kompatibilität mit
traditionellen Linux-Programmen. Diese Datei führt den DNS-Stub
127.0.0.53 als einzigen DNS-Server auf. Sie enthält auch eine Liste der
Such-Domains, die im Gebrauch durch Systemd-resolved sind. Die Liste der
Such-Domains wird immer aktuell gehalten. Beachten Sie, dass
/run/systemd/resolve/stub-resolv.conf von Anwendungen nicht direkt, sondern
nur durch den Symlink /etc/resolv.conf verwandt werden soll. Diese Datei kann
ein Symlink von /etc/resolv.conf sein, um alle lokalen Clients, die die
DNS-API umgehen, mit systemd-resolved mit korrekten
Such-Domain-Einstellungen zu verbinden. Dieser Betriebsmodus wird
empfohlen.
•Eine statische Datei
/usr/lib/systemd/resolv.conf wird bereitgestellt, die den DNS-Stub 127.0.0.53
(siehe oben) als einzigen DNS-Server aufführt. Diese Datei kann ein
Symlink von /etc/resolv.conf sein, um alle lokalen Clients, die die lokale
DNS-API umgehen, mit systemd-resolved zu verbinden. Diese Datei
enthält keine Such-Domains.
•systemd-resolved verwaltet die
Datei /run/systemd/resolve/stub-resolv.conf zur Kompatibilität mit
traditionellen Linux-Programmen. Diese Datei darf ein Symlink von
/etc/resolv.conf sein und wird immer aktuell gehalten. Sie enthält alle
bekannten DNS-Server. Beachten Sie die Beschränkungen des Dateiformats:
es kennt kein Konzept schnittstellenbezogenener DNS-Server und enthält
daher nur systemweite DNS-Server-Definitionen. Beachten Sie, dass
/run/systemd/resolve/stub-resolv.conf von Anwendungen nicht direkt, sondern
nur durch den Symlink /etc/resolv.conf verwandt werden soll. Falls dieser
Betriebsmodus verwandt wird, werden lokale Clients, die sämtliche
lokale DNS-APIs umgehen, auch systemd-resolved umgehen und direkt mit
bekannten DNS-Servern kommunizieren.
•Alternativ kann /etc/resolv.conf von
anderen Paketen verwaltet werden. In diesem Fall wird systemd-resolved
sie für DNS-Konfigurationsdaten auslesen. In diesem Betriebsmodus ist
systemd-resolved Konsument statt Anbieter dieser
Konfigurationsdaten.
Beachten Sie, dass der ausgewählte Betriebsmodus für diese Datei
vollautomatisch erkannt wird, abhängig davon, ob /etc/resolv.conf ein
Symlink auf /run/systemd/resolve/resolv.conf ist oder 127.0.0.53 als
DNS-Server aufführt.
SIGNALE
SIGUSR1Beim Empfang des Prozesssignals SIGUSR1
wird systemd-resolved die Inhalte aller von ihm verwalteten
DNS-Ressourcedatensatzzwischenspeicher sowie sämtliche
Funktionsstufeninformationen, die es über konfigurierte DNS-Server
herausfand, in das Systemprotokoll ausgeben.
SIGUSR2
Beim Empfang des Prozesssignals SIGUSR2
wird systemd-resolved die Inhalte aller von ihm verwalteten
Zwischenspeicher ausgeben. Beachten Sie, dass es normalerweise nicht notwendig
sein sollte, dies explizit anzufragen – außer zur Fehlersuche
–, da systemd-resolved sowieso jedes Mal, wenn sich die
Netzwerkkonfiguration des Rechners ändert, seine Zwischenspeicher
automatisch leert. Senden dieses Signals an systemd-resolved ist
äquivalent zu dem Befehl resolvectl flush-caches, allerdings
wird Letzterer empfohlen, da er synchron arbeitet.
SIGRTMIN+1
Beim Empfang des Prozesssignals
SIGRTMIN+1 wird systemd-resolved alles, was es über die
konfigurierten DNS-Server gelernt hat, vergessen. Insbesondere alle
Informationen über Server-Funktionalitätsunterstützung
werden entfernt, und die Ermittlungslogik für die
Serverfunktionalität wird bei der nächsten Anfrage neu
gestartet, beginnend mit der am höchsten augestatteten Funktionsstufe.
Beachten Sie, dass es normalerweise nicht notwendig sein sollte, dies explizit
anzufragen – außer zur Fehlersuche –, da
systemd-resolved sowieso jedes Mal, wenn sich die
DNS-Serverkonfiguration ändert, die gelernten Informationen vergisst.
Senden dieses Signals an systemd-resolved ist äquivalent zu dem
Befehl resolvectl reset-server-features, allerdings wird Letzterer
empfohlen, da er synchron arbeitet.
SIEHE AUCH
systemd(1), resolved.conf(5), dnssec-trust-anchors.d(5), nss-resolve(8), resolvectl(1), resolv.conf(5), hosts(5), systemd.network(5), systemd-networkd.service(8)ANMERKUNGEN
- 1.
- RFC 3493
- 2.
- RFC 6762
- 3.
- Enhält /etc/resolv.conf beispielsweise
nameserver 127.0.0.53
search foobar.com barbar.com
Wird nss-dns mit einer Such-Domain eingesetzt,
ist es daher essenziell, immer nss-files mit einer höheren
Priorität zu konfigurieren und Abbildungen für Namen
bereitzustellen, die nicht mittels Such-Domains aufgelöst werden
sollen.
- 4.
- Es gibt derzeit mehr als 1.500 Domain-Namen oberster Stufe und regelmäßig werden neue hinzugefügt, oft mittels »attraktiver« Namen, die wahrscheinlich auch lokal verwandt werden. Indem mehrgliedrige Namen auf diese Art nicht nachgeschlagen werden, wird in beide Richtungen Zerbrechlichkeit vermieden: ein gültiger globaler Name könnte durch einen lokalen Namen verschleiert werden und die Auflösung eines relativen lokalen Namens könnte plötzlich fehlschlagen, wenn eine neue Domain auf oberster Stufe erstellt wird oder wenn eine neue Unter-Domain einer Domain oberster Stufe registriert wird. Durch Auflösen jedes übergebenen Namens als entweder relativ oder absolut wird diese Mehrdeutigkeit vermieden.
ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <[email protected]> und Mario Blättermann <[email protected]> erstellt. Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen. Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Übersetzer| systemd 252 |