NFS-Client-Zugriff unter RHEL konfigurieren

Einführung

In diesem Lab lernen Sie die wesentlichen Fähigkeiten zur Konfiguration des NFS-Client-Zugriffs auf einem Red Hat Enterprise Linux (RHEL)-System kennen. Sie beginnen damit, einen Netzwerkspeicher manuell mit dem Befehl mount einzubinden, um den grundlegenden Prozess zu verstehen. Anschließend konfigurieren Sie eine persistente Einbindung in /etc/fstab, um sicherzustellen, dass der NFS-Share nach einem Systemneustart automatisch verfügbar ist, und erhalten so ein grundlegendes Verständnis der statischen Integration von Netzdateisystemen.

Aufbauend auf diesen Kernkonzepten werden Sie zu einer dynamischeren und effizienteren Methode übergehen, indem Sie den Automounter einrichten. Dies beinhaltet die Installation und Aktivierung des autofs-Dienstes sowie die Erstellung von indirekten Maps für die Einbindung von Verzeichnissen bei Bedarf und direkten Maps für statische Mount-Punkte. Sie werden das Lab abschließen, indem Sie überprüfen, ob sowohl direkte als auch indirekte Automounts für verschiedene Benutzer korrekt funktionieren, und so Ihre Fähigkeit zur Verwaltung robuster NFS-Client-Konfigurationen festigen.

NFS-Share manuell mit dem Befehl mount einhängen

In diesem Schritt lernen Sie, wie Sie mit dem Network File System (NFS)-Protokoll auf ein Netzwerk-freigegebenes Verzeichnis zugreifen. NFS ermöglicht es einem Client-System, über ein Computernetzwerk auf Dateien zuzugreifen, ähnlich wie auf lokalen Speicher zugegriffen wird. Für diese Übung simulieren wir sowohl einen NFS-Server als auch einen Client auf Ihrer lokalen Maschine, um die notwendigen Befehle zu üben.

Auf Ihrem System wurde ein NFS-Server vorkonfiguriert, um das Verzeichnis /srv/nfs/shared_data zu exportieren (freizugeben). Ihre Aufgabe ist es, dieses freigegebene Verzeichnis in einen lokalen Ordner einzuhängen, den Zugriff zu überprüfen und es dann auszuhängen.

Schritt 1.1: Erstellen eines lokalen Mount-Points

Um auf das freigegebene NFS-Verzeichnis zuzugreifen, benötigen Sie ein lokales Verzeichnis, das als "Mount-Point" dient. Dies ist im Wesentlichen ein leerer Ordner auf Ihrem Client-System, in dem die Inhalte des Remote-Shares nach dem Einhängen erscheinen. Alle Operationen werden innerhalb Ihres ~/project-Verzeichnisses durchgeführt.

Erstellen Sie ein Verzeichnis namens nfs_mount in Ihrem Projektordner:

mkdir ~/project/nfs_mount

Sie können überprüfen, ob das Verzeichnis erstellt wurde, indem Sie den Inhalt Ihres Projektordners auflisten:

ls -F ~/project

nfs_mount/

Schritt 1.2: Einhängen des NFS-Shares

Nun können Sie den Befehl mount verwenden, um den Remote-NFS-Share an Ihren neu erstellten Mount-Point anzuhängen. Der Befehl erfordert sudo-Berechtigungen, da das Einhängen von Dateisystemen eine systemweite Operation ist.

Die grundlegende Syntax lautet mount -t nfs <server>:<remote_directory> <local_mount_point>.

• -t nfs: Gibt an, dass der Dateisystemtyp NFS ist.
• localhost:/srv/nfs/shared_data: Die Quelle, d. h. der Server und der Pfad, den er exportiert.
• ~/project/nfs_mount: Das Ziel, d. h. Ihr lokaler Mount-Point.

Führen Sie den folgenden Befehl aus, um den Share einzuhängen:

sudo mount -t nfs localhost:/srv/nfs/shared_data ~/project/nfs_mount

Dieser Befehl erzeugt keine Ausgabe, wenn er erfolgreich ist.

Schritt 1.3: Überprüfen des Mounts und Interaktion mit dem Share

Nachdem Sie den Befehl mount ausgeführt haben, sollten Sie überprüfen, ob der Share korrekt eingehängt ist. Dies können Sie auf verschiedene Arten tun.

Verwenden Sie zunächst den Befehl mount, der an grep weitergeleitet wird, um nach NFS-Mounts zu filtern:

mount | grep nfs

localhost:/srv/nfs/shared_data on /home/labex/project/nfs_mount type nfs4 (rw,relatime,vers=4.2,rsize=...,wsize=...,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=...,local_lock=none,addr=...)

Überprüfen Sie als Nächstes den Inhalt Ihres Mount-Points. Er sollte nun die Dateien aus dem Remote-Verzeichnis /srv/nfs/shared_data anzeigen.

ls -l ~/project/nfs_mount

total 4
-rw-r--r--. 1 root root 32 Nov 10 14:30 welcome.txt

Sie können nun mit diesem Verzeichnis interagieren, als wäre es ein lokaler Ordner. Beachten Sie, dass in dieser Laborumgebung die Dateien aufgrund der NFS-Serverkonfiguration mit no_root_squash root gehören. In Produktionsumgebungen sehen Sie je nach NFS-Servereinstellungen möglicherweise nobody als Eigentümer. Erstellen wir eine neue Datei innerhalb des eingehängten Shares. Da der NFS-Share möglicherweise root gehört, müssen Sie sudo mit dem Befehl tee verwenden, um Dateien zu schreiben:

echo "My test file" | sudo tee ~/project/nfs_mount/my_file.txt > /dev/null

Überprüfen Sie, ob Ihre neue Datei neben der ursprünglichen vorhanden ist:

ls -l ~/project/nfs_mount

total 8
-rw-r--r--. 1 root  root  13 Nov 10 14:35 my_file.txt
-rw-r--r--. 1 root  root  32 Nov 10 14:30 welcome.txt

Schritt 1.4: Aushängen des NFS-Shares

Wenn Sie mit der Nutzung eines Netzwerk-Shares fertig sind, ist es wichtig, ihn mit dem Befehl umount sauber auszuhängen. Dies stellt sicher, dass alle Daten synchronisiert und die Verbindung ordnungsgemäß geschlossen werden. Sie müssen nur den Mount-Point angeben.

sudo umount ~/project/nfs_mount

Um zu bestätigen, dass der Share ausgehängt wurde, listen Sie den Inhalt des Verzeichnisses ~/project/nfs_mount auf. Es sollte nun wieder leer sein.

ls -l ~/project/nfs_mount

total 0

Einen persistenten NFS-Mount in /etc/fstab konfigurieren

Im vorherigen Schritt haben Sie gelernt, wie Sie einen NFS-Share manuell mit dem Befehl mount einhängen. Solche Mounts sind jedoch temporär und überleben keinen Systemneustart. Um einen Mount dauerhaft zu machen, müssen Sie einen Eintrag in die Datei /etc/fstab (kurz für "file systems table") aufnehmen. Diese Datei enthält eine Liste von Dateisystemen und Geräten, die beim Systemstart automatisch eingehängt werden.

In diesem Schritt konfigurieren Sie denselben NFS-Share so, dass er dauerhaft eingehängt wird, indem Sie einen Eintrag in /etc/fstab hinzufügen.

Schritt 2.1: Vorbereiten der Umgebung

Stellen Sie zunächst sicher, dass der Mount-Point aus dem vorherigen Schritt, ~/project/nfs_mount, existiert und leer ist. Wenn Sie direkt aus dem letzten Schritt fortfahren, sollte er bereits vorhanden sein.

Wenn das Verzeichnis nicht existiert, erstellen Sie es jetzt:

mkdir -p ~/project/nfs_mount

Stellen Sie außerdem sicher, dass derzeit nichts in dieses Verzeichnis eingehängt ist. Sie können den Befehl umount ausführen, der einen Fehler meldet, wenn es nicht eingehängt ist, und das ist völlig in Ordnung.

sudo umount ~/project/nfs_mount

Schritt 2.2: Bearbeiten der Datei /etc/fstab

Nun fügen Sie eine neue Zeile zur Datei /etc/fstab hinzu, um den persistenten NFS-Mount zu definieren. Sie müssen sudo verwenden, um diese Systemkonfigurationsdatei zu bearbeiten. Wir verwenden den nano-Editor.

Öffnen Sie die Datei mit dem folgenden Befehl:

sudo nano /etc/fstab

Navigieren Sie zum Ende der Datei und fügen Sie die folgende Zeile hinzu. Achten Sie sehr genau auf die Syntax, da Fehler in dieser Datei zu Problemen beim Systemstart führen können.

localhost:/srv/nfs/shared_data /home/labex/project/nfs_mount nfs defaults,_netdev 0 0

Lassen Sie uns diese Zeile aufschlüsseln:

• localhost:/srv/nfs/shared_data: Dies ist das zu mountende Gerät. Es gibt den NFS-Server (localhost) und das exportierte Verzeichnis (/srv/nfs/shared_data) an.
• /home/labex/project/nfs_mount: Dies ist der lokale Mount-Point, an dem der Share zugänglich sein wird.
• nfs: Dies gibt den Dateisystemtyp an.
• defaults,_netdev: Dies sind die Mount-Optionen. defaults enthält einen Standard-Satz von Optionen (wie rw für Lese-/Schreibzugriff). _netdev ist entscheidend für Netzdateisysteme; es teilt dem System mit, zu warten, bis das Netzwerk aktiv ist, bevor versucht wird, diesen Share einzuhängen.
• 0: Dies ist das dump-Feld, das vom dump-Backup-Dienstprogramm verwendet wird. Ein Wert von 0 deaktiviert es.
• 0: Dies ist das pass-Feld, das vom fsck-Dienstprogramm verwendet wird, um die Reihenfolge der Dateisystemprüfungen beim Booten zu bestimmen. Ein Wert von 0 bedeutet, dass das Dateisystem nicht überprüft wird.

Nachdem Sie die Zeile hinzugefügt haben, speichern Sie die Datei und beenden Sie nano, indem Sie Ctrl+X, dann Y und dann Enter drücken.

Schritt 2.3: Testen des /etc/fstab-Eintrags

Sie müssen das System nicht neu starten, um Ihren neuen /etc/fstab-Eintrag zu testen. Der Befehl mount ist schlau genug, um /etc/fstab zu lesen. Wenn Sie nur den Mount-Point angeben, sucht mount den entsprechenden Eintrag in /etc/fstab und verwendet die dort gefundenen Informationen.

Hängen Sie den Share mit nur dem Mount-Point ein:

sudo mount ~/project/nfs_mount

Wenn der Befehl ohne Fehler abgeschlossen wird, ist Ihr /etc/fstab-Eintrag korrekt.

Schritt 2.4: Überprüfen des Mounts

Überprüfen Sie, ob der Share nun eingehängt ist, indem Sie die Ausgabe des Befehls mount prüfen und den Inhalt des Verzeichnisses auflisten.

mount | grep nfs_mount

localhost:/srv/nfs/shared_data on /home/labex/project/nfs_mount type nfs4 (rw,relatime,vers=4.2,rsize=...,wsize=...,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=...,local_lock=none,addr=...,_netdev)

Überprüfen Sie nun den Inhalt. Sie sollten die Dateien aus dem Share sehen.

ls -l ~/project/nfs_mount

total 4
-rw-r--r--. 1 root root 32 Nov 10 14:30 welcome.txt

Dieser Mount ist nun persistent und würde nach einem Neustart automatisch wiederhergestellt werden.

Schritt 2.5: Bereinigen der Umgebung

Um Konflikte mit späteren Übungen zu vermeiden, sollten Sie nun die Änderungen rückgängig machen. Hängen Sie zuerst den Share aus und entfernen Sie dann die Zeile, die Sie aus /etc/fstab hinzugefügt haben.

Hängen Sie das Verzeichnis aus:

sudo umount ~/project/nfs_mount

Öffnen Sie /etc/fstab erneut, um den Eintrag zu entfernen:

sudo nano /etc/fstab

Verwenden Sie die Pfeiltasten, um zu der von Ihnen hinzugefügten Zeile (localhost:/srv/nfs/shared_data ...) zu navigieren, und drücken Sie Ctrl+K, um die gesamte Zeile zu löschen. Speichern und beenden Sie dann, indem Sie Ctrl+X, Y und Enter drücken.

Dadurch wird das System für den nächsten Teil des Labs in einem sauberen Zustand hinterlassen.

Automounter einrichten durch Installation und Aktivierung von autofs

In den vorherigen Schritten haben Sie manuelle und persistente Mounts untersucht. Während /etc/fstab hervorragend für dauerhafte Mounts geeignet ist, hat es einen Nachteil: Es versucht, alles beim Booten einzuhängen. Wenn ein Netz-Share nicht verfügbar ist, kann dies den Bootvorgang verlangsamen oder sogar stoppen. Der Automounter, der vom autofs-Dienst bereitgestellt wird, löst dieses Problem, indem er Netzdateisysteme bei Bedarf einhängt, nur wenn sie zum ersten Mal aufgerufen werden.

Der autofs-Dienst verwendet eine Reihe von Konfigurationsdateien, sogenannte "Maps", um zu bestimmen, welche Remote-Shares eingehängt werden sollen und wo. In diesem Schritt bereiten Sie Ihr System auf die Verwendung des Automounters vor, indem Sie das notwendige Paket installieren und seinen Dienst starten.

Schritt 3.1: Installieren des autofs-Pakets

Die autofs-Funktionalität ist nicht in der Standard-RHEL-Installation enthalten. Sie müssen sie mit dem dnf-Paketmanager installieren. Dies erfordert sudo-Berechtigungen.

Führen Sie den folgenden Befehl aus, um das autofs-Paket zu installieren. Das Flag -y beantwortet die Bestätigungsaufforderung automatisch mit "yes", was für dieses Labor praktisch ist.

sudo dnf install -y autofs

Der Befehl lädt das autofs-Paket und alle erforderlichen Abhängigkeiten herunter und installiert sie. Sie sehen eine Ausgabe, die der folgenden ähnelt:

Last metadata expiration check: ...
Dependencies resolved.
================================================================================
 Package       Architecture    Version                Repository           Size
================================================================================
Installing:
 autofs        x86_64          1:5.1.7-50.el9         ...                  ...
...

Transaction Summary
================================================================================
Install  1 Package

Total download size: ...
Installed size: ...
...
Complete!

Schritt 3.2: Starten des autofs-Dienstes

Auf einem Standard-RHEL-System würden Sie systemctl zum Starten und Aktivieren von Diensten verwenden. Dieses Labor läuft jedoch in einer containerisierten Umgebung, in der systemctl nicht verfügbar ist. Stattdessen starten wir den autofs-Daemon direkt mit seinem Befehl automount.

Dieser Befehl startet den Automounter-Daemon, der im Hintergrund läuft und auf Zugriffsversuche auf Verzeichnisse wartet, die in seinen Maps konfiguriert sind.

Führen Sie den folgenden Befehl aus, um den Dienst zu starten:

sudo automount

Wenn erfolgreich, erzeugt dieser Befehl keine Ausgabe. Er startet einfach den Daemon-Prozess.

Schritt 3.3: Überprüfen, ob der Dienst läuft

Da Sie systemctl status autofs nicht zur Überprüfung des Dienstes verwenden können, können Sie mit dem Befehl ps überprüfen, ob der automount-Prozess läuft. Der Befehl ps aux listet alle laufenden Prozesse auf, und wir können seine Ausgabe an grep weiterleiten (|), um nach dem automount-Prozess zu filtern.

ps aux | grep automount

Sie sollten mindestens eine Zeile für den automount-Prozess selbst sehen. Die zweite Zeile, die grep automount anzeigt, ist nur der grep-Befehl, den Sie ausgeführt haben, und kann ignoriert werden.

root      ...  0.0  0.0 ...      ?        Ssl  15:30   0:00 /usr/sbin/automount
labex     ...  0.0  0.0 ...      pts/0    S+   15:31   0:00 grep --color=auto automount

Das Vorhandensein des Prozesses /usr/sbin/automount bestätigt, dass der Dienst läuft und bereit ist, On-Demand-Mounts zu verarbeiten. In den nächsten Schritten konfigurieren Sie die Maps, die autofs mitteilen, was zu tun ist.

Eine indirekte Automount-Map für dynamische Verzeichnisse erstellen

In diesem Schritt konfigurieren Sie Ihre erste Automount-Regel mit einer indirekten Map. Eine indirekte Map ist der gebräuchlichste Typ der Automount-Konfiguration. Sie funktioniert, indem sie ein einzelnes Basisverzeichnis (wie /home oder /net) mit einer Map-Datei verknüpft. Wenn ein Benutzer versucht, auf ein Unterverzeichnis innerhalb dieses Basisverzeichnisses zuzugreifen, sucht autofs den Namen des Unterverzeichnisses in der Map-Datei und hängt den entsprechenden Remote-Share bei Bedarf ein.

Dies ist äußerst nützlich für das Einhängen von Benutzer-Home-Verzeichnissen oder einer Sammlung von gemeinsamen Projektordnern, ohne alle auf einmal einhängen zu müssen. Wir werden eine indirekte Map konfigurieren, um Projektverzeichnisse, die sich unter einem neuen Basisverzeichnis namens /project_shares befinden, dynamisch einzuhängen.

Schritt 4.1: Erstellen der NFS-Server-Exporte

Zuerst bereiten wir die Verzeichnisse auf unserem simulierten NFS-Server vor, die wir teilen möchten. Wir erstellen zwei Projektverzeichnisse, design und testing, innerhalb von /srv/nfs/.

Erstellen Sie die Verzeichnisse und legen Sie in jedem eine Beispieldatei ab:

sudo mkdir -p /srv/nfs/{design,testing}
sudo sh -c 'echo "Design documents" > /srv/nfs/design/README'
sudo sh -c 'echo "Testing scripts" > /srv/nfs/testing/README'

Als Nächstes müssen wir dem NFS-Server mitteilen, diese Verzeichnisse zu exportieren. Dies geschieht durch Hinzufügen von Einträgen zur Datei /etc/exports.

Öffnen Sie die Datei mit nano:

sudo nano /etc/exports

Fügen Sie die folgenden Zeilen zur Datei hinzu. Diese Zeilen weisen den NFS-Server an, die Verzeichnisse design und testing mit jedem Client (*) mit Lese-/Schreibberechtigungen (rw) zu teilen.

/srv/nfs/design *(rw,sync,no_root_squash)
/srv/nfs/testing *(rw,sync,no_root_squash)

Speichern Sie die Datei und beenden Sie sie (Ctrl+X, Y, Enter).

Wenden Sie schließlich die Änderungen auf den NFS-Server an, indem Sie alle Verzeichnisse neu exportieren:

sudo exportfs -ra

Schritt 4.2: Erstellen des Master-Map-Eintrags

Die autofs-Konfiguration beginnt mit der Master-Map-Datei /etc/auto.master. Es ist bewährte Praxis, diese Datei nicht direkt zu bearbeiten, sondern neue Konfigurationsdateien in das Verzeichnis /etc/auto.master.d/ zu legen.

Erstellen Sie eine neue Master-Map-Datei für unsere Projekt-Shares:

sudo nano /etc/auto.master.d/shares.autofs

Fügen Sie diese einzelne Zeile in diese Datei ein:

/project_shares /etc/auto.shares

Diese Zeile teilt autofs mit: "Für jeden Zugriff unter dem Verzeichnis /project_shares konsultieren Sie die Map-Datei unter /etc/auto.shares für Anweisungen."

Speichern und beenden Sie den Editor.

Schritt 4.3: Erstellen der indirekten Map-Datei

Erstellen Sie nun die indirekte Map-Datei /etc/auto.shares, auf die Sie gerade in der Master-Map verwiesen haben.

sudo nano /etc/auto.shares

Fügen Sie die folgenden Zeilen in diese Datei ein:

design  -fstype=nfs,rw,sync   localhost:/srv/nfs/design
testing -fstype=nfs,rw,sync   localhost:/srv/nfs/testing

Lassen Sie uns eine Zeile aufschlüsseln:

• design: Dies ist der "Schlüssel" (key). Er entspricht dem Namen des Unterverzeichnisses unter /project_shares. Wenn ein Benutzer auf /project_shares/design zugreift, wird diese Zeile ausgelöst.
• -fstype=nfs,rw,sync: Dies sind die Mount-Optionen, die den Dateisystemtyp, Lese-/Schreibzugriff und synchrone Schreibvorgänge angeben.
• localhost:/srv/nfs/design: Dies ist der Remote-NFS-Share-Speicherort, der eingehängt werden soll.

Speichern und beenden Sie den Editor.

Schritt 4.4: autofs neu laden und den Mount testen

Damit der autofs-Dienst Ihre neuen Map-Dateien erkennt, müssen Sie seine Konfiguration neu laden. Da systemctl nicht verfügbar ist, senden wir das HUP (hangup)-Signal an den automount-Prozess, was ihn veranlasst, seine Konfiguration neu zu lesen.

sudo killall -HUP automount

Testen wir es nun. Versuchen Sie zuerst, den Inhalt des Basisverzeichnisses /project_shares aufzulisten. Es wird leer erscheinen, da noch nichts eingehängt wurde.

ls -l /project_shares

total 0

Versuchen Sie als Nächstes, auf eines der Unterverzeichnisse zuzugreifen. Dies ist der Auslöser, der autofs dazu veranlasst, den Mount durchzuführen.

ls -l /project_shares/design

total 4
-rw-r--r--. 1 root root 17 Nov 10 16:10 README

Erfolg! Der design-Share wurde automatisch eingehängt. Wenn Sie nun das Basisverzeichnis erneut auflisten, sehen Sie das Verzeichnis design, da es ein aktiver Mount-Point ist.

ls -l /project_shares

total 0
dr-xr-xr-x. 2 root root 0 Nov 10 16:12 design

Machen Sie dasselbe für das testing-Verzeichnis, um zu bestätigen, dass es ebenfalls funktioniert:

ls -l /project_shares/testing

total 4
-rw-r--r--. 1 root root 16 Nov 10 16:10 README

Sie haben erfolgreich eine indirekte Automount-Map konfiguriert und getestet.

Eine direkte Automount-Map für statische Mount-Points erstellen

In diesem Schritt lernen Sie den zweiten Typ der Automount-Konfiguration kennen: eine direkte Map. Im Gegensatz zu einer indirekten Map, die mehrere Mounts unter einem gemeinsamen Basisverzeichnis gruppiert, definiert eine direkte Map spezifische, einzelne Mount-Punkte irgendwo im Dateisystem. Jeder Eintrag in einer direkten Map entspricht einem einzelnen, absoluten Pfad.

Direkte Maps sind nützlich für das Einhängen einer kleinen Anzahl von Shares an festen, bekannten Orten, wie z. B. das Einhängen eines gemeinsamen Tools-Verzeichnisses unter /usr/local/tools. Wir werden eine direkte Map konfigurieren, um ein gemeinsames common_data-Verzeichnis nach /mnt/common einzuhängen.

Schritt 5.1: Vorbereiten des NFS-Server-Exports

Wie zuvor müssen wir zuerst das Verzeichnis auf unserem simulierten NFS-Server vorbereiten, das wir teilen möchten. Wir erstellen ein Verzeichnis namens common_data.

Erstellen Sie das Verzeichnis und eine Beispieldatei darin:

sudo mkdir -p /srv/nfs/common_data
sudo sh -c 'echo "Common shared data" > /srv/nfs/common_data/info.txt'

Fügen Sie nun einen Eintrag zu /etc/exports hinzu, um dieses Verzeichnis über NFS verfügbar zu machen.

sudo nano /etc/exports

Fügen Sie die folgende neue Zeile zur Datei hinzu. Dies wird das Verzeichnis /srv/nfs/common_data freigeben.

/srv/nfs/common_data *(rw,sync,no_root_squash)

Speichern Sie die Datei und beenden Sie sie (Ctrl+X, Y, Enter).

Wenden Sie die Änderungen auf den NFS-Server an, indem Sie alle Verzeichnisse neu exportieren:

sudo exportfs -ra

Schritt 5.2: Erstellen des Master-Map-Eintrags für die direkte Map

Um eine direkte Map zu verwenden, müssen Sie sie zuerst aus der Master-Map-Konfiguration referenzieren. Der spezielle Mount-Punkt /- wird verwendet, um anzuzeigen, dass die zugehörige Map-Datei eine direkte Map ist.

Erstellen Sie eine neue Master-Map-Datei für unseren direkten Mount:

sudo nano /etc/auto.master.d/direct.autofs

Fügen Sie diese einzelne Zeile in diese Datei ein:

/- /etc/auto.direct

Diese Zeile teilt autofs mit: "Konsultieren Sie die Datei /etc/auto.direct für eine Liste direkter Mounts. Die Mount-Punkte sind absolute Pfade, die in dieser Datei definiert sind."

Speichern und beenden Sie den Editor.

Schritt 5.3: Erstellen der direkten Map-Datei

Erstellen Sie nun die direkte Map-Datei /etc/auto.direct, auf die Sie gerade verwiesen haben.

sudo nano /etc/auto.direct

Fügen Sie diese Zeile in diese Datei ein. Das Format ist etwas anders als bei einer indirekten Map.

/mnt/common -fstype=nfs,rw,sync   localhost:/srv/nfs/common_data

Analysieren wir diese Zeile:

• /mnt/common: Dies ist der "Schlüssel" (key), aber für eine direkte Map ist der Schlüssel der vollständige, absolute Pfad des Mount-Punktes.
• -fstype=nfs,rw,sync: Dies sind die Mount-Optionen, wie zuvor.
• localhost:/srv/nfs/common_data: Dies ist der Remote-NFS-Share-Speicherort.

Speichern und beenden Sie den Editor.

Schritt 5.4: autofs neu laden und den direkten Mount testen

Genau wie bei der indirekten Map müssen Sie die autofs-Konfiguration neu laden, damit sie die neue direkte Map erkennt.

sudo killall -HUP automount

Testen wir nun den direkten Mount. Im Gegensatz zu einer indirekten Map existiert der Mount-Punkt /mnt/common nicht im Dateisystem, bis Sie versuchen, darauf zuzugreifen.

Versuchen Sie, auf das Verzeichnis /mnt/common zuzugreifen. Dies löst autofs aus, um den Mount-Punkt zu erstellen und den Share einzuhängen.

ls -l /mnt/common

total 4
-rw-r--r--. 1 root root 19 Nov 10 17:00 info.txt

Erfolg! Der direkte Mount wurde bei Bedarf erstellt. Sie können ihn auch mit dem Befehl mount überprüfen:

mount | grep common

localhost:/srv/nfs/common_data on /mnt/common type nfs4 (rw,relatime,vers=4.2,rsize=...,wsize=...,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=...,local_lock=none,addr=...)

Sie haben nun erfolgreich sowohl eine indirekte Map für dynamische Unterverzeichnisse als auch eine direkte Map für einen statischen, absoluten Mount-Punkt konfiguriert.

Direkte und indirekte Automounts als verschiedene Benutzer überprüfen

In diesem letzten Schritt erfahren Sie, wie der Automounter in einer Multi-User-Umgebung funktioniert. Das Automounten macht einen Share verfügbar, aber die zugrunde liegenden Dateisystemberechtigungen auf dem NFS-Server steuern, wer tatsächlich auf die Dateien lesen oder schreiben kann. Sie erstellen ein paar Testbenutzer, weisen ihnen den Besitz der jeweiligen NFS-Shares zu und testen dann ihren Zugriff auf sowohl die indirekten als auch die direkten Maps.

Diese Übung demonstriert ein reales Szenario, in dem verschiedene Teams (z. B. Design und Testing) den Besitz ihrer jeweiligen gemeinsamen Verzeichnisse haben, wobei Lesezugriff für andere Benutzer verfügbar ist, aber Schreibzugriff auf den Besitzer beschränkt ist.

Schritt 6.1: Erstellen von Testbenutzern und Festlegen von Berechtigungen

Zuerst müssen Sie zwei neue Benutzer erstellen: designer1 und tester1. Sie legen auch ein einfaches Passwort für sie fest, damit Sie zu ihren Konten wechseln können.

Verwenden Sie den Befehl useradd, um die Benutzer zu erstellen. Das Flag -m erstellt ein Home-Verzeichnis für sie.

sudo useradd -m designer1
sudo useradd -m tester1

Legen Sie als Nächstes ein Passwort für jeden Benutzer fest. Der Einfachheit halber verwenden wir in diesem Lab das Passwort labex.io für beide (entspricht den Komplexitätsanforderungen einschließlich Länge, Groß-/Kleinschreibung, Zahlen und Sonderzeichen).

sudo passwd designer1
## Enter new UNIX password: labex.io
## Retype new UNIX password: labex.io
## passwd: password updated successfully

sudo passwd tester1
## Enter new UNIX password: labex.io
## Retype new UNIX password: labex.io
## passwd: password updated successfully

Ändern Sie nun den Besitz der freigegebenen Verzeichnisse auf der "Server"-Seite (/srv/nfs/*), um diesen neuen Benutzern Zugriff zu gewähren.

sudo chown -R designer1:designer1 /srv/nfs/design
sudo chown -R tester1:tester1 /srv/nfs/testing

Das Verzeichnis /srv/nfs/common_data bleibt im Besitz von root, wodurch es für normale Benutzer schreibgeschützt ist.

Schritt 6.2: Testen des Zugriffs als Benutzer designer1

Wechseln Sie zum Benutzerkonto designer1 mit dem Befehl su (substitute user). Das - stellt sicher, dass Sie die vollständige Login-Umgebung des Benutzers erhalten.

su - designer1
## Password: labex.io

Ihre Eingabeaufforderung ändert sich zu [designer1@host ~]$.

Testen Sie zuerst den Zugriff auf den design-Share über die indirekte Map. Dies sollte erfolgreich sein.

ls -l /project_shares/design

total 4
-rw-r--r--. 1 designer1 designer1 17 Jun 16 16:12 README

Versuchen Sie nun, eine Datei in dieses Verzeichnis zu schreiben. Dies sollte ebenfalls erfolgreich sein.

echo "My design file" > /project_shares/design/design_file.txt
ls -l /project_shares/design

total 8
-rw-r--r--. 1 designer1 designer1 15 Jun 16 16:18 design_file.txt
-rw-r--r--. 1 designer1 designer1 17 Jun 16 16:12 README

Versuchen Sie als Nächstes, auf den testing-Share zuzugreifen. Sie können den Inhalt sehen, aber nicht darauf schreiben, da er tester1 gehört.

ls -l /project_shares/testing

total 4
-rw-r--r--. 1 tester1 tester1 16 Jun 16 16:12 README

Testen Sie schließlich den direkt gemappten Share. designer1 sollte ihn lesen, aber nicht darauf schreiben können.

cat /mnt/common/info.txt

Common shared data

echo "test" > /mnt/common/new_file.txt

-bash: /mnt/common/new_file.txt: Permission denied

Beenden Sie die Sitzung von designer1, um zum Benutzer labex zurückzukehren.

exit

Schritt 6.3: Testen des Zugriffs als Benutzer tester1

Führen Sie nun ähnliche Tests als Benutzer tester1 durch.

su - tester1
## Password: labex.io

Greifen Sie auf den design-Share zu. Sie können den Inhalt einschließlich der von designer1 erstellten Datei sehen, aber nicht darauf schreiben.

ls -l /project_shares/design

total 8
-rw-r--r--. 1 designer1 designer1 15 Jun 16 16:18 design_file.txt
-rw-r--r--. 1 designer1 designer1 17 Jun 16 16:12 README

Greifen Sie nun auf den testing-Share zu und schreiben Sie darauf. Dies sollte erfolgreich sein, da tester1 dieses Verzeichnis besitzt.

ls -l /project_shares/testing

total 4
-rw-r--r--. 1 tester1 tester1 16 Jun 16 16:12 README

echo "My test script" > /project_shares/testing/test_script.sh
ls -l /project_shares/testing

total 8
-rw-r--r--. 1 tester1 tester1 16 Jun 16 16:12 README
-rw-r--r--. 1 tester1 tester1 15 Jun 16 16:19 test_script.sh

Beenden Sie die Sitzung von tester1.

exit

Schritt 6.4: Aufräumen der Umgebung

Um das Lab abzuschließen und das System in seinen ursprünglichen Zustand zurückzuversetzen, entfernen Sie die von Ihnen erstellten Testbenutzer. Der Befehl userdel -r entfernt den Benutzer und sein Home-Verzeichnis.

sudo userdel -r designer1
sudo userdel -r tester1

Damit ist das Lab zur Verwaltung von NFS mit autofs abgeschlossen.

Zusammenfassung

In diesem Lab lernen Sie, wie Sie den NFS-Client-Zugriff auf einem RHEL-System konfigurieren. Sie beginnen mit einem manuellen Mount, indem Sie zuerst einen lokalen Mount-Punkt erstellen und dann den Befehl mount verwenden, um eine Verbindung zum NFS-Share herzustellen. Nachdem Sie die manuelle Verbindung mit dem Befehl mount hergestellt haben, konfigurieren Sie einen persistenten Mount, indem Sie einen Eintrag in der Datei /etc/fstab erstellen, um sicherzustellen, dass der Share beim Booten automatisch eingehängt wird.

Darüber hinaus behandelt das Lab die Konfiguration von On-Demand-Mounts mit dem autofs-Dienst. Dies beinhaltet die Installation und Aktivierung des Dienstes sowie die Definition, wie Shares mit zwei verschiedenen Methoden eingehängt werden: Erstellung einer indirekten Map für das dynamische Einhängen von Verzeichnissen und einer direkten Map für das Einhängen von Shares an statischen, vordefinierten Orten. Der Prozess endet mit der Überprüfung, ob sowohl direkte als auch indirekte Automounts für verschiedene Benutzer korrekt funktionieren.