Cloud Intelligence™Cloud Intelligence™

Cloud Intelligence™

NFS auf Linux-Instanzen automatisch einbinden

By Sayle MatthewsJul 20, 20208 min read

Diese Seite ist auch in English, Español, Français, Italiano, 日本語 und Português verfügbar.

1 fl0wtntavgxuf3yqbi5owg

Vor ein paar Wochen begegnete mir ein vermeintlich exotischer Anwendungsfall: Bei der Migration vieler VMs aus meinem Home Lab nach Kubernetes wollte ich ein NFS-Volume automatisch in eine Linux-Maschine oder einen Docker-Container einbinden.

Hintergrund war, dass ich den Backing Store von InfluxDB, MySQL und Grafana auf mein NAS auslagern wollte, statt ihn auf dem lokalen Dateisystem des jeweiligen Geräts liegen zu lassen. NFS setze ich in meinem Netzwerk häufig ein, um Dateien zwischen mehreren Geräten zu teilen – einfach, weil es unkompliziert ist und von praktisch jedem Gerät unterstützt wird.

Nachdem ich das in meinem Home Lab eingerichtet hatte, wurde mir klar, dass dieser Anwendungsfall doch gar nicht so exotisch ist – schließlich kommt NFS weltweit massenhaft zum Einsatz. In einer Cloud-Umgebung lässt sich damit ein On-Premise-NFS-Share einbinden, um Daten abzuziehen, Prozessen lesenden oder schreibenden Zugriff auf einen NFS-Share zu geben, Home-Verzeichnisse von Nutzern per NFS einzubinden – und für unzählige weitere Szenarien.

Das Problem – und der Schlüssel zum automatischen Mounten

Zuerst ging ich den Weg, den ich am besten kannte: fstab, das ich seit Jahrzehnten immer wieder einsetze. Schnell zeigte sich aber, dass das NFS-Mount nicht rechtzeitig eingebunden wurde, damit die Datenbank-Daemons darauf zugreifen konnten – mit erheblichen Folgeproblemen.

Genau da stieß ich auf das Linux-Paket autofs. Es zum Laufen zu bringen, war einiges an Bastelarbeit, denn viele Anleitungen im Netz waren veraltet oder ließen entscheidende Details aus. Diese Anleitung zeigt direkt, wie es geht, damit Sie keinen halben Tag damit verbringen müssen – Zeit ist schließlich das, was in unserer Branche immer am knappsten ist.

Im Kern ist autofs schlicht ein Daemon, der Shares im Hintergrund bei Bedarf automatisch ein- und wieder aushängt. Anders als bei fstab passiert das auf Anforderung – also auch beim Booten, ohne dass man sich um die Startreihenfolge der Daemons Gedanken machen muss.


Voraussetzungen

Der Einfachheit halber gehe ich in dieser Anleitung davon aus, dass Sie bereits einen NFS-Server auf Ihrem NAS oder einer Linux-Maschine betreiben oder einen Dienst wie Google Clouds Filestore als NAS nutzen.

Halten Sie die vollständigen NFS-Share-Pfade für jeden Share bereit, den Sie hinzufügen möchten. Manchmal sehen sie anders aus als gedacht – also lieber zweimal prüfen. Auf Synology-NAS-Systemen ist beispielsweise das Volume vorangestellt, etwa /volume1/share_path.

Die Befehle in dieser Anleitung beziehen sich auf Debian-basierte Distributionen, funktionieren also mit Debian, Ubuntu, Kali usw. In jedem Abschnitt ergänze ich den passenden Befehl für Red-Hat-basierte Distributionen, damit Sie als RHEL- oder CentOS-Nutzer nichts umrechnen müssen.

Bitte beachten Sie: NFS-Sicherheitspraktiken behandle ich in dieser Anleitung bewusst nicht – das Thema ist so umfangreich, dass es den Umfang der Anleitung locker verdoppeln würde. Wichtig ist es trotzdem, gar keine Frage – aber ich klammere es hier aus und empfehle Ihnen, sich einzulesen, um die Sicherheit nach dem ersten Setup so umzusetzen, wie es am besten zu Ihrer Organisation passt. Wenn Sie tiefer einsteigen möchten, ist dieser Einsteiger-Artikel von Red Hat ein guter Startpunkt: hier.


Das Vorgehen

  1. Installieren Sie das autofs-Paket mit dem passenden Befehl für Ihre Distribution:

    Ubuntu: `sudo apt -y install nfs-common autofs

    Red Hat: sudo yum -y install nfs-common autofs`

  2. Öffnen Sie die Datei /etc/auto.master in Ihrem bevorzugten Editor.

  3. Scrollen Sie ans Ende der Datei und fügen Sie für jeden gewünschten Mount eine Zeile wie diese hinzu. Ersetzen Sie dabei das Wort share in auto.share durch Ihren Wunschnamen:

    `/- /etc/auto.share -nosuid,noowners

    `(Sie können zur besseren Lesbarkeit gerne weitere Leerzeichen einfügen – Medium erlaubt in Code-Blöcken innerhalb nummerierter Listen leider nur ein einzelnes Leerzeichen.)

  4. Als Nächstes legen Sie die Dateien an, die Sie im vorherigen Schritt referenziert haben. Sie liegen alle unter /etc und folgen dem Format auto.[share_name]. Für jede oben hinzugefügte auto.share-Zeile öffnen Sie also die entsprechende Datei in Ihrem bevorzugten Texteditor und legen sie an. Tragen Sie dort folgende Zeile ein und ersetzen Sie Share-Name (ich persönlich lege alles unter /mnt ab, das können Sie aber nach Belieben anpassen), Servername und Share-Pfad:

    `/mnt/[share_name] -fstyle=nfs,user,nolock,nosuid,rw [server_name]:[share_path]

    `(Auch hier können Sie für die Lesbarkeit mehr Leerzeichen einfügen. Wenn Sie nur lesenden statt lesend-schreibenden Zugriff wollen, ändern Sie das obige rw in ro.)

  5. Anschließend starten Sie den autofs-Dienst mit folgendem Befehl neu:

    Ubuntu: sudo service autofs restart

    Red Hat: sudo systemctl restart autofs

  6. Jetzt sollten Sie prüfen, ob der Dienst sauber gestartet ist und keine Syntax-, Netzwerk- oder sonstigen Fehler aufgetreten sind. Den Status sehen Sie mit:

    Ubuntu: sudo service autofs status

    Red Hat: sudo systemctl status autofs

  7. Im besten Fall meldet die Ausgabe, dass der Dienst läuft und alles in Ordnung ist. Andernfalls werden die letzten Log-Zeilen angezeigt, die beim Debugging helfen. Am Ende dieser Anleitung finden Sie zusätzlich einen Abschnitt mit grundlegenden Debugging-Schritten.

  8. Nun können Sie mit cd in die Verzeichnisse wechseln, die Sie in den Dateien oben angegeben haben, um auf die Shares zuzugreifen. Diese Verzeichnisse müssen Sie nicht selbst anlegen – der autofs-Daemon erstellt sie automatisch.

  9. Eine letzte Gegenprobe: Mit mount erhalten Sie eine Liste aller Mounts auf der Instanz. Die von autofs erzeugten Mounts finden Sie bequem mit mount | grep autofs.

  10. Ab hier werden die Mounts automatisch geladen und bei Bedarf neu eingebunden.

  11. An dieser Stelle empfehle ich dringend, sich mit NFS-Sicherheit zu beschäftigen, Ihre Mounts abzusichern und das für Ihren Anwendungsfall passende Sicherheitskonzept umzusetzen.


Häufige Probleme debuggen

Beim Einarbeiten bin ich auf einige Stolpersteine gestoßen, die ich hier samt Lösungsweg auflisten möchte.

Der erste Stolperstein: Der Daemon warf reihenweise Fehler, weil keine Verbindung zu NFS zustande kam. Die Ursache: Synology stellt dem Share-Namen die Volume-Nummer voran – das war mir damals nicht bewusst. Diagnostiziert habe ich das, indem ich versucht habe, den NFS-Share manuell in einen Ordner in meinem Home-Verzeichnis einzubinden, mit folgendem Befehl: mkdir tmp_mnt && sudo mount -v -r -o user,nolock,nosuid [server_name]:[share_path] tmp_mnt. Das bindet den Share in ein lokales Verzeichnis ein. Sie erhalten entweder eine Erfolgsmeldung oder einen Fehler, der Aufschluss über das Problem gibt. Zum Aushängen verwenden Sie sudo umount tmp_mnt.

Ein weiterer Fehler trat auf, weil der Server über seinen Hostnamen nicht erreichbar war. Dahinter steckte ein internes DNS-Problem – der Hostname wurde nicht aufgelöst. Diagnostiziert habe ich das, indem ich den Share über seine IP-Adresse erreichen konnte und anschließend per nslookup hostname festgestellt habe, dass die IP-Adresse nicht in den Hostnamen aufgelöst wurde. Hinweis: Eventuell müssen Sie dafür die Pakete bind-utils (für Red Hat sudo yum -y install bind-utils) oder dnsutils (für Debian sudo apt install -y dnsutils) installieren.

Das letzte Problem ist Kubernetes-spezifisch: Aus keinem Pod im Cluster konnte ich auf externe Dienste außerhalb des Clusters zugreifen – inklusive NFS-Shares. Der Grund: Der Hostname ließ sich per DNS nicht auflösen, weil der Cluster meinen internen DNS-Server außerhalb des Clusters nicht kannte. Die Theorie dahinter sprengt den Rahmen dieser Anleitung, daher gebe ich nur die Lösung sowie einen weiterführenden Link an.

  1. Bearbeiten Sie die CoreDNS-ConfigMap mit folgendem Befehl: kubectl edit configmap coredns -n kube-system.
  2. Es öffnet sich ein Texteditor mit der YAML-Datei für CoreDNS. Darin gibt es einen Abschnitt namens Corefile mit einem YAML-Block, der mit .:53 beginnt.
  3. Bestimmen Sie Ihre interne Domain. Sie ergibt sich aus der Konfiguration Ihres internen DNS-Servers; falls Sie keinen internen DNS-Server haben, verwenden Sie einfach local.
  4. Ermitteln Sie die IP-Adresse Ihres DNS-Servers. Falls Sie keinen haben, ist es höchstwahrscheinlich die IP-Adresse Ihres Routers.
  5. Fügen Sie den folgenden Codeblock mit Ihren eigenen Angaben darunter in einer neuen Zeile ein (achten Sie auf Leerzeichen statt Tabulatoren!), speichern Sie und verlassen Sie den Editor:

[domain_name]:53 { errors cache 30 forward . [dns_server] }

Mehr dazu, warum das funktioniert, finden Sie hier.