[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: NFS geht nicht mehr, als Client wie als Server



Ah jetzt ja, so langsam kommen wir der Sache Näher... hoffe ich mal. :)

Am Sun, 29 Sep 2013 17:03:21 +0200
schrieb Tim Boneko <tim@boneko.de>:

> On Sun, 2013-09-29 at 16:16 +0200, Michael Schmitt wrote:
> 
> 
> > Ansonsten, auch wenn ich nen Kaltstart nicht als
> > besonders wahrscheinlichen Problemlöser ansehe, hau rein. Kannst ja
> > auch mal den Server in Alufolie einpacken. *feix*
> > 
> 
> Hab ich gemacht, hat nix gebracht. Aber ein super Tipp, danke! Wenn
> die Folie ins Gehäuse gezogen wird, gibt's Sound- und Lichteffekte,
> für die andere Leute viel Geld bezahlen. So einfach ist Casemodding!

Kannst ja mal patentieren, ich nehm dann auch nur ne 60% Beteiligung,
bin ja ned so. ;)


> > Die Idee war eigentlich da vom Client ebenfalls mit nc was
> > hinzuschicken, um eben beiderseitig die etwaig "marode" NFS-Schicht
> > durch was vollkommen anderes testweise zu ersetzen.
> 
> Ah jezt ja, verstanden. Ich habe auf dem Server nfs-kernel-server
> beendet, nc -lp 2049 gestartet und auf dem Client nc <server> 2049
> gestartet. Damit konnte ich einwandfrei Eingaben durch das Netz
> schieben.

Hier eindeutig, NFS-Server is der Problemverursacher (oberflächlich
betrachtet), aber...
 
> Umgekehrt funktionierte es erst nicht, vom Server zum Clientport 2049
> konnte ich scheinbar nix schicken. Es ging erst, als ich die IP-
> Adresse als Ziel nahm statt des Hostnamens: Der Server sucht den
> Client unter falscher Adresse:
> 
> root@kellerkind:# host taylor
> taylor.indehell has address 62.157.140.133
> taylor.indehell has address 80.156.86.78
> Host taylor.indehell not found: 3(NXDOMAIN)
> Host taylor.indehell not found: 3(NXDOMAIN)

... das gibt dem ganzen dann doch nen ganz anderen Spin. :) Ich finds
nen bissl komisch, daß der NFS-Server dann keinen "Nee, Du darfst ned!"
an den Client ausgibt, sondern gar nix macht, aber da mag ich grad ned
kreativ genuch sein um das 100% zu blicken. Aber is ja auch bums, ich
hab trotzdem ne grobe Vermutung wie man das Problem lösen *könnte*.


> Alle Clients kriegen die von dnsmasq vergebenen Adressen und
> Hostnamen angezeigt. Nur der Server selbst fragt upstream nach
> internen Namen. Ich habe hier wohl ein dnsmasq- Problem. Zumindest
> wäre das noch ein Ansatz.

Genau, aber fangen wir doch mal beim NFS-Server an. Du hast vermutlich
in der /etc/exports hostnamen statt IP-Adressen verwendet. Füge mal aus
lauter Jux und Dollerei da einen identischen Eintrag hinzu, nur eben
mit IP-Adressen. also sowas ala

/srv            192.168.25.0/24(ro, ...)

dann "exportfs -av" auf dem Server, in der Ausgabe überprüfen ob er die
neue IP-Adressen-basierte Schreibweise akzeptiert und vom client aus
nochmal versuchen das share zu mounten.

Wenn das tut, is DNS sogar zu 100% als ursächliche Fehlerursache
ausgemacht (auch wenn IMHO der NFS-Server zumindest wohl ne Teilschuld
trägt). Dann kannst Du ja mal dem dnsmasq sagen, er soll die Domain
"indehell" als lokale Domain ansehen und überprüfen ob auf den Clients
und dem Server auch sowas ala "search indehell" und "domain indehell"
zumindest auf den Clients drinsteht. Die Optionen sind auch per dhcp
übertragbar. Is leider schon ebbes her, daß ich mich mit dnsmasq
auseinandergesetzt habe, kann Dir daher ned aus dem Kopf sagen wie die
Stellschrauben genau heißen, aber Doku lesen überlasse ich da mal Dir.

Ich will mich zwar noch ned all zu weit aus dem Fenster lehnen und das
Problem als gelöst ansehen, aber guck doch bitte mal in *allen* Logs
auf dem NFS-Server ob da ned irgendwo was drinsteht wie
"unauthenticated mount request from <IP-Adresse>" oder so. Ich würde
auf /var/log/auth.log tippen. Aber dann wäre da noch zu klären warum es
u.A. bei rpcinfo einen Timeout gab statt nem klaren "sorry, Du hast
kaan Derfschein ned". Aber das wäre dann alles Fleißarbeit. Anyway,
schaun wir mal.

Grüße
Michael


Reply to: