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

Re: nfs-client starten



Gruesse!
* David Baer <david@student.ethz.ch> schrieb am [12.11.03 14:35]:

Ich verkürze das Reply-Quoting jetzt mal, damits übersichtlicher wird.

Der einzige "Problem"-Ping ist also der vom Laptop zum Server.

> > d) funktionieren andere netz-Programme ohne Fehler bzw. nennenswerte
> >    Verzögerungen?
> >    Kannst du vom Laptop z.B. eine ssh session zum Server machen?
> ja


> > Ich klammere mich deswegen so hartnäckig ;-) an diese Fragen weil DUPs
> > beim Ping eigentlich nicht vorkommen dürfen.
> > Siehe: man ping => DUPLICATE AND DAMAGED PACKETS
> wo die wohl her kommen?
> > 
> > Evtl. ist deine Broadcast-Adresse falsch gesetzt?
> > Poste doch mal die Ausgabe von
> > ifconfig eth0 (oder wie dein interface heißt)suriananda:/etc# ifconfig eth0
> eth0      Link encap:Ethernet  HWaddr 00:0D:60:38:9B:E2
>           inet addr:192.168.1.4  Bcast:192.168.1.7  Mask:255.255.255.248
>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>           RX packets:191603 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:110894 errors:0 dropped:0 overruns:0 carrier:0
>           collisions:72 txqueuelen:100
>           RX bytes:101720010 (97.0 MiB)  TX bytes:8042653 (7.6 MiB)
>           Interrupt:11 Base address:0x8000 Memory:c0220000-c0240000

Ah, eine abenteuerliche Konfiguration ;-)
Wurden dir die Werte für IPs, Broadcast-Adresse und Subnet-Maske von
einem Netz-Admin vorgegeben oder ist das ausschliesslich dein privates
Netz?
Rechen, rechen... :-)
Mit diesen Werten deckt das Netz 192.168. nämlich 32 Subnets mit jeweils
8 Hosts per Subnet ab. Und die Broadcast ist eine Limited-Broadcast.

Wenn es ausschliesslich dein privates Netz ist, gibt es einen Grund für
diese Aufteilung?

Auch müssen an den anderen Rechner im gleichen Subnet 192.168.1.0 -
192.168.1.7 die gleichen Angaben eingetragen sein. Das müßtest du mit
ifconfig mal am Server und Router überprüfen.

> > Bitte auch nochmal die Ausgabe von:
> > ping -c 3 192.168.1.0
> suriananda:/etc# ping -c 3 192.168.1.0
> PING 192.168.1.0 (192.168.1.0): 56 data bytes
> 64 bytes from 192.168.1.4: icmp_seq=0 ttl=64 time=0.0 ms
> 64 bytes from 192.168.1.4: icmp_seq=1 ttl=64 time=0.0 ms
> 64 bytes from 192.168.1.4: icmp_seq=2 ttl=64 time=0.0 ms

Das kann dann auch nicht gehen. Ich bin von einer Standard Broadcast-
und Netmask ausgegangen. Du müßtest also
ping -c 3 192.168.1.7
machen. Da sollten sich dann (Broadcast=Rundruf) alle erreichbaren
Rechner im Subnet melden, also Laptop, Server, Router.

Diese Ausgaben von nfsstat vom Server und das Telnet:

> compuJAH:/home/david/da/la/doc # nfsstat -s
> Server rpc stats:
> calls      badcalls   badauth    badclnt    xdrcall
> 0          0          0          0          0
Hier (und bei der restlichen Ausgabe) zählen sich im normalen
nfs-Betrieb normalerweise die Werte hoch.

Die Zugriffe per telnet auf den server-portmapper (Port 111) hätten
IMHO normalerweise die Zähler anstoßen müssen, aber bei der 2. Ausgabe
von nfsstat kommt:

> Server rpc stats:
> calls      badcalls   badauth    badclnt    xdrcall
> 0          0          0          0          0
usw. ...
Also der Server hat nichts mitgekriegt.

> > d) Wie andere dir schon geraten haben: kannst du (nach entsprechender
> >    Konfiguration /etc/exports) vom Router oder anderer Rechner eine
> >    nfs-Freigabe mounten?  also z.B. am Router:
> >    mount -t nfs 192.168.1.3:/home/david /mnt
> das verstehe ich jetzt nicht ganz.  mount ist ein befehl, der mein router 
> nicht kennt. und ansonsten steht nur noch 'ne windows-büchse am netz. 

Schade, dann können wir den Router als Testrechner, ob der Server richtig
konfiguriert ist, leider vergessen.
> 
> > 	
> > Keine Bange, wir kriegen das schon hin ;-)
> super!

;-) Es wird nurmehr immer schwieriger alle möglichen Lösungsansätze über
diese Liste abzuwickeln. Wenn du in deiner Umgebung vielleicht jemand
hast der unter Einbeziehung der Mails dir helfen könnte, vor Ort?
Ich will diesen Thread meinerseits aber nicht abwürgen. Das sind
eigentlich die Probleme die ich mag ;-))))

> das mit den DUPs beim PING ist sicher ein problem. was mich aber auch noch 
> verwirrt ist 
Ob die Dup-Pings am Problem kratzen (also Netzwerk-Problem) bin ich mir
momentan nicht mehr so sicher wie bei meiner ersten Mail. Vor allem wenn
deine o.a. Konfiguration von IP/Netmask/Broadcast einen wirklichen Sinn
macht. Und ssh funktioniert ja auch.

> 1. dass der portmapper bei ps aux in klammern dasteht und

Das bedeutet, das der Prozeß ins Swapfile ausgelagert wurde, aus "Mangel
an Benutzung" oder zu geringem Speicher. Siehe auch
man ps, suche nach brackets. Dann wird auch der Programmpfad nicht
angezeigt.

> 2. dass beim /proc/filesystems keinen nfs eintrag hat.
> was bedeutet dies, und wie kann ich es beheben? 

modprobe nfs, wenn du das nfs-filesystem als Modul kompiliert hat.
Solange du kein nfs benutzt, wird das Modul nicht geladen, somit auch
nicht in /proc zu sehen.

> 
> ausserdem bin ich mir nicht sicher, ob ich auf debian seite irgendwelche 
> firewalls hab.  auf suse seite hab ich die ports 111 und 2048 geöffnet.

nfs=2049, aber das hast du ja schon korrigiert.
Debian (woody) hat out of the box keine Firewall aktiv. Wenn du eine
eingerichtet hast würde ich diese zum Testen auf jedenfall deaktivieren.

Beim Server (suse) schreibst du "hab ich die ports ... geöffnet". Läuft
auf dem Server eine Firewall? Wenn ja, hast du beim "Öffnen" der Ports
auch 111/udp und 2049/udp freigegeben, und nicht nur tcp? Das wird gerne
vergessen. Evtl. am Server die FW mal deaktivieren.

Eine Möglichkeit (wenn in deinem Fall auch entfernt) wäre noch: es gibt
einen kernel-space-nfs-server und einen user-space. Der ältere
user-space basierende macht manchmal im Zusammenhang mit RPC Probleme.
Wie du das jetzt rauskriegst für den suse-server? Ich glaub, es gab im
yast eine Option wo man wählen konnte zwischen user- und kernel-space,
irgendas mit use_nfs_kernel_server. Ist schon länger her. Da würde ich
testweise mal den kernel-space nehmen.

Ansonsten mal zum Vergleich: bei mir sind nfs-mäßig folgende Prozesse
aktiv, mit ps:

Server (debian): 
mehrere [nfsd]
[portmap]
/sbin/rpc.statd
[rpciod]
/usr/sbin/rpc.mountd

Client (debian, nfs-server auch gestartet, aber kein export):
/sbin/portmap
[rpciod]
/sbin/rpc.statd

> vielen dank
> david

Deine mail an die nfs-sourceforge habe ich gesehen, die Angaben zeigen
IMHO nicht ausßergewöhnliches was wir nicht schon angesprochen hätten.
Vielleicht sieht ein anderes Listenmitglied noch was.

Ciao,
	Gerhard



Reply to: