ubuntuusers.de

Ok...ich mache dann jetzt erstmal Feierabend und wenn dann bis heute Abend niemand was einzuwenden hat, würde ich das anpassen.

Ich habe noch andere Vorschläge zu diesem Wiki, aber eins nach dem anderen 😉

Z. B:

Damit sich der Rechner notebook auch zu der Freigabe /PFAD/ZUR/FREIGABE3 verbinden kann, muss er mit der IP-Adresse in der Datei /etc/hosts stehen

Das kann ich so nicht wirklich bestätigen. Muss es aber nochmal testen, wenn auch der Host ein Ubuntu-Rechner ist. Ich habe ein UnRaid zu Hause und dort steht keiner meiner Clients in der /etc/hosts aber alle haben Zugriff. Von daher denke ich, dass das auch nicht ganz korrekt ist.

Wie es sich von Ubuntu (als NFS Server) zu Ubuntu (als NFS Client) verhält, muss ich erst noch checken. Würde mich aber wundern, wenn es da so viel ander wäre.

Erldedigt

Danke für die Mithilfe!

Ach, nicht dafür. Das Ubuntuusers-Wiki hat mir schon viel mehr geholfen als ich dem Wiki 😀

David1977 schrieb:

Damit sich der Rechner notebook auch zu der Freigabe /PFAD/ZUR/FREIGABE3 verbinden kann, muss er mit der IP-Adresse in der Datei /etc/hosts stehen

Das kann ich so nicht wirklich bestätigen. Muss es aber nochmal testen, wenn auch der Host ein Ubuntu-Rechner ist.

Das ist meiner Erfahrung nach so und kann meiner Auffassung nach nicht anders sein. Der Laptop als Client steht mit seinen zwei IP-Adressen (LAN und WLAN gesondert) in der /etc/hosts.

Hallo eider,

Wie gesagt, habe ich bei mir verschiedene Ubuntu Desktops und auch Laptops die auf verschiedene NFS Shares von UnRaid zugreifen. In keiner der hosts-Dateien stehen die jeweiligen Rechner (abgesehen von 127.0.0.1 und dem Rechnernamen). Es stehen aber keine entfernten Rechner drin. Kann man natürlich eintragen, ist aber meiner Meinung nach nicht relevant für einen NFS Share oder den Zugriff darauf.

Ich muss das aber nochmal genauer testen.

Meiner Meinung nach braucht es nur 3 Dateien um einen NFS Server zu konfigurieren: /etc/exports , /etc/hosts.deny und /etc/hosts.allow

Die /etc/hosts-Datei dient doch eher zur Namensauflösung und einen NFS share mountet man ja eher via IP.

David1977 schrieb:

Damit sich der Rechner notebook auch zu der Freigabe /PFAD/ZUR/FREIGABE3 verbinden kann, muss er mit der IP-Adresse in der Datei /etc/hosts stehen

Das gilt nur, wenn man via Hostname und nicht via IP auf den NFS-Server zugreifen will.

Gruß BillMaier

//edited hab mir das nochmal angesehen im Artikel. Das bezieht sich auf die Freigabe mit

# Freigabe gilt nur für den Rechner mit dem Namen notebook
/PFAD/ZUR/FREIGABE4      notebook(ro,async)

Da muss dann natürlich notebook in der /etc/hosts des Servers stehen.

Das ist imho aber alles etwas verquer im Artikel. Also wer möchte darf den Artikel gerne grund-überarbeiten. Bitte bei Bedarf Bescheid geben, dann richten wir eine Baustelle dafür ein.

Gruß BillMaier

Ich weiß ja grundlegend auf was man hinaus möchte. Es ist nur ein wenig unglücklich ausgedrückt.

Wir sind uns ja einig, dass die /etc/hosts zur Namensauflösung im Netzwerk dient. Einen NFS share binde ich je nachdem...

Für NFS 3 ohne Eintrag in der /etc/hosts (je nachdem, was der default export des Servers ist...nfs3 oder 4):

sudo mount -t nfs -o vers=3 <ip_des_servers>:/<pfad>/<zum>/<share>

mit Eintrag vom Hostnamen und IP des Servers in der /etc/hosts (am Client!!, da dieser ja den Namen auflösen können muss):

sudo mount -t nfs -o vers=3 <hostname_servers>:/<pfad>/<zum>/<share>

Die Zeile, die wir hier aber ansprechen besagt, dass sich der Rechner 'notebook' nur dann mit dem Share verbinden (mounten) kann, wenn er mit der IP in der hosts-Datei steht.

Der Rechner 'notebook' könnte sich aber auch völlig ohne Eintrag in der hosts-Datei via IP verbinden bzw. der export des Servers müsste via IP vorgegeben sein.

Wenn der export eines NFS Share auf dem Server via Hostnamen erfolgen soll. also....

/mnt/<share> notebook(ro)

Dann ist es klar, dass zur Auflösung des Namens 'notebook' die hosts-Datei auf dem Server angepasst werden muss. Da dann dieser den Namen auflösen können soll.

Zwingend notwendig für den prinzipiellen Export oder den mount des Shares ist das aber nicht. Denn das geht auch ohne weiteres via IP Adresse.

Ich weiß...jetzt hört es sich wieder nach "meckern" an. Sorry dafür 😉. Ich finde es halt verwirrend ausgedrückt oder anders gesagt, nur die halbe Wahrheit. Ich mach mir mal Gedanken, wie man das sinnvoll ergänzen/anpassen kann ohne einen "wall of text" zu haben.

Ich bin mir halt auch unsicher, ob man das Thema der Namensauflösung im NFS Wiki überhaupt ansprechen soll, da dieses ja doch recht speziell ist und ggf in andere Wikis übergreifen wird. (hosts und bind bzw. dnsmasq)

Edit:

Ich sehe, Bill und ich sind uns einig 😉

David1977 schrieb:

Ich weiß...jetzt hört es sich wieder nach "meckern" an. Sorry dafür 😉. Ich finde es halt verwirrend ausgedrückt oder anders gesagt, nur die halbe Wahrheit.

Das ist schon ok, ich finde es auch im Artikel nicht klar und freue mich auf deine Korrektur.

Ich mach mir mal Gedanken, wie man das sinnvoll ergänzen/anpassen kann ohne einen "wall of text" zu haben.

👍

Ich bin mir halt auch unsicher, ob man das Thema der Namensauflösung im NFS Wiki überhaupt ansprechen soll, da dieses ja doch recht speziell ist und ggf in andere Wikis übergreifen wird. (hosts und bind bzw. dnsmasq)

Wenn dir eine Art Nebenbemerkung mit Beispiel einfällt, die dann auf die hosts verweist, umso besser. Dann kann der Rest mit den Hosts da gerne raus.

Gruß BillMaier

David1977 schrieb:

Ok...ich mache dann jetzt erstmal Feierabend und wenn dann bis heute Abend niemand was einzuwenden hat, würde ich das anpassen.

Noch eine Idee dazu, damit das nicht so ums-Eck erklärt werden muss:

Ein oder zwei ergänzende Sätze in 'root_squash' , dann in 'no_root_squash' nur die Bemerkung 'unterdrückt root_squash oder 'verhindert root_squash' oder sowas. Kannst ja mal schauen.

Ach ja, bevor wir hier einen um den anderen Punkt diskutieren, richten wir vielleicht doch lieber ne Baustelle ein. Was meinst?

Gruß BillMaier

ich war so lange inaktiv hier im Forum (habe gedacht ich lerne erstmal und mache ein wenig was kaputt, bevor ich ständig doofe Fragen stellen 😉 ).

Ich weiß ehrlich gesagt nicht, was "Baustelle einrichten" genau bedeuten soll. Also zumindest, wenn es irgendwie ein insider ist, stehe ich auf dem Schlauch. 😳 😀

Grundlegend überarbeiten muss man den Artikel nicht. Hier und dort ein paar Ergänzende Worte, vielleicht auch einen zusätzlichen Header oder ein "Achtung"-Kästchen würden die Sache schon etwas mehr abrunden, finde ich.

Nebenbemerkung in Bezug auf die Hosts könnte in etwa so aussehen:

Natürllich kann man in der /etc/export auf dem Server, sowie auch beim 'mount' am Client den Hostnamen anstatt der IP verwenden. Dazu müssen jedoch gewisse Einträge (jeweils am Server sowie auch am Client) in der 'etc/hosts' vorgenommen werden. Weitere Erklärungen in Bezug auf die hosts-Datei und im Bezug auf die Namensauflösung bitte dem folgenden Wiki entnehmen: <Link zum hosts-Wiki>

Nur mal so ins blaue gedacht. Dann könnte der ganze Kram mit der Namensauflöung und 'notebook' weg und man könnte sich im NFS komplett auf das Einrichten und mounten des Shares via IP konzentrieren.

Wenn man es doch irgendwie zeigen möchte, was so möglich ist, kann man auch gern ein Beispiel einfügen und einen Export und einen mount via Hostnamen veranschaulichen. Das wäre ja kein Akt.

Ein oder zwei ergänzende Sätze in 'root_squash' , dann in 'no_root_squash' nur die Bemerkung 'unterdrückt root_squash oder 'verhindert root_squash' oder sowas. Kannst ja mal schauen.

Mach ich. 👍

David1977 schrieb:

Ich weiß ehrlich gesagt nicht, was "Baustelle einrichten" genau bedeuten soll. Also zumindest, wenn es irgendwie ein insider ist, stehe ich auf dem Schlauch. 😳 😀

Die Baustelle ist eine Kopie dieses Artikels. Da kannst du dann in aller Freiheit alles kaputt machen. Wenn fertig, schieben wir den Artikel zurück ins Wiki und ersetzen damit diesen hier. ▶ https://forum.ubuntuusers.de/topic/du-moechtest-einen-artikel-schreiben-oder-ver/

Grundlegend überarbeiten muss man den Artikel nicht. Hier und dort ein paar Ergänzende Worte, vielleicht auch einen zusätzlichen Header oder ein "Achtung"-Kästchen würden die Sache schon etwas mehr abrunden, finde ich.

Ok, dann geht das auch ohne Baustelle. Bzgl. der Achtung-Kästen kannst ja nochmal Bescheid geben hier - manche Artikel sind quasi nur noch rot vor lauter Achtung.

Nur mal so ins blaue gedacht. Dann könnte der ganze Kram mit der Namensauflöung und 'notebook' weg und man könnte sich im NFS komplett auf das Einrichten und mounten des Shares via IP konzentrieren.

Kannst du imho gerne umsetzen. Nur Mut!

Wenn man es doch irgendwie zeigen möchte, was so möglich ist, kann man auch gern ein Beispiel einfügen und einen Export und einen mount via Hostnamen veranschaulichen. Das wäre ja kein Akt.

Dito.

Ich möchte dir Mut machen, es hier einfach probieren. Ich bin mir sicher, der Artikel wird besser. Falls du doch noch Scheu hast ▶ Baustelle.

Viele Grüße

BillMaier

Nicht wundern.

Ist nicht so, dass ich mich nicht traue. Ich habe im Moment einfach nur wenig Zeit. Kurz vor einer Prüfung bzgl einer Linux-basierenden Fortbildung. 😉

Ich kümmere mich ASAP drum

P. s.: und ja, ich habe meinen Nick ändern lassen 😀

Ok, melde dich einfach bei Bedarf wieder. Viel Erfolg bei der Fortbildung!

Gruß BillMaier

Notiz: standardmäßig wird nun wohl NFS4 beim einhängen verwendet, sodass man eine andere Version angeben muss, falls gewünscht.

#  mount -vvt nfs 172.9.10.254:/kubernetes-nfs /mnt/temp
mount.nfs: timeout set for Fri Sep  7 12:05:40 2018
mount.nfs: trying text-based options 'vers=4,addr=172.9.10.254,clientaddr=10.139.0.121'
mount.nfs: mount(2): Protocol not supported
mount.nfs: trying text-based options 'addr=172.9.10.254'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 172.9.10.254 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 172.9.10.254 prog 100005 vers 3 prot UDP port 30000
#  umount /mnt/temp
#  mount -vvt nfs 192.168.73.10:/k8_staging /mnt/temp
mount.nfs: timeout set for Fri Sep  7 12:06:56 2018
mount.nfs: trying text-based options 'vers=4,addr=192.168.73.10,clientaddr=192.168.73.121'
#  umount /mnt/temp
#  mount -vvt nfs -onfsvers=3 192.168.73.10:/k8_staging /mnt/temp
mount.nfs: timeout set for Fri Sep  7 12:07:34 2018
mount.nfs: trying text-based options 'nfsvers=3,addr=192.168.73.10'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 192.168.73.10 prog 100003 vers 3 prot TCP port 2049
mount.nfs: prog 100005, trying vers=3, prot=17
mount.nfs: trying 192.168.73.10 prog 100005 vers 3 prot UDP port 2050

Sollte bei Gelegenheit in den Artikel.

bei einem test auf auf 18.04 ist mir gestern aufgefallen, das /etc/init.d/nfs-common "kommentarlos" mit exit gekillt wird, weil der lsb-script erkennt, dass es eine nfs-common.service (systemd) konfig gibt. Die datei ist aber in wirklichkeit ein link auf /dev/null.

Das sorgt dafür, das nach einer "clean install" NFS (auf clientseite) nicht zu benutzten ist.

Lösung ist die Datei nfs-common.service zu löschen.

Sollten wir das ins Wiki aufnehmen?