SYSTEMD-RESOLVED.SERVICE(8)

BEZEICHNUNG
systemd-resolved.service, systemd-resolved - Verwalter für die Auflösung von Netzwerknamen

ÜBERSICHT

systemd-resolved.service

/lib/systemd/systemd-resolved

BESCHREIBUNG

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

SIGUSR1
    Beim 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
    https://tools.ietf.org/html/rfc3493

2.  RFC 6762
    https://tools.ietf.org/html/rfc6762

3.  Enhält /etc/resolv.conf beispielsweise

        nameserver 127.0.0.53
        search foobar.com barbar.com

    und wir suchen nach »localhost«, dann wird nss-dns die folgende Anfrage an systemd-resolved, das unter 127.0.0.53:53 auf Anfragen wartet: zuerst »localhost.foobar.com«, dann »localhost.barbar.com« und schließlich »localhost«. Falls die ersten zwei Abfragen (hoffentlich) fehlschlagen, wird systemd-resolved eine Anfrage für die dritte Anfrage synthetisieren.

    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 <debian@helgefjell.de> und Mario Blättermann <mario.blaettermann@gmail.com> erstellt.

Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 (https://www.gnu.org/licenses/gpl-3.0.html) 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 (debian-l10n-german@lists.debian.org).