NFS.SYSTEMD(7)

BEZEICHNUNG
nfs.systemd - NFS-Dienste mittels Systemd verwalten.

ÜBERSICHT
nfs-utils.service
nfs-server.service
nfs-client.target
etc

BESCHREIBUNG
Das Paket nfs-utils stellt eine Reihe von Unit-Dateien für systemd bereit, über die die verschiedenen Dienste gestartet und verwaltet werden können. Diese Unit-Dateien stellen sicher, dass die Dienste in der richtigen Reihenfolge gestartet werden und die Voraussetzungen erfüllt sind, bevor abhängige Dienste gestartet werden. Da es recht viele Unit-Dateien gibt, ist es nicht sofort ersichtlich, wie bestimmte Ergebnisse am besten erzielt werden können. In den folgenden Unterabschnitten wird versucht, die Fälle abzudecken, die höchstwahrscheinlich am häufigsten vorkommen.

  Konfiguration
Die Standard-Systemd-Unit-Dateien bieten keine leichte Möglichkeit, beliebige Befehlszeilenargumente an Daemons zur Konfiguration deren Verhaltens zu übergeben. In vielen Fällen können solche Konfigurationen durch die Vornahme von Änderungen an /etc/nfs.conf oder anderen Konfigurationsdateien durchgeführt werden. Wenn das nicht zweckmäßig ist, könnte eine Distribution Systemd-»Ergänzungsdateien« bereitstellen, die die ExecStart=-Einstellung zum Starten des Programmes mit anderen Argumenten ersetzen. Beispielsweise würde eine Ergänzungsdatei systemd/system/nfs-mountd.service.d/local.conf, die
    [Service]
    EnvironmentFile=/etc/sysconfig/nfs
    ExecStart=
    ExecStart= /usr/sbin/rpc.mountd $RPCMOUNTDOPTS
enthält, dazu führen, dass die Unit nfs-mountd.service das Programm rpc.mountd unter Verwendung der Argumente ausführt, deren Wert für RPCMOUNTDOPTS in /etc/sysconfig/nfs bereitgestellt wird. Dies erlaubt die nahtlose Integration mit existierenden Konfigurationswerkzeugen.

  Aktivierung von Unit-Dateien
Es gibt drei Unit-Dateien, die dafür gedacht sind, manuell gestartet zu werden. Alle anderen werden automatisch nach Bedarf gestartet. Diese drei sind:

nfs-client.target
    Diese Datei sollte auf jedem Rechner aktiviert werden, der jemals als NFS-Client dient. Es entsteht kaum Aufwand beim transparenten Aktivieren, jedes Mal wenn NFS-Client-Software installiert wird.

nfs-server.service
    Diese muss aktiviert sein, um NFS-Dienste für Clients bereitstellen zu können. Sie wird gestartet und konfiguriert die erforderlichen Daemons in der nötigen Reihenfolge.

nfs-blkmap.service
    Der Daemon blkmapd ist nur auf NFS-Clients erforderlich, die pNFS (paralleles NFS) und insbesondere das Layout-Protokoll blocklayout verwenden. Wenn Sie diese spezielle Erweiterung für NFS verwenden könnten, sollte die Unit nfs-blkmap.service aktiviert sein.

Mehrere andere Units, wie rpc-gssd.service, die als optional betrachtet werden könnten, achten darauf, nur zu starten, falls die benötigte Konfigurationsdatei existiert. rpc-gssd.service startet nicht, falls die (normalerweise in /etc liegende) Datei krb5.keytab nicht existiert.

  Neustarten von NFS-Diensten
Die meisten NFS-Daemons können jederzeit neu gestartet werden. Sie werden sämtlichen benötigten Zustand neu laden und weiterhin Anfragen bedienen. Allerdings wird dies selten benötigt.

Wenn Konfigurationsänderungen erfolgen, ist schwer feststellbar, welche Dienste neu gestartet werden müssen, damit die Konfiguration wirksam wird. Der einfachste und oft beste Ansatz ist, alles neu zu starten. Dabei hilft die bereitgestellte Unit nfs-utils.service. Sie erklärt geeignete Abhängigkeiten zu anderen Units, so dass
    systemctl restart nfs-utils
alle laufenden NFS-Daemons neu startet. Dadurch werden alle Konfigurationsänderungen wirksam, außer an den in /etc/fstab oder /etc/nfsmount.conf aufgeführten Einhängeoptionen. Einhängeoptionen können nur durch Aushängen und erneutes Einhängen des Dateisystems geändert werden. Dies kann störend sein und sollte nur durchgeführt werden, wenn der Nutzen den Aufwand rechtfertigt. Der Befehl
    umount -a -t nfs; mount -a -t nfs
sollte alle NFS-Dateisysteme aus- und neu wieder einhängen.

  Unerwünschte Dienste maskieren
Es kommt selten vor, dass einige Dienste von der Ausführung abgehalten werden sollen, obwohl sie normalerweise Teil eines funktionierenden NFS-Systems sind. Dies kann zur Reduzierung der Systemlast auf das absolut minimal notwendige oder zur Reduzierung der Angriffsfläche, durch Vermeidung von Daemons, die nicht absolut notwendig sind, erforderlich sein.

Auf drei bestimmte Dienste kann dies zutreffen: rpcbind, idmapd und rpc-gssd. rpcbind ist nicht Teil des Pakets nfs-utils, wird aber von mehreren NFS-Diensten verwandt. Allerdings wird es nicht benötigt, wenn nur NFSv4 im Einsatz ist. Falls ein Standort niemals NFSv3 (oder NFSv2) verwendet und nicht möchte, dass rpcbind ausgeführt wird, dann sollte Folgendes ausgeführt werden:
    systemctl mask rpcbind
Dadurch wird rpcbind deaktiviert und die verschiedenen NFS-Dienste, die davon abhängen (und nur für NFSv3 erforderlich sind), werden den Start verweigern, ohne die Aktionen der NFSv4-Dienste zu beeinflussen. Insbesondere rpc.statd wird nicht laufen, wenn rpcbind maskiert ist.

idmapd ist nur für NFSv4 erforderlich, und selbst in diesem Fall nicht, wenn der Client und der Server sich darüber geeinigt haben, Benutzerkennungen statt Benutzernamen zum Identifizieren der Dateieigentümer zu verwenden. Falls idmapd nicht gebraucht wird und nicht gewünscht ist, kann er mit folgendem Befehl maskiert werden:
    systemctl mask idmapd
Falls die Datei krb5.keytab vorhanden ist, wird davon ausgegangen, dass rpc-gssd benötigt wird. Falls an einem Standort die Datei vorhanden sein muss, aber rpc-gssd nicht ausgeführt werden soll, dann kann es wie folgt maskiert werden:
    systemctl mask rpc-gssd

DATEIEN
/etc/nfs.conf
/etc/nfsmount.conf
/etc/idmapd.conf

SIEHE AUCH
systemd.unit(5), nfs.conf(5), nfsmount.conf(5).

ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von Mario Blättermann <mario.blaettermann@gmail.com> und Helge Kreutzmann <debian@helgefjell.de> 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).