[RndTbl] wacky NFS port problem

[Adam Thompson]

Also, most distros now seem to have a service called 'portreserve' that runs very early in the boot process, grabs all the critical ports  and then lets them go one by one as other services start up and ask for them.
I recall from my reading that RPC and NFS were the primary reason this thing existed.
-Adam


> -----Original Message-----
> From: roundtable-bounces at muug.mb.ca [mailto:roundtable-
> bounces at muug.mb.ca] On Behalf Of Trevor Cordes
> Sent: October 24, 2016 03:58
> To: roundtable at muug.mb.ca
> Subject: Re: [RndTbl] wacky NFS port problem
> 
> On 2016-10-24 Trevor Cordes wrote:
> > It would be really nice if I could specify the local source port, or
> > at least specify the list of no-no ports using this elusive, promised,
> > "sysctl".  Anyone have any ideas?
> 
> Sigh... as often the case, after writing my email I found the answer, this
> was a tough one!  Had to use the source patch logs to get some hints.  I
> didn't want to grep the files in sys and proc for nfs, but sunrpc.
> 
> #find /proc/ /sys/ | grep sunrpc |grep port
> /proc/sys/sunrpc/max_resvport /proc/sys/sunrpc/min_resvport
> 
> #tail -c+1 /proc/sys/sunrpc/m??_resvport ==>
> /proc/sys/sunrpc/max_resvport <==
> 1023
> 
> ==> /proc/sys/sunrpc/min_resvport <==
> 665
> 
> Also 2 files in:
> /sys/module/sunrpc/parameters/m??_resvport
> 
> Might need to tweak.
> 
> Tada!  I'll just tweak those to a tiny range I know for sure I won't use at
> all, and still be under 1024.
> 
> Note, each mount takes another of those ports, so if you mount a large
> number of remote fs's then you need a big enough range.  I only mount
> 1 NFS mount, so I'm good with a tiny (1?) range.
> 
> A bit presumptuous of them to assume anything over 665 is "safe"!!
> 
> Moral of the story, if you use NFSv4 and you run critical services over
> port 664, you better set these sysctl's to avoid this problem.
> 
> Aside: I may also be forgetting my raw socket programming, but I didn't
> think using a source port to connect to something external (i.e. as an
> initiator) tied up that port completely keeping others from
> bind/listen()ing on it?  I thought as long as you were the only
> bind/listen()er it didn't matter what ports other progs took?  I could be
> massively wrong on this...
> _______________________________________________
> Roundtable mailing list
> Roundtable at muug.mb.ca
> http://www.muug.mb.ca/mailman/listinfo/roundtable