From: Steve Dickson <SteveD@redhat.com>
To: Olaf Kirch <olaf.kirch@oracle.com>
Cc: "Talpey, Thomas" <Thomas.Talpey@netapp.com>,
nfs@lists.sourceforge.net, Bernhard Busch <bbusch@biochem.mpg.de>
Subject: Re: NFS mount problem (2000 NFS filesystems) of linux clients to a solaris server
Date: Tue, 13 Mar 2007 09:11:01 -0400 [thread overview]
Message-ID: <45F6A2E5.1040306@RedHat.com> (raw)
In-Reply-To: <200703091525.15438.olaf.kirch@oracle.com>
Olaf Kirch wrote:
> On Friday 09 March 2007 13:16, Bernhard Busch wrote:
>> But , if i remove the sleep command the
>>
>> nfs bindresvport: Address already in use
>
> This is a message from the mount command, and it's really
> a problem in the RPC library. At some point, mount would
> use 2 ports per mount (one when doing pmap_getport, the
> other when talking to the server's mountd). I think the getport
> call was fixed a while ago, as it doesn't really need a privport
> at all. But for many NFS servers, a privileged port is a must
> when talking to mountd.
True... there was a bug in the glibc code that was causing
pmap port queries to use privileged ports and the entire
privileged port range was not being used... both were fixed
while back...
>
> I think one reasonable fix for this would be to make mount
> (or the rpc library) issue a setsockopt(SOL_SOCKET, SO_REUSEADDR)
> *after* it's done with the request, and before closing the socket. That way,
> we can immediately rebind to this port, without risking confusion by having to
> mount commands bind to the same port at the same time.
I looked into doing this and it got really messy quick... Remember
SO_REUSEADDR is basically a server option used for listening
sockets... so when you use this option on the client, it works
but puts the socket in a very weird state... something just
looked wrong...
I'm of the option the true answer is, Stop using privileged ports
all together. The notion that using privileged ports give any
type of security is a bit absurd... imho... Especially now that we
have true security with the -o sec=<whatever> option...
So I'm thinking we should start allowing the actual NFS mount/traffic
to exist on any port and only keep the privileged port silliness
for mountd quires... something that could actually be done over
UDP (assuming there are no firewall issues)....
steved.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
prev parent reply other threads:[~2007-03-13 13:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-08 12:42 NFS mount problem (2000 NFS filesystems) of linux clients to a solaris server Bernhard Busch
2007-03-08 13:08 ` Talpey, Thomas
2007-03-09 12:16 ` Bernhard Busch
2007-03-09 13:09 ` Talpey, Thomas
2007-03-09 14:46 ` Olaf Kirch
2007-03-09 15:04 ` Talpey, Thomas
2007-03-12 12:35 ` Talpey, Thomas
2007-03-12 16:57 ` Trond Myklebust
2007-03-09 14:25 ` Olaf Kirch
2007-03-13 13:11 ` Steve Dickson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45F6A2E5.1040306@RedHat.com \
--to=steved@redhat.com \
--cc=Thomas.Talpey@netapp.com \
--cc=bbusch@biochem.mpg.de \
--cc=nfs@lists.sourceforge.net \
--cc=olaf.kirch@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.