Re: Status of mount.nfs

[Steve Dickson <SteveD@redhat.com>]

Chuck Lever wrote:
> Steve Dickson wrote:
>> Chuck Lever wrote:
>>> I was looking at this yesterday.  The stock timeout for TCP connects 
>>> on Linux is 75 seconds.  The version of getport() used in the mount 
>>> command might control the TCP connect timeout by using a non-blocking 
>>> connect() with a select().  The select() then times out if the 
>>> connection doesn't complete.
>>>
>>> But I'm wondering if we really want to continue using TCP for GETPORT 
>>> calls.  Solaris mount appears to use only UDP for GETPORT, for example.
> 
>> As as long as the GETPORTs don't use privilege ports I don't think its
>> a problem...
> 
> Not sure what you mean.  Yesterday you said the TCP connect timeout 
> *was* a problem.  I've recommended two ways to address it.
TCP timeouts are a problem if you can't control them... But
point taken... UPD is probably the best way to query a
portmapper or rpcbinder to get the needed info...

> 
> The ephemeral port space is limited too, don't forget.  It's simply a 
> somewhat larger space than the privileged port space.  If a large 
> network application (say, a web server) is running on the system, that 
> space can shrink fairly rapidly, and we're in nearly the same boat as 
> with privileged ports.  Using a TCP connection from an ephemeral port 
> only mitigates the port space problem, it doesn't really correct it 
> entirely.
Only mitigates the problem for a short time and you'll always run
out of privileged port before running out of non-privileged but
again... point taken... eliminating the problem is probably
the answer...

> 
>> plus I don't think one size fixes all.. meaning due to
>> different firewalls requirements both udp and tcp GETPORTS will be
>> needed... imho...
> 
> We say "firewall!" a lot, but I would like to see typical use cases for 
> mounting through a firewall so I understand what kind of implementation 
> we're aiming for (and maybe even what kind of test cases to build!).  Do 
> our users really expect to mount NFS shares through any firewall with 
> "-o defaults" ?
Yes! Mostly on the server side... meaning people wanted to set the
port the daemons listen on (via the initscripts) so clients can
access the server through a firewall... Is this a common setup?
No. But there are people that want a firewall between the
server and client.. Also I can only assume the reason for the
'mountport=" option was to work better with firewalls...
but that is only speculation...


> 
> I'd like to hear from the distributors what you consider are the use 
> cases that absolutely must be supported.  Otherwise we will end up 
> standing on our left big toenail to support stuff that isn't worth the 
> pain or is never used.
In the end, I think we need to be able to control the ports and
protocol mounts uses, allowing people to punch holes in firewalls.


steved.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs