NFS4 Export

UCS - Univention Corporate Server
#8

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

#9

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

#10

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

#11

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
FAILED RPC Security Service for NFS Server after 4.3 Upgrade
#12

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.

#13

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'
NFS wither Kerberos
NFSv4 / Kerberos credentials for Machine account
After NFSv4 with Kerberos, nfs-server appears in the Pascom
#14

Ich habe das jetzt mal auf einem DC Slave probiert:

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

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.

#16

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.

#17

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.

#18

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, …

#19

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.

#20

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.

1 Like
#21

ich versuche das auch gerade einzurichten. Beim dritten Befehl erhalte ich jedoch einen Fehler:

root@tux:~# systemctl restart rpc-svcgssd.service
Failed to restart rpc-svcgssd.service: Unit rpc-svcgssd.service is masked.

Was ist da verkehrt?

#22

Sind diese Schritte im besagten Szenario (NFS4, Samba4, Kerberos) auch auszuführen?

#23

Bis auf diese Schritte habe ich alles gemacht. Bekomme die o.g. Meldung beim Versuch den Service neu zu starten und beim Versuch am Client zu mounten:

root@pc001:~# mount -t nfs4 -o sec=krb5i tux.gehr.lan:/home /home
mount.nfs4: requested NFS version or transport protocol is not supported

Das krb5i scheint das Problem zu sein:

Dez 06 16:03:11 tux exportfs[26033]: exportfs: unknown flavor krbi
Dez 06 16:03:11 tux systemd[1]: nfs-server.service: Control process exited, code=exited status=1
Dez 06 16:03:11 tux systemd[1]: Failed to start NFS server and services.
-- Subject: Unit nfs-server.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit nfs-server.service has failed.

Der Fehler kam daher

#24

Der Dienst wurde deaktiviert und muß daher erst aktiviert werden:

systemctl unmask rpc-svcgssd.service
systemctl enable rpc-svcgssd.service
systemctl start rpc-svcgssd.service
#25 
root@tux:/data# systemctl enable rpc-svcgssd.service
The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
settings in the [Install] section, and DefaultInstance for template units).
This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
   .wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
   a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
   D-Bus, udev, scripted systemctl call, ...).
4) In case of template units, the unit is meant to be enabled with some
   instance name specified.
#26

Ok seems that isn’t required

#27

Here is a summary of the steps I took:

++ Auf dem Server (Master) ++

+ Export-Root auf dem Server anlegen +

Datei /etc/exports

"/home" -rw,root_squash,sync,no_subtree_check,sec=krb5i


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

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

/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 try-reload-or-restart nfs-server.service

samba-tool spn add nfs/tux.gehr.lan/gerh.lan tux\$

/etc/univention/templates/files/etc/default/nfs-kernel-server

NEED_SVCGSSD=yes

ucr commit /etc/default/nfs-kernel-server



/etc/univention/templates/files/etc/default/nfs-common
NEED_STATD=no

ucr commit /etc/default/nfs-common


++ Auf dem Client ++

systemctl restart rpc-gssd.service
kinit Administrator

Wenn ich nun auf dem Client versuche das Home zu mounten erhalte ich lediglich:

root@pc001:~# showmount -e tux.gehr.lan
Export list for tux.gehr.lan:
/home *
root@pc001:~# mount -t nfs4 -o sec=krb5i tux.gehr.lan:/home /home
mount.nfs4: an incorrect mount option was specified
Mastodon