NFS4 Export

Hallo,

ich möchte gerne einen NFS4 Export erstellen. Diesen möchte ich dann auf unterschiedlichen Systemen mounten um z.B. Benutzern den Zugriff auf das Home-Verzeichnis zu gewähren aber auch andere Verzeichnisse die sowohl für einzelne Benutzer als auch für Webservices bereitgestellt werden sollen.

Derzeit finde ich keine hilfreichen oder funktionierenden Informationen wie so ein NFS4 Export erstellt bzw gemounted werden kann.

Ich habe gegooglet und hier mehrere Informationen gefunden die aber alle zu keinem funktionierenden Resultat geführt haben.
Die Schritte welche auf der Seite wiki.univention.de/index.php?tit … 4_with_UCS beschrieben sind habe ich ebenfalls versucht umzusetzen. Leider funktioniert auch das nicht.

Einen NFS3 Export möchte ich nur sehr ungerne verwenden seit ich festgestellt habe, dass jeder Rechner im Netz auf alle Daten lesend und schreibend zugreifen kann sobald nur die User ID passt.

Gibt es irgendwo eine Step by step Anleitung nach der man verfahren kann?

Vielen Dank im vorraus!

Mit freundlichen Grüßen

Hendrik Dreyer

Moin,

ja, eine solche Anleitung gibt es, die von Ihnen verlinkte. Was daran funktioniert nicht? Es ist vermutlich am Sinnvollsten, wenn Sie genau beschreiben, was Sie davon umgesetzt haben und wo es dann zu welchen Fehlern und Problemen kam. Dann können wir Ihnen auch besser weiterhelfen.

Hallo,

vielen Dank für die Antwort. Da die aktuelle UCS-Version nicht aufgeführt ist und meine Versuche bisher fehlgeschlagen sind, nahm ich an, dass es vielleicht einen anderen Artikel gibt.
Bei meinem ersten Versuch habe ich jetzt einen ersten Fehler bei der Ausführung eines Kommandos gefunden.
In der folgenden Befehlszeile habe ich den FQDN eingetragen:

samba-tool spn add nfs/fs1.sub.domain.tld.$(hostname -d)/$(hostname -d) fs1.sub.domain.tld\$

Dies wurde mit einem Fehler quitiert. Nachdem ich nun den Befehl erneut mit dem Hostnamen des NFS-Servers abgesetzt habe wurde dieser nun wie folgt bestätigt:

WARNING: No path in service IPC$ - making it unavailable!
NOTE: Service IPC$ is flagged unavailable.

Ich nehme mal an, dass dies lediglich in einer Windows-Domain zu Problemen führen kann. Das ist aber dann noch nicht relevant. Sollte es hier eine schnelle einfache Lösung geben freue ich mich selbstverständlich über einen Tipp

Auf allen beteiligte Systemen habe ich die folgenden Befehle ausgeführt:

kvno=$(ldapsearch -D $(ucr get ldap/hostdn) -w $(cat /etc/machine.secret ) -h $(ucr get ldap/master) cn=$(hostname) -p 7389 krb5KeyVersionNumber | grep krb5KeyVersionNumber: | cut -d" " -f2)
ktutil add -w $(cat /etc/machine.secret ) -V $kvno -p nfs/$(hostname -f)@$(ucr get kerberos/realm) -e aes256-cts-hmac-sha1-96
ktutil add -w $(cat /etc/machine.secret ) -V $kvno -p nfs/$(hostname -f)@$(ucr get kerberos/realm) -e aes128-cts-hmac-sha1-96
ktutil add -w $(cat /etc/machine.secret ) -V $kvno -p nfs/$(hostname -f)@$(ucr get kerberos/realm) -e des-cbc-md5
ktutil add -w $(cat /etc/machine.secret ) -V $kvno -p nfs/$(hostname -f)@$(ucr get kerberos/realm) -e des-cbc-crc

Auf dem NFS-Server habe ich in der Univention Configuration Registry (GUI) die folgenden Parameter gesetzt:

NEED_IDMAPD=yes
NEED_GSSD=yes
nfs/nfsd/nfs4=true

Den Parameter NEED_SVCGSSD habe ich in der Datei /etc/univention/templates/files/etc/default/nfs-kernel-server angepasst und den Befehl ucr commit /etc/default/nfs-kernel-server ausgeführt.
Hier die Ausgabe der Datei /etc/default/nfs-kernel-server

cat /etc/default/nfs-kernel-server
# Warning: This file is auto-generated and might be overwritten by
#          univention-config-registry.
#          Please edit the following file(s) instead:
# Warnung: Diese Datei wurde automatisch generiert und kann durch
#          univention-config-registry überschrieben werden.
#          Bitte bearbeiten Sie an Stelle dessen die folgende(n) Datei(en):
#
#       /etc/univention/templates/files/etc/default/nfs-kernel-server
#

# Number of servers to start up
RPCNFSDCOUNT="8"


# Runtime priority of server (see nice(1))
RPCNFSDPRIORITY=0

# Options for rpc.mountd.
# If you have a port-based firewall, you might want to set up
# a fixed port here using the --port option. For more information,
# see rpc.mountd(8) or http://wiki.debian.org/?SecuringNFS
RPCMOUNTDOPTS="--manage-gids --port 32767"


# Do you want to start the svcgssd daemon? It is only required for Kerberos
# exports. Valid alternatives are "yes" and "no"; the default is "no".
NEED_SVCGSSD=yes

# Options for rpc.svcgssd.
RPCSVCGSSDOPTS=

Zuletzt habe ich auf dem NFS-Server die Dienste neugestartet:

/etc/init.d/nfs-common restart
/etc/init.d/nfs-kernel-server restart
exportfs
/data       gss/krb5i
/data/home  gss/krb5i

Der Test auf dem Client (UCS Terminalserver) habe ich dann den folgenden Befehl ausgeführt und erhalte eine Fehlermeldung:

mount -t nfs4 fs1.sub.domain.tld:/userdata/home /mnt/fs1 -o sec=krb5i
mount.nfs4: access denied by server while mounting fs1.sub.domain.tld:/data/home

Im Moment der Befehlsausführung bin ich als root angemeldet!
Auch nach dem Befehlkinit <username> kann ich nicht mounten oder das Verzeichnis listen.
Auch der Versuch das Verzeichnis /home direkt zu mounten also mit dem Befehl

mount -t nfs4 fs1.sub.domain.tld:/home /mnt/fs1 -o sec=krb5i
mount.nfs4: access denied by server while mounting fs1.sub.domain.tld:/data/home

Führt zum gleichen Fehlerbild.

Die Datei /etc/exports auf dem NFS-Server hat den folgenden Inhalt:

"/data"      gss/krb5i(rw,async,fsid=0,insecure,crossmnt,no_subtree_check)
"/data/home" gss/krb5i(rw,async,nohide,insecure,crossmnt,no_subtree_check)

Vielen Dank im Vorraus.

Mit freundlichen Grüßen

Hendrik Dreyer

Vielen Dank für die ausführlichen Informationen. Von Univention habe ich die Information, dass sie zur Frage »geht NFSv4 mit UCS 4« zumindest nichts Gegenteiliges wissen – sprich es sollte nach der Anleitung weiterhin funktionieren.

Ich werde das einmal nachstellen und Ihre mit meinen Ergebnissen vergleichen, bitte dafür aber um etwas Geduld.

Hallo,

ich habe es selber ausprobiert und bin leider in dieselben Probleme gelaufen wie Sie. Intensives Nachforschen und Ausprobieren hat leider nicht geholfen.

Von Univention habe ich noch den Hinweis, das Samba-Debug-Level schrittweise hochzusetzen (erst auf 3, dann 5 und zur Not 12), da Samba Kerberos-Meldungen in den Samba-Logdateien loggen sollte.

Ein weiterer Tipp von Univention war, anstelle von »samba-tool spn add« das Script »/usr/share/univention-samba4/scripts/create_spn_account.sh« zu verwenden. Dies wird eine eigene Keytab erzeugen, die der NFS-Server dann verwenden müsste. Das habe ich allerdings selber nicht ausprobiert.

Hallo,

vielen Dank für die Unterstützung und die Mühe.
Ich werde das testen und Ergebnisse hier dann mitteilen

Ich bitte um ein wenig Geduld da ich derzeit unterwegs bin.

Mit freundlichen Grüßen

Hendrik Dreyer

[quote=“hendrix3er”]Hallo,

vielen Dank für die Unterstützung und die Mühe.
Ich werde das testen und Ergebnisse hier dann mitteilen

Ich bitte um ein wenig Geduld da ich derzeit unterwegs bin.[/quote]

Lieber Herr Dreyer,

ist bei Ihren Tests irgendetwas herausgekommen? Ich stehe vor dem gleichen Problem und insofern wäre ein Hinweis, ob das genannte Skript (/usr/share/univention-samba4/scripts/create_spn_account.sh) geholfen hat, sehr interessant für mich. Gerne natürlich auch mit einer Schilderung, wie Sie vorgegangen sind, falls es geklappt hat.

Gruß, V. Mayer

Sehr geehrter Herr Mayer,

ich habe die Anbindung bisher nicht via Kerberos umsetzen können. Aufgrun einiger Strukturänderungen habe ich mich zunächst für einen Workarround entschieden.
Ich nutze NFSv3 in einem dedizierten VLan. Somit gibt es keinen NFS-Traffic im User-LAN. Es haben auch nicht alle Server, und erst recht keine Clients Zugriff oder eine Route in das NFS-VLan.

Die LinuxTerminalserver Lösung welche ich anvisiert hatte läuft leider auch nicht ganz so stabil wie ursprünglich gedacht so dass ich hier auch zunächst den Zugriff auf Daten über ein Webfrontend oder aber über CIFS (nur intern) bereit stelle. NFS ist derzeit also nicht Priorität!

Über NFS stelle ich Daten des Fileservers für den Webserver bereit. Gleichzeitig schieben die einzelnen Server über NFSv3 zu sichernde Daten auf den Backupserver. Über die exports-Datei ist in diesem Fall der Zugriff gesteuert.

Ich habe aber noch nicht aufgegeben, komme nur zeitlich nicht dazu mich intensiever mit dem Thema auseinander zu setzen. Ich poste hier die Lösung NFSv4 wenn ich sie umsetzen konnte.

Mit freundlichen Grüßen

Hendrik Dreyer

Lieber Herr Dreyer,

danke für die sehr ausführliche Antwort, auch wenn sie bzgl. des Kernproblems lautet, dass es noch nicht geht. Mag jemand von Univention dazu noch einmal etwas sagen? Wie ist vorzugehen, wenn man kerberisiertes NFSv4 (oder andere kerberisierte Dienste) nutzen will und der Kerberos-Server Samba4 ist? Unabhängig von UCS habe ich das (NFSv4 mit MIT-Kerberos) durchaus schon mal hinbekommen. Insofern wäre meine Erwartung, auch mit Heimdal/UCS auf keine großen Schwierigkeiten zu stoßen. Wie aber geht’s mit Samba4?

Gruß, V. Mayer

Sehr geehrter Herr Mayer,
Da unsere Partner (in diesem Fall Herr Bunkus von Linet) hier im Forum unser verlängerter Arm sind und wir regelmäßig (auch zu diesem Thema) Rücksprache halten, gibt es von Univention Seite nicht wirklich etwas hinzuzufügen. Alles weitere würde im Moment den Rahmen des Forums sprengen, dafür bitte ich um Verständnis.

Falls Sie hier einen konkreten Fall haben den wir für Sie möglich machen sollen, können wir über unsere Vertriebsmitarbeiter aber sicher einen gangbaren Weg finden.

Mit freundlichem Gruß,
Jens Thorp-Hansen

Ich habe folgendes erfolgreich mit UCS-4.2duchgeführt – allerdings funktioniert es derzeit nicht mit Samba4:
Zunächst einige Variablen:

FQDN="$(hostname -f)"
DOMAIN="$(dnsdomainname)"
REALM="$(ucr get kerberos/realm)"
PRINCIPAL="nfs/${FQDN}@${REALM}"
BASE="cn=kerberos,$(ucr get ldap/base)"

Für den NFS-Server einen Kerberos-Principal anlegen:

udm kerberos/kdcentry create \
    --position "$BASE" \
    --set name="$PRINCIPAL" \
    --set generateRandomPassword=1

Diesen in die Keytab exportieren:

kadmin -l ext_keytab -k /etc/krb5.keytab "$PRINCIPAL"

Ein Verzeichnis exportieren: Hier wird krb5i verwendet, was nur die Integrität sicherstellt, aber nicht die Daten verschlüsselt. Will man das haben, muss man krb5p verwenden.

echo '/home  gss/krb5i(rw,sync,no_subtree_check)' >>/etc/exports

Dafür sorgen, dass der RPC Server GSS Dienst gestartet ist:

sed -i -re 's/#?(NEED_SVCGSSD=).*/\1yes/' \
    /etc/univention/templates/files/etc/default/nfs-kernel-server
ucr commit /etc/default/nfs-kernel-server
service nfs-kernel-server restart

Mounten kann man das ganze testweise dann so:

mount -t nfs4 -o sec=krb5i $FQDN:/home /mnt

Wichtig ist hier, dann man hier das selbe Verfahren wie oben angibt.

Für weitere Tests:

su - Administrator
cd /mnt/Administrator # schlägt fehl
kinit
cd /mnt/Administrator # jetzt geht's
kdestroy

Es freut mich, daß sich hier etwas tut. Aber es wäre noch schöner, wenn es als offiziellesFeature einfließen würde, denn normales NFS isf ja offen wie ein Scheunentor.

Ausser Dokumentation wird sich hier leider erst einmal wegen anderer Prioritäten nichts weiter tun.

Für Samba4 muss man abweichend folgendes machen, weil Samba4 seine eigene Kerberos-Implementierung hat. Die basiert zwar auf Heimdal und die Heimdal-Tools tun auch alle so, als würden sie es richtig machen, aber wegen Detailunterschiede geht es dann eben doch nicht.

AD ordnet die Kerberos-Prinzipale für einen Dienst jeweils einem eigenen Benutzerkonto zu - deswegen gibt es z.B. in einem Standard-UCS bereits die “dns-$DC_NAME”-Benutzerkonten, die dem “dns/$DC_NAME”-Kerberos-Principalen entsprechen. Ähnliches muss man dann auch für nfs auf dem NFS-Server machen (hier mein UCS Master):

/usr/share/univention-samba4/scripts/create_spn_account.sh \
    --samaccountname "nfs-$HOSTNAME" \
    --serviceprincipalname "nfs/$(hostname -f)" \
    --privatekeytab nfs.keytab
ktutil copy /var/lib/samba/private/nfs.keytab /etc/krb5.keytab
systemctl restart rpc-svcgssd.service

Anschließend exportiere ich hier zum Beispiel /home:

echo '/home  gss/krb5i(rw,sync,no_subtree_check)' >>/etc/exports
systemctl try-reload-or-restart nfs-server.service

Für den Client ist nichts zu tun - der sollte™ das Maschinenkonto verwenden. Ggf. muss man nur den RPC-Daemon für den Client einmalig neu starten:

systemctl restart rpc-gssd.service
kinit Administrator
mount -t nfs4 -o sec=krb5i "$(ucr get ldap/master):/home" '/home'

Ich habe das jetzt mal auf einem DC Slave probiert:

Permission denied.
ERROR: could not create user account nfs-$hostname

Wenig überraschend geht es auf dem DC Master. Da es im Samba4-DNS-Joinscript auch auf dem DC Slave ausgeführt wurde, sollte es auch dort irgendwie gehen. Ich schätze mal es werden die Join-Credentials genommen. Der genaue Mechanismus ist aber etwas undurchsichtig.

Für einen offiziellen Support müßte übrigens nur in einem Join-Script der Prinzipal angelegt und der rpc-gssd aktiviert werden. Für die einzelnen Freigaben kann man Kerberos bereits über die UMC aktivieren (Tab “Erweiterte Einstellungen” -> “Erweiterte NFS-Einstellungen” -> “sec=krbi” eintragen). Der Ubuntu-Client handelt automatisch den richtigen Parameter aus.

OT: Nur aus Neugier: Mit welchem LDAP-Objekt werden eigentlich die LDAP-Prinzipale verknüpft?

EDIT: Schon rausgefunden. Das Objekt befindet sich unterhalb von cn=kerberos,dc=top,dc=top1.

Wenn ich versuche, mich auf einenm Client, der den DC Master als /home gemounted hat, einzuloggen, hängt der Start der graphischen Oberfläche. Beim Login per SSH sind hingegen keine Probleme festzustellen.

Bei einem anderem Client mit einem DC Slave als Server tritt dieses Problem nicht auf. An der Hardware kann es aber nicht liegen. Die vom Master ist eigentlich deutlich potenter.

Die Firewall kann das Problem ebenfalls nicht verursachen, da ich diese testweise abgeschaltet habe.

Unterschiede bei der NFS-Konfiguration sind mir auch nicht aufgefallen. Der Master wurde aber ursprünglich mit UCS 2.4 installiert, der Slave mit UCS 3.X.

Auf dem DC Master und DC Backups gibt es die Datei /etc/ldap.secret, die das Klartextpasswort für den Benutzer cn=admin,$ldap_base enthält. Auf DC Slaves und Member-Servern gibt es die nicht. Dort muss man dann per --binddn ... --bindpwdfile ... passenden Credential angeben, mit denen udm passende Einträge anlegen bzw. verändern kann.

Mir ist kein generelles Problem bekannt: Hier hilft nur die Analyse mit strace und Co, wo welcher Prozess hängt und warum es nicht weitergeht. “Beliebt” sind hier Fälle, wo der erste Versuch scheitert, dann der 2. aber gelingt, weil dann irgendein Prozess Dinge zwischengespeichert hat. Oder ssh macht Dinge als nobody, kdm aber nicht bzw. umgekehrt. Oder, oder, oder, …

Ich habe mir noch mal die Konfigurationen angeschaut und doch einen entscheidenden Unterschied gefunden: Für den DC Master war subtree_check aktiviert.

Ich schätze mal das beißt sich mit Kerberos und dem nicht konfigurierten “virtual Root”. Vielleicht hat letzteres aber auch nichts damit zu tun.

Was hat es eigentlich mit dem ““virtual Root”” auf sich? Es wird in allen Anleitungen erwähnt, es funktioniert aber ja offenkundig auch ohne. Ich schätze mal standardmäßig wird “/” als virtual Root konfigurieriert und scheint somit doch nicht zwingend erforderlich zu sein.

Mit NFSv3 war es so, dass man auf den Clients die Verzeichnisnamen vom Server verwenden musste, d.h. wenn ich auf dem server das Verzeichnis /data/ exportiere, dann mountet man es auf den Clients als server:/data. Das hat natürlich den Nachteil, dass Änderungen auf dem Server auf allen Clients nachgepflegt werden müssen.
Mit virtual Root schaft man sich eine künstliche Verzeichnishierarchie (per bind-mount), so dass man auf dem Server sich eine beliebige Struktur für den NFS-Export bauen kann, die mit der tatsächlichen Verzeichnisstruktur auf dem Server nicht mehr 1:1 übereinstimmen muss.
Weiterhin vereinfacht das ggf. auch den Export/Import, weil man dann auf dem Server eben nur noch die Verzeichnisse in den virtual Root verlinkt, die man wirklich exportieren will - auf den Clients mountet man dann einfach server:/ und muss nicht mehr jede Freigabe einzeln mounten.
Zudem erhöht es die Sicherheit, weil der NFS-Export eben auf den virtual Root beschränkt ist und man so nicht “aus versehen” mehr exportiert, als man eigentlich wollte.
In der 1. Implementierung von NFSv4 im Linux-Kernel musste man sogar ein virtual Root verwenden, das wurde aber später aufgehoben, so dass man nun auch wieder mehrere Freigaben exportieren kann.