On Mon, Aug 12, 2002 at 03:43:21PM +0200, Schoenwaelder Oliver wrote:
we have two SuSE 8.0 (kernel 2.4.18 and all the latest patches) running on two sites, connected via internet. Server A has public ip address and server B is host on private LAN behind NATed gateway.
Bad idea.
Now we exported a directory on server A via nfs. At server B we mount this directory. For our firewall (iptables) we opened upd ports for rpc (111) and nfs(2049).
It gets worse...
And after each reboot we have to add/modify the mountd port (got with rpcinfo -p localhost).
... and worse... :)
But I think there must be an exact definition of what to allow for nfs on client and server side. But what?
The client wants to access the server's portmapper, nfsd, and mountd. If you didn't turn on file locks on the client, it also wants to talk to the server's lockd and statd (and vice versa: the server also wants to talk to the client's lockd and statd). FWIW, you can tell mountd to bind to a specific port using the -p command line option.
And we have a very poor nfs performance. Doing an "ls" on one of subdirs with few files is ok, but with another subdir which contains 100+ files this proccess doesn't return in proper time (it takes minutes!!!). Any idea?
This is not surprising. NFS was designed as a protocol for LANs, not for the Internet. You may be able to improve performance if you lower rsize and wsize to 1024 bytes; this avoids fragmentation of UDP datagrams and helps stability. But overall I would recomment to use rsync or similar to synchronize data across the Internet, not NFS. Olaf -- Olaf Kirch | Anyone who has had to work with X.509 has probably okir@suse.de | experienced what can best be described as ---------------+ ISO water torture. -- Peter Gutmann