From: Frank van Maarseveen <frankvm@frankvm.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Mohit Katiyar <katiyar.mohit@gmail.com>,
Linux NFS mailing list <nfs@lists.sourceforge.net>,
linux-kernel@vger.kernel.org
Subject: Re: NFS inconsistent behaviour
Date: Wed, 18 Oct 2006 22:09:36 +0200 [thread overview]
Message-ID: <20061018200936.GA14733@janus> (raw)
In-Reply-To: <1161199580.6095.112.camel@lade.trondhjem.org>
On Wed, Oct 18, 2006 at 03:26:20PM -0400, Trond Myklebust wrote:
> On Wed, 2006-10-18 at 20:38 +0200, Frank van Maarseveen wrote:
> > I ran out of privileged ports due to treemounting on /net from about 50
> > servers. The autofs program map for this uses the "showmount" command and
> > that one apparently uses privileged ports too (buried inside RPC client
> > libs part of glibc IIRC). The combination broke autofs and a number of
> > other services because there were no privileged ports left anymore.
>
> Yeah. The RPC library appears to always try to grab a privileged port if
> it can. One solution would be to have the autofs scripts drop all
> privileges before calling showmount.
>
> I suppose we could also change the showmount program to create a socket
> that is bound to an unprivileged port, then use
> clnttcp_create()/clntudp_create().
>
> We could probably do the same in the "mount" program when doing things
> like interrogating the portmapper, probing for rpc ports etc. The only
> case where mount might actually need to use a privileged port is when
> talking to mountd. Even then, it could be trained to first try using an
> unprivileged port.
If we could fix why there are that many connections in state TIME_WAIT
then using privileged ports would not be a problem either.
--
Frank
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
WARNING: multiple messages have this Message-ID (diff)
From: Frank van Maarseveen <frankvm@frankvm.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Mohit Katiyar <katiyar.mohit@gmail.com>,
Linux NFS mailing list <nfs@lists.sourceforge.net>,
linux-kernel@vger.kernel.org
Subject: Re: [NFS] NFS inconsistent behaviour
Date: Wed, 18 Oct 2006 22:09:36 +0200 [thread overview]
Message-ID: <20061018200936.GA14733@janus> (raw)
In-Reply-To: <1161199580.6095.112.camel@lade.trondhjem.org>
On Wed, Oct 18, 2006 at 03:26:20PM -0400, Trond Myklebust wrote:
> On Wed, 2006-10-18 at 20:38 +0200, Frank van Maarseveen wrote:
> > I ran out of privileged ports due to treemounting on /net from about 50
> > servers. The autofs program map for this uses the "showmount" command and
> > that one apparently uses privileged ports too (buried inside RPC client
> > libs part of glibc IIRC). The combination broke autofs and a number of
> > other services because there were no privileged ports left anymore.
>
> Yeah. The RPC library appears to always try to grab a privileged port if
> it can. One solution would be to have the autofs scripts drop all
> privileges before calling showmount.
>
> I suppose we could also change the showmount program to create a socket
> that is bound to an unprivileged port, then use
> clnttcp_create()/clntudp_create().
>
> We could probably do the same in the "mount" program when doing things
> like interrogating the portmapper, probing for rpc ports etc. The only
> case where mount might actually need to use a privileged port is when
> talking to mountd. Even then, it could be trained to first try using an
> unprivileged port.
If we could fix why there are that many connections in state TIME_WAIT
then using privileged ports would not be a problem either.
--
Frank
next prev parent reply other threads:[~2006-10-18 20:09 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-16 7:05 NFS inconsistent behaviour Mohit Katiyar, Noida
2006-10-16 7:13 ` Mohit Katiyar
2006-10-16 8:46 ` Frank van Maarseveen
2006-10-16 9:35 ` Mohit Katiyar
2006-10-16 9:39 ` Frank van Maarseveen
2006-10-18 1:22 ` Mohit Katiyar
2006-10-18 6:39 ` Frank van Maarseveen
2006-10-18 17:57 ` Trond Myklebust
2006-10-18 18:37 ` Trond Myklebust
2006-10-18 18:37 ` Trond Myklebust
2006-10-18 18:38 ` Frank van Maarseveen
2006-10-18 18:38 ` Frank van Maarseveen
2006-10-18 19:26 ` Trond Myklebust
2006-10-18 19:26 ` Trond Myklebust
2006-10-18 20:09 ` Frank van Maarseveen [this message]
2006-10-18 20:09 ` [NFS] " Frank van Maarseveen
2006-10-18 20:17 ` Chuck Lever
2006-10-18 20:17 ` [NFS] " Chuck Lever
2006-10-18 20:44 ` Trond Myklebust
2006-10-18 20:44 ` [NFS] " Trond Myklebust
2006-10-19 12:11 ` Alan Cox
2006-10-19 1:53 ` Mohit Katiyar
2006-10-19 1:53 ` Mohit Katiyar
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=20061018200936.GA14733@janus \
--to=frankvm@frankvm.com \
--cc=katiyar.mohit@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nfs@lists.sourceforge.net \
--cc=trond.myklebust@fys.uio.no \
/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.