Konfiguration des NFS-Client-Zugriffs in RHEL

Einführung

In diesem Lab erlernen Sie die wesentlichen Fähigkeiten zur Konfiguration des NFS-Client-Zugriffs auf einem Red Hat Enterprise Linux (RHEL)-System. Sie beginnen damit, eine Netzwerkfreigabe manuell mit dem Befehl mount einzubinden, um den grundlegenden Prozess zu verstehen. Anschließend konfigurieren Sie einen persistenten Mount in /etc/fstab, um sicherzustellen, dass die NFS-Freigabe nach einem Systemneustart automatisch verfügbar ist, was Ihnen ein grundlegendes Verständnis der statischen Integration von Netzwerkdateisystemen vermittelt.

Aufbauend auf diesen Kernkonzepten gehen Sie zu einer dynamischeren und effizienteren Methode über, indem Sie den Automounter einrichten. Dies umfasst die Installation und Aktivierung des autofs-Dienstes sowie die Erstellung von indirekten Maps für das bedarfsgesteuerte Mounten von Verzeichnissen und direkten Maps für statische Mountpoints. Sie schließen das Lab ab, indem Sie überprüfen, ob sowohl direkte als auch indirekte Automounts für verschiedene Benutzer korrekt funktionieren, wodurch Sie Ihre Fähigkeit festigen, robuste NFS-Client-Konfigurationen zu verwalten.

Manuelles Mounten einer NFS-Freigabe mit dem Befehl mount

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

Ein NFS-Server wurde auf Ihrem System vorkonfiguriert, um das Verzeichnis /srv/nfs/shared_data zu exportieren (freizugeben). Ihre Aufgabe ist es, dieses freigegebene Verzeichnis in einen lokalen Ordner zu mounten, den Zugriff zu überprüfen und es anschließend wieder auszuhängen.

Schritt 1.1: Erstellen eines lokalen Mountpoints

Um auf das freigegebene NFS-Verzeichnis zuzugreifen, benötigen Sie ein lokales Verzeichnis, das als "Mountpoint" dient. Dies ist im Grunde ein leerer Ordner auf Ihrem Client-System, in dem die Inhalte der Remote-Freigabe erscheinen, sobald sie gemountet sind. 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: Mounten der NFS-Freigabe

Jetzt können Sie den Befehl mount verwenden, um die Remote-NFS-Freigabe an Ihren neu erstellten Mountpoint anzuhängen. Der Befehl erfordert sudo-Rechte, da das Mounten von Dateisystemen eine Operation auf Systemebene ist.

Die grundlegende Syntax lautet mount -t nfs -o vers=3 <server>:<remote_directory> <local_mount_point>.

• -t nfs -o vers=3: Gibt an, dass der Dateisystemtyp NFS ist und erzwingt NFSv3, das in dieser Lab-Umgebung das funktionierende Protokoll ist.
• localhost:/srv/nfs/shared_data: Die Quelle, also der Server und der Pfad, den er exportiert.
• ~/project/nfs_mount: Das Ziel, also Ihr lokaler Mountpoint.

Führen Sie den folgenden Befehl aus, um die Freigabe zu mounten:

sudo mount -t nfs -o vers=3 localhost:/srv/nfs/shared_data ~/project/nfs_mount

Dieser Befehl erzeugt bei Erfolg keine Ausgabe.

Schritt 1.3: Überprüfen des Mounts und Interaktion mit der Freigabe

Nachdem Sie den Befehl mount ausgeführt haben, sollten Sie überprüfen, ob die Freigabe korrekt gemountet wurde. Dies können Sie auf verschiedene Arten tun.

Verwenden Sie zuerst den Befehl mount in Kombination mit grep, um nach NFS-Mounts zu filtern:

mount | grep nfs

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

Überprüfen Sie anschließend den Inhalt Ihres Mountpoints. 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 Lab-Umgebung die Dateien aufgrund der NFS-Server-Konfiguration mit no_root_squash dem Benutzer root gehören. In Produktionsumgebungen sehen Sie je nach NFS-Server-Einstellungen möglicherweise nobody als Besitzer. Lassen Sie uns eine neue Datei innerhalb der gemounteten Freigabe erstellen. Da die NFS-Freigabe 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 existiert:

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 der NFS-Freigabe

Wenn Sie mit der Nutzung einer Netzwerkfreigabe fertig sind, ist es wichtig, sie sauber mit dem Befehl umount auszuhängen. Dies stellt sicher, dass alle Daten synchronisiert sind und die Verbindung ordnungsgemäß geschlossen wird. Sie müssen nur den Mountpoint angeben.

sudo umount ~/project/nfs_mount

Um zu bestätigen, dass die Freigabe 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

Konfiguration eines persistenten NFS-Mounts in /etc/fstab

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

In diesem Schritt konfigurieren Sie dieselbe NFS-Freigabe so, dass sie persistent gemountet wird, indem Sie einen Eintrag zu /etc/fstab hinzufügen.

Schritt 2.1: Vorbereiten der Umgebung

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

Falls das Verzeichnis nicht existiert, erstellen Sie es jetzt:

mkdir -p ~/project/nfs_mount

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

sudo umount ~/project/nfs_mount

Schritt 2.2: Bearbeiten der Datei /etc/fstab

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

Ö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. Seien Sie bei der Syntax sehr vorsichtig, 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,vers=3 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 Mountpoint, an dem die Freigabe zugänglich sein wird.
• nfs: Dies gibt den Dateisystemtyp an.
• defaults,_netdev,vers=3: Dies sind die Mount-Optionen. defaults enthält einen Standardsatz von Optionen (wie rw für Lesen/Schreiben). _netdev ist entscheidend für Netzwerkdateisysteme; es weist das System an, zu warten, bis das Netzwerk aktiv ist, bevor versucht wird, diese Freigabe zu mounten. vers=3 hält das Lab auf dem funktionierenden NFS-Protokoll für diese containerisierte Umgebung.
• 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 geprüft wird.

Nachdem Sie die Zeile hinzugefügt haben, speichern Sie die Datei und beenden Sie nano durch Drücken von Strg+X, dann Y und dann Enter.

Schritt 2.3: Testen des /etc/fstab-Eintrags

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

Mounten Sie die Freigabe nur mit dem Mountpoint:

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 die Freigabe jetzt gemountet 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 nfs (rw,relatime,vers=3,rsize=...,wsize=...,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,local_lock=none,addr=...,_netdev)

Überprüfen Sie nun den Inhalt. Sie sollten die Dateien aus der Freigabe 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 die Änderungen nun rückgängig machen. Hängen Sie zuerst die Freigabe aus und entfernen Sie dann die Zeile, die Sie in /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 ... vers=3 ...) zu navigieren, und drücken Sie Strg+K, um die gesamte Zeile zu löschen. Speichern und beenden Sie dann durch Drücken von Strg+X, Y und Enter.

Dies hinterlässt das System in einem sauberen Zustand für den nächsten Teil des Labs.

Einrichten des Automounters durch Installation und Aktivierung von autofs

In den vorherigen Schritten haben Sie das manuelle und persistente Mounten erkundet. Während /etc/fstab großartig für permanente Mounts ist, hat es einen Nachteil: Es versucht, alles beim Booten zu mounten. Wenn eine Netzwerkfreigabe nicht verfügbar ist, kann dies den Bootvorgang verlangsamen oder sogar anhalten. Der Automounter, bereitgestellt durch den autofs-Dienst, löst dieses Problem, indem er Netzwerkdateisysteme bei Bedarf mountet, nur wenn sie zum ersten Mal aufgerufen werden.

Der autofs-Dienst verwendet eine Reihe von Konfigurationsdateien, sogenannte "Maps", um zu bestimmen, welche Remote-Freigaben gemountet 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 Paketmanager dnf installieren. Dies erfordert sudo-Rechte.

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 Lab 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 ähnlich der folgenden:

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 verwenden, um Dienste zu starten und zu aktivieren. Dieses Lab 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 Versuche überwacht, auf Verzeichnisse zuzugreifen, die in seinen Maps konfiguriert sind.

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

sudo automount

Bei Erfolg 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 verwenden können, um den Dienst zu überprüfen, können Sie mit dem Befehl ps sicherstellen, dass der automount-Prozess läuft. Der Befehl ps aux listet alle laufenden Prozesse auf, und wir können seine Ausgabe mit | 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 zeigt, 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 Sehen des Prozesses /usr/sbin/automount bestätigt, dass der Dienst läuft und bereit ist, bedarfsgesteuerte Mounts zu verarbeiten. In den nächsten Schritten konfigurieren Sie die Maps, die autofs sagen, was zu tun ist.

Erstellen einer indirekten Automount-Map für dynamische Verzeichnisse

In diesem Schritt konfigurieren Sie Ihre erste Automount-Regel unter Verwendung einer indirekten Map. Eine indirekte Map ist der häufigste 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 mountet die entsprechende Remote-Freigabe bei Bedarf.

Dies ist äußerst nützlich, um Benutzer-Home-Verzeichnisse oder eine Sammlung von freigegebenen Projektordnern zu mounten, ohne alle auf einmal mounten zu müssen. Wir konfigurieren eine indirekte Map, um Projektverzeichnisse, die sich unter einem neuen Basisverzeichnis namens /project_shares befinden, dynamisch zu mounten.

Schritt 4.1: Erstellen der NFS-Server-Exporte

Bereiten wir zunächst die Verzeichnisse auf unserem simulierten NFS-Server vor, die wir freigeben 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, dass er diese Verzeichnisse exportieren soll. Dies tun wir, indem wir Einträge zur Datei /etc/exports hinzufügen.

Ö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 für jeden Client (*) mit Lese-Schreib-Berechtigungen (rw) freizugeben.

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

Speichern Sie die Datei und beenden Sie (Strg+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 im Verzeichnis /etc/auto.master.d/ hinzuzufügen.

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

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

Fügen Sie diese einzelne Zeile zur Datei hinzu:

/project_shares /etc/auto.shares

Diese Zeile sagt autofs: "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 diese Zeilen zur Datei hinzu:

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

Lassen Sie uns eine Zeile aufschlüsseln:

• design: Dies ist der "Schlüssel". Er entspricht dem Unterverzeichnisnamen unter /project_shares. Wenn ein Benutzer auf /project_shares/design zugreift, wird diese Zeile ausgelöst.
• -fstype=nfs,rw,sync,vers=3: Dies sind die Mount-Optionen, die den Dateisystemtyp, Lese-Schreib-Zugriff, synchrone Schreibvorgänge und die in dieser Lab-Umgebung verwendete NFS-Version angeben.
• localhost:/srv/nfs/design: Dies ist der Remote-NFS-Freigabeort, der gemountet werden soll.

Speichern und beenden Sie den Editor.

Schritt 4.4: Neuladen von autofs und Testen des Mounts

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 dazu veranlasst, seine Konfiguration neu einzulesen.

sudo killall -HUP automount

Lassen Sie uns das nun testen. Versuchen Sie zuerst, den Inhalt des Basisverzeichnisses /project_shares aufzulisten. Es wird leer erscheinen, da noch nichts gemountet 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 bringt, den Mount durchzuführen.

ls -l /project_shares/design

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

Erfolg! Die design-Freigabe wurde automatisch gemountet. Wenn Sie nun das Basisverzeichnis erneut auflisten, sehen Sie das design-Verzeichnis, da es ein aktiver Mountpoint ist.

ls -l /project_shares

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

Tun 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.

Erstellen einer direkten Automount-Map für statische Mountpoints

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, individuelle Mountpoints irgendwo im Dateisystem. Jeder Eintrag in einer direkten Map entspricht einem einzelnen, absoluten Pfad.

Direkte Maps sind nützlich, um eine kleine Anzahl von Freigaben an festen, bekannten Orten zu mounten, wie z. B. das Mounten eines freigegebenen Werkzeugverzeichnisses unter /usr/local/tools. Wir konfigurieren eine direkte Map, um ein freigegebenes common_data-Verzeichnis unter /mnt/common zu mounten.

Schritt 5.1: Vorbereiten des NFS-Server-Exports

Wie zuvor müssen wir zuerst das Verzeichnis auf unserem simulierten NFS-Server einrichten, das wir freigeben 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 diese neue Zeile zur Datei hinzu. Dies gibt das Verzeichnis /srv/nfs/common_data frei.

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

Speichern Sie die Datei und beenden Sie (Strg+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 zuerst in der Master-Map-Konfiguration darauf verweisen. Der spezielle Mountpoint /- 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 zur Datei hinzu:

/- /etc/auto.direct

Diese Zeile sagt autofs: "Konsultieren Sie die Datei /etc/auto.direct für eine Liste direkter Mounts. Die Mountpoints sind absolute Pfade, die innerhalb 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 zur Datei hinzu. Das Format unterscheidet sich leicht von einer indirekten Map.

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

Lassen Sie uns diese Zeile analysieren:

• /mnt/common: Dies ist der "Schlüssel", aber bei einer direkten Map ist der Schlüssel der vollständige, absolute Pfad des Mountpoints.
• -fstype=nfs,rw,sync,vers=3: Dies sind die Mount-Optionen, wie zuvor, einschließlich der in dieser Lab-Umgebung verwendeten NFS-Version.
• localhost:/srv/nfs/common_data: Dies ist der Remote-NFS-Freigabeort.

Speichern und beenden Sie den Editor.

Schritt 5.4: Neuladen von autofs und Testen des direkten Mounts

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

Lassen Sie uns nun den direkten Mount testen. Im Gegensatz zu einer indirekten Map existiert der Mountpoint /mnt/common nicht im Dateisystem, bis Sie versuchen, darauf zuzugreifen.

Versuchen Sie, auf das Verzeichnis /mnt/common zuzugreifen. Dies veranlasst autofs, den Mountpoint zu erstellen und die Freigabe zu mounten.

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. In dieser Lab-Umgebung ist die erfolgreiche Ausgabe von ls -l /mnt/common die zuverlässigste Bestätigung, da die Mount-Anzeige variieren kann, wenn NFS-Server und Client dieselbe Maschine sind.

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

Überprüfen direkter und indirekter Automounts als verschiedene Benutzer

In diesem letzten Schritt überprüfen Sie, wie der Automounter in einer Multi-User-Umgebung funktioniert. Automounting macht eine Freigabe verfügbar, aber es sind die zugrunde liegenden Dateisystemberechtigungen auf dem NFS-Server, die steuern, wer die Dateien tatsächlich lesen oder schreiben kann. Sie erstellen ein paar Testbenutzer, weisen ihnen den Besitz der jeweiligen NFS-Freigaben 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 freigegebenen 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 (erfüllt die Komplexitätsanforderungen einschließlich Länge, gemischter 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, was es für normale Benutzer schreibgeschützt macht.

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 die design-Freigabe ü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 die testing-Freigabe zuzugreifen. Sie können den Inhalt sehen, aber nicht hineinschreiben, da sie 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 die direkt gemountete Freigabe. designer1 sollte sie lesen, aber nicht hineinschreiben 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 designer1-Sitzung, um zum labex-Benutzer 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 die design-Freigabe zu. Sie können den Inhalt sehen, einschließlich der von designer1 erstellten Datei, aber nicht hineinschreiben.

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 die testing-Freigabe zu und schreiben Sie hinein. 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 tester1-Sitzung.

exit

Schritt 6.4: Bereinigen der Umgebung

Um das Lab abzuschließen und das System in seinen ursprünglichen Zustand zu versetzen, 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

Dies schließt das Lab zur Verwaltung von NFS mit autofs ab.

Zusammenfassung

In diesem Lab lernen Sie, den NFS-Client-Zugriff auf einem RHEL-System zu konfigurieren. Sie beginnen mit einem manuellen Mount, erstellen zuerst einen lokalen Mountpoint und verwenden dann den Befehl mount, um eine Verbindung zur NFS-Freigabe herzustellen. Nach der manuellen Verbindung mit dem Befehl mount konfigurieren Sie einen persistenten Mount, indem Sie einen Eintrag in der Datei /etc/fstab erstellen, wodurch sichergestellt wird, dass die Freigabe beim Booten automatisch gemountet wird.

Darüber hinaus behandelt das Lab die Konfiguration des bedarfsgesteuerten Mountens mit dem autofs-Dienst. Dies umfasst die Installation und Aktivierung des Dienstes sowie die Definition, wie Freigaben gemountet werden, unter Verwendung zweier verschiedener Methoden: Erstellen einer indirekten Map für das dynamische Mounten von Verzeichnissen und einer direkten Map für das Mounten von Freigaben an statischen, vordefinierten Orten. Der Prozess schließt mit der Überprüfung ab, dass sowohl direkte als auch indirekte Automounts für verschiedene Benutzer korrekt funktionieren.