Re: nfs-server: kernel vs. user
Andreas Metzler <ametzler@downhill.at.eu.org> writes:
> Axel Duerrbaum <axeld@rts.maschinenbau.uni-kassel.de> wrote:
> > Andreas Metzler <ametzler@downhill.at.eu.org> writes:
> >> Axel Duerrbaum <axeld@rts.maschinenbau.uni-kassel.de> wrote:
> [...]
> >>> Im HOWTO und den ma-pages kann ich diese Einschränkung nirgends
> >>> finden.
>
> >> exports(5)
> >> | ... /etc/exports serves as the access control list for file systems
> >> *^^^^^^^^^^^^*
>
> > Was anderes als Dateisysteme sollte NFS auch exportieren?
>
> Komplette Verzeichnisbaeume, auch wenn sie auf anderen Dateisystemen
> liegen? Gerade das war doch die Frage.
Mir scheint, jetzt vertrittst Du meine Argumentation: Wenn ich ein
Verzeichnis freigebe, werden die darunter liegenden auch
freigegeben.
Nur macht der kernel-server das nicht (mehr), wenn die
Unterverzeichnisse selbst mount-points sind (und noch nicht mal
nfs-mounts).
> > Dies besagt
> > nicht, das man nicht über *Partitons*grenzen hinaus exportieren darf.
>
> So ist das auch nicht richtig. Du kannst z.B. mit RAID mehrere
> Partitionen zusammenfassen und das darauf liegenden *Dateisystem*
> kompett exportieren.
Prima. Aber leider habe ich den umgekehrten Fall: mehrere Partitionen
unter einem Verzeichnis.
> >> file:///usr/share/doc/HOWTO/en-html/NFS-HOWTO/server.html#CONFIG
> >> 3.2.1. /etc/exports
> >> ...
> >> | directory
> >> |
> >> | the directory that you want to share. It may be an entire
> >> | volume though it need not be. If you share a directory, then
> >> | all directories under it within the same file system will be
> >> *^^^^^^^^^^^^^^^^*
> >> | shared as well.
>
> > Genau diese Stelle interpretiere ich anderst herum:
>
> > Wenn ich ein komplettes Dateisystem freigebe, dann sind alle
> > Unterverzeichnisse mit drin.
>
> Du vertauscht "directory" und "the same file system" um eine dir
> genehme Uebersetzung zu erhalten.
OK, das habe ich wohl beim Übersetzen wirklich falsch verstanden.
Dies scheint genau die Einschränkung zu sein, die ich übersehen habe.
Allerdings vestehe ich die Motivation für dieses Verhalten nicht.
Nämlich die Mount-Points im freigegebenen Verzeichnis anzuzeigen, aber
deren Inhalt nicht. Und das ohne Fehlermeldung oder ohne irgendeinen
Eintrag in einem Logfile.
> Beinahe Wort-fuer-Wort-Uebersetzung:
>
> Verzeichnis
> Das Verzeichnis, das freigegeben werden soll. Es *kann* ein
> ganzes Volume (z.B. Partition) sein, das muss aber nicht sein.
> Wenn sie ein *Verzeichnis* freigeben, werden alle darunter
> liegende *Verzeichnisse* im selben *Dateisystem* auch
> feigegeben.
>
> Ich sehe da keinen Spielraum fuer Interpretation.
Ich jetzt auch nicht mehr. Vielleicht war ich gesten morgen einfach
noch nicht wach genug.
> [...]
> > Ausserdem würde dann das Beispiel in exports(5) keinen Sinn ergeben:
>
> > # sample /etc/exports file
> > / master(rw) trusty(rw,no_root_squash)
> > ^^^--- dies wäre Deiner Meinung nach nicht möglich.
>
> > "The first line exports the entire filesystem to machines ..."
>
> Warum? Nirgends steht geschrieben das / und z.B. /home auf dem selben
> Dateisystem liegen. Obige Zeile gibt das das komplette Root-Dateisystem
> frei.
Ja, leider aber nicht so ganz. Denn wenn /home ein eigenes Dateisystem ist,
sieht man nur ein leeres /home.
Jedenfall jetzt unter woody. Unter potato und dem kernel-server wäre
/home lesbar gewesen.
> > Ich denke, da ist ein neuer Fehler im kernel-server, der vorher nicht
> > da war.
OK, mittlererweile sehe ich ein, das das vielleicht kein Fehler ist,
sondern ein neues Feature. Es soll wohl rekursive Mounts vermeiden.
Aber das hätte man eventuell nur auf nicht-lokale Dateisysteme
beschränken können.
> Wenn du der Meinung bist, solltest du dich an
> nfs@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs wenden, und das als
> Bug melden. - Keine Angst, die Liste hat wenig Verkehr (im Schnitt
> vielleicht fuenf Mails/Tag) und die dort mitlesenden Leute sind sehr
> umgaenglich.
Wenn ich herausgefunden habe, wie man im dortigen Archiv suchen kann
(warum es vorher ging und jetzt nicht mehr und warum es keine Warnung
gibt) und ich es irgendwie in Englisch hinkriege, werde ich gerne dort
versuchen.
Danke nochmals (besonders für die ausführliche Übersetzung).
MfG,
AxelD
--
Axel Dü¼rrbaum / Universität Kassel / FB 15 - RTS Regelungstechnik
Mönchebergstraße 7 / 34109 Kassel / Germany / Technik I/II / Raum 2602
phone:+49 561 804 3261 eMail:axeld@uni-kassel.de
Reply to: