PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : NFSv4 ohne UID-Mapping? Übertragung der echten UID und GID?



WebWusel
01.03.12, 20:08
Hallo,

ich habe eine gut funktionierende NFS-Umgebung für Clients, die als OpenVZ-Server laufen und ihre Container vom NFS-Server beziehen. Tatsächlich handelt es sich um ein wenig für meine Zwecke umgebogenes Proxmox 1.9.

Soweit so gut, das läuft unter NFSv3 recht rund.

Nun möchte ich auf NFSv4 umstellen und das nicht nur wegen der angeblich besseren Performance sonden vor allem wegen des besseren Lockings und Crash-Handlings.

Nun habe ich aber das Problem, dass mir das UID/GID-Mapping das Vorhaben als unmöglich erscheinen lässt. Die laufenden Container der OpenVZ Server wissen nichts vom NFS-Mount ihres Hosts. Sie sind auch nicht zwingend Teil der Domäne und daher sind die User der Container meist auch weder auf dem Host noch auf dem NFS-Server vorhanden.

Mit einem kleinen Beispiel kann ich wohl gut aufzeigen, was ich meine:

Ein ls -lisa auf einem OpenVZ-Server, der via NFSv3 mounted sieht so aus:

194619080 4 drwxr-xr-x 10 root root 4096 Feb 1 19:02 .
178522444 4 drwxr-xr-x 111 root root 4096 Feb 17 13:14 ..
194619081 4 drwx------ 2 root root 4096 Nov 19 01:46 .configs
194621721 4 -rw-r----- 1 1369 1369 17 Feb 1 19:02 .forward
194619082 4 drwxr-x--- 2 root www-data 4096 Jan 24 2011 atd
194619083 4 drwxr-x--- 2 root 1369 4096 Jan 24 2011 backup
194619084 4 drwxr-x--- 2 1369 www-data 4096 Jan 24 2011 files
194619085 4 drwxr-x--- 3 1369 www-data 4096 Jan 24 2011 html
194619087 4 drwxr-x--- 3 root 1369 4096 Feb 28 02:03 log
194619089 4 drwxrwx--- 2 1369 www-data 4096 Jan 24 2011 phptmp
194619090 4 drwxrwx--- 2 root 1369 4096 Jan 24 2011 restore

Wir sehen hier, User die dem Host nicht bekannt sind werden mit der echten UID angezeigt. So soll es sein.

Ein ls -lisa des gleichen Verzeichnisses auf einem Host, der die Verzeichnisse via NFSv4 mounted sieht so aus:

194619080 4 drwxr-xr-x 10 root root 4096 Feb 1 19:02 .
178522444 4 drwxr-xr-x 111 root root 4096 Feb 17 13:14 ..
194619081 4 drwx------ 2 root root 4096 Nov 19 01:46 .configs
194621721 4 -rw-r----- 1 nobody nogroup 17 Feb 1 19:02 .forward
194619082 4 drwxr-x--- 2 root www-data 4096 Jan 24 2011 atd
194619083 4 drwxr-x--- 2 root nogroup 4096 Jan 24 2011 backup
194619084 4 drwxr-x--- 2 nobody www-data 4096 Jan 24 2011 files
194619085 4 drwxr-x--- 3 nobody www-data 4096 Jan 24 2011 html
194619087 4 drwxr-x--- 3 root nogroup 4096 Feb 28 02:03 log
194619089 4 drwxrwx--- 2 nobody www-data 4096 Jan 24 2011 phptmp
194619090 4 drwxrwx--- 2 root nogroup 4096 Jan 24 2011 restore

Hier wird, ganz wie es bei NFSv4 gewollt ist, auf nobody und nogroup gemappt, wenn die echte UID nicht vorhanden ist.

Im Gegensatz dazu ein ls -lisa aus der virtuellen Maschine heraus, der das Verzeichnis gehört:

194619080 4 drwxr-xr-x 10 root root 4096 Feb 1 19:02 .
178522444 4 drwxr-xr-x 111 root root 4096 Feb 17 13:14 ..
194619081 4 drwx------ 2 root root 4096 Nov 19 01:46 .configs
194621721 4 -rw-r----- 1 web70 web70 17 Feb 1 19:02 .forward
194619082 4 drwxr-x--- 2 root www-data 4096 Jan 24 2011 atd
194619083 4 drwxr-x--- 2 root web70 4096 Jan 24 2011 backup
194619084 4 drwxr-x--- 2 web70 www-data 4096 Jan 24 2011 files
194619085 4 drwxr-x--- 3 web70 www-data 4096 Jan 24 2011 html
194619087 4 drwxr-x--- 3 root web70 4096 Feb 28 02:03 log
194619089 4 drwxrwx--- 2 web70 www-data 4096 Jan 24 2011 phptmp
194619090 4 drwxrwx--- 2 root web70 4096 Jan 24 2011 restore

So soll es auch sein.

Auf einem Host, der die Verzeichnisse via NFSv4 hält, startet erst gar keine virtuelle Maschine.

Und der Vollständigkeit halber sei erwähnt, dass ohne laufenden rpc.idmapd alle Dateien und Verzeichnissen der UID und GID 4294967294 gehören, womit natürlich alles für die Tonne ist.

Also die alles entscheidende Frage, nachdem ich mich heute einen Tag lang durch das Netz gegooglet habe:

Kennt jemand einen Weg NFSv4 davon zu überzeugen, dass es die reale UID und GID ohne Mapping überträgt und akzeptiert?

Achso: Security und Verschlüsselung können komplett außen vor gelassen werden und ist aus Performance-Gründen auch nicht gewünscht. Die Übertragung der Daten vom NFS-Server zu den Clients erfolgt über ein eigens dafür vorhandenes, physikalisch isoliertes Netz.

Vielen Dank im Voraus!

WebWusel
02.03.12, 07:36
Ich habe etwas gefunden, was zum Ziel führen könnte. Aus dem manual des idmapd(8):

Options:
...
-C' Client-only: perform no idmapping for any NFS server, even if one is detected.
-S' Server-only: perform no idmapping for any NFS client, even if one is detected.
...

Aber wie überrede ich nfs-common dazu, rpc.idmapd -S bzw. rpc.idmapd -C zu starten?

Wenn ich das im laufenden Betrieb mache, also den idmapd stoppe und mit Option wieder starte bringt das scheinbar nichts.

WebWusel
04.03.12, 09:23
Entsprechende Parameterübergabe durch den Start-Stop-Daemon in der /etc/init.d/nfs-common mit "-- -S" auf dem Server und "-- -C" auf dem Client startet den idmapd wie gewünscht. Das Resultat bleibt unverändert.

Und wenn sich hier niemand findet, der eine Lösung kennt, wo wohl sonst. Im Umkehrschluss bedeutet das wohl, dass es keine Lösung gibt.

Fazit: NFSv4 ist sicherlich großartig in homogenen, in sich geschlossenen Netzwerken. Als Fileserver für filebasierte Paravirtualisierung ala OpenVZ allerdings total ungeeignet.

Sehr, sehr schade. Ich schreib' NFSv4 dann mal für unsere Struktur ab.

p. s.: bevor hier jemand schreibt NFSv4 funktioniert nicht in OVZ-Containern bitte nochmal oben lesen. Es geht hier um die Hardware-Server und dieses - in diesem Fall - störende und nicht abschaltbare UID/GID-Mapping und nicht um die Container!

drcux
04.03.12, 10:55
Nun habe ich aber das Problem, dass mir das UID/GID-Mapping das Vorhaben als unmöglich erscheinen lässt.

Und da liegt wohl dein Denkfehler.

AFAIK: die UID/GID spielt bei NFSv4 keine Rolle mehr, es werden Benutzernamen und Gruppen gemappt, d.h., bei NFSv4 werden die UID/GID nicht mehr übertragen, der Server weiß also nicht, welche UID/GID auf dem Client genutzt wird. Dein Problem ist also nicht das Mapping, sondern schon eine Schicht darunter. Ich glaube nicht, das man dieses Verhalten bei NFSv4 so einfach ausschalten kann.

WebWusel
04.03.12, 11:30
Doch, genau das ist das Problem. NFSv4 geht davon aus, dass User auf dem Server auch grundsätzlich auf dem Client existieren, berücksichtigt dabei aber, dass die UID unterschiedlich ist bzw sein kann. Deshalb wird auch nicht die UID/GID übertragen sondern der Name. Das läßt sich natürlich prima mitlesen, wenn man idmapd geschwätzig startet.

Ist der User nicht vorhanden, ob nun auf dem Server oder dem Client, wird auf Nobody bzw Nogroup gemappt.

Und wonach wir gestern noch bis in die Nacht geforscht haben, ist ein Weg genau dieses Verhalten abzuschalten. Nach dem Motto: "Mach es wie unter V3 und kümmer Dich nicht um die Usernamen bzw Gruppennamen".

Du hast wohl recht, es läßt sich offensichtlich nicht umgehen.

Irgendwo habe ich gelesen, dass es mit gss/krb5 funktionieren kann. Jetzt muss ich das erst mal wiederfinden und dann probieren wir es nochmal.

WebWusel
16.10.12, 15:21
Knock, knock.

Stehe wieder vor dem selben Problem. Hat vielleicht inzwischen jemand eine Idee dazu?