Op zaterdag 19 oktober 2002 07:07, schreef Jim Carter:
On Sat, 19 Oct 2002, Richard Bos wrote:
I want to perform an NFS installation from SuSE-8.0...
server: 192.168.3.1 client: 192.168.5.1
I started wrong directly from the beginning, I should have choosen the client and server at the same network. New assignment: server: 192.168.3.1 client: 192.168.3.2 I assume that this makes the configuration easier to understand and at least its more clear to what I want. So, now I thought it will almost work right away, but it still shows the same behaviour :( server: ifconfig eth0 192.168.3.1 route add default eth0 (I removed all the other routes) client: ifconfig eth0 192.168.3.2 route add default eth0 I made no further routing alterations. At the client: # rpcinfo -p 192.168.3.1 shows all the expected output. The command: # mount -o ro -t nfs dar:/dist/suse-8.0 /var/adm/dist takes a very long time to complete, but then at the end the volume is mounted. # dmesg says (for several tries): ortmap: server localhost not responding, timed out portmap: server localhost not responding, timed out lockd_up: makesock failed, error=-5 portmap: server localhost not responding, timed out lockd_down: no lockd running. portmap: server localhost not responding, timed out portmap: server localhost not responding, timed out portmap: server localhost not responding, timed out Oct 19 12:06:11 dar rpc.mountd: authenticated mount request from 192.168.3.2:941 for /dist/suse-8.0 (/dist/suse-8.0) I assume routing is still incorrect, but what is wrong? [continued below]
server route activated via: ifconfig eth0 192.168.3.1 route add -net 192.168.5.0 netmask 255.255.255.0 gw 192.168.3.1 eth0
So the client could send ARP to the server, the server could answer back (since ARP doesn't use IP addresses), the client could send a UDP packet to the server's mountd and the server would get it, and the server would send its reply to... itself? And itself would forward the packet to the gateway that handles the 5-net, namely itself. The server reports that it accepted the client's authentication, but the client reports that it never got the filehandle from mountd, which is no lie.
I think you want:
route add -net 192.168.5.0 netmask 255.255.255.0 dev eth0
server route activated via: ifconfig eth0 192.168.5.1 route add default eth0
Actually the client, right? Assuming that the network has an egress path to the Internet, and that path is on the NFS server (which had better have a good firewall or the hackers are going to chew up its NFS), the client needs to use the egress gateway as its default route. This will also take care of the jump to the rest of the 3-net. Like this (order is important):
route add -net 192.168.3.0 netmask 255.255.255.0 dev eth0 route add default gw 192.168.3.1
I don't know your net setup, but it's not common to put two non-interacting subnets on the same Ethernet cable. They still fight for the resource, but don't get the benefit of being able to talk to each other except via a router that's hard to configure. At one time at UCLA we had a ~512 member subnet, using a netmask of 255.255.254.0. If your situation is too many machines that you're unable to split in 2 subnets, you might consider choking down the netmask like that, rather than trying to route traffic for the other net through dev eth0.
At the server, the file /var/lib/nfs/xtab has the following (strange) contents: /dist/suse-8.0 192.168.5.1(ro,async,wdelay,hide,insecure,root_squash,no_all_squash,subtr ee_check,secure_locks,mapping=identity,anonuid=-2,anongid=-2) ... etc ... BTW: how can I tidy this?
xtab is maintained by the NFS server in its own way, and the sysop should consider it readonly. /etc/exports is what needs to be tidy :-)
Agreed, The /etc/exports is tidy. But all the entries in the xtab file are not relevant anymore. That's the reason if it possible to get it cleaned up, it looks like I confused the nfsserver with my trials :( -- Richard Bos Without a home the journey is endless