All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Dickson <SteveD@redhat.com>
To: Jeff Layton <jlayton@redhat.com>
Cc: Linux NFS Mailing list <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH 0/3] mountd: disabling turning off TCP listeners (v2)
Date: Fri, 25 Oct 2013 08:23:29 -0400	[thread overview]
Message-ID: <526A62C1.6060803@RedHat.com> (raw)
In-Reply-To: <20131025074316.2affe9e9@tlielax.poochiereds.net>



On 25/10/13 07:43, Jeff Layton wrote:
> On Thu, 24 Oct 2013 15:45:03 -0400
> Steve Dickson <SteveD@redhat.com> wrote:
> 
>>
>>
>> On 24/10/13 14:45, Jeff Layton wrote:
>>> On Thu, 24 Oct 2013 14:17:10 -0400
>>> Steve Dickson <steved@redhat.com> wrote:
>>>
>>>> [ Here is the second try for these patches incorporating the code review..]
>>>>
>>>> Recently it was pointed out to me that the [-n | --no-tcp] flags 
>>>> were broken in mountd. Sure enough they are and they broke 
>>>> when nfs-utils moved to using libtirpc, which was years ago.
>>>>
>>>> Obviously nobody is using these flags since has not been 
>>>> notice until now, but it seemed to me it no longer makes 
>>>> any sense to have flags. We really want people to use TCP 
>>>> so why should there be a way to turn it off? It should be
>>>> the opposite... They should be able to turn off UDP listeners
>>>> not TCP... 
>>>>
>>>>
>>>> Steve Dickson (3):
>>>>   mountd: Use protocol bit fields to turn protocols off.
>>>>   mountd: Deprecate the ability to disable TCP listeners.
>>>>   mountd: Add the ability to disable UDP listeners.
>>>>
>>>>  support/include/rpcmisc.h |  2 +-
>>>>  support/nfs/rpcmisc.c     | 19 ++++++++++++++-----
>>>>  support/nfs/svc_create.c  |  5 +++++
>>>>  utils/mountd/mountd.c     | 17 ++++++++++++-----
>>>>  utils/mountd/mountd.man   |  6 +++---
>>>>  5 files changed, 35 insertions(+), 14 deletions(-)
>>>>
>>>
>>> Sorry I'm coming in late on this...
>> np... I was expecting more push back! ;-) 
>>
>>>
>>> I don't think we want to remove the ability to disable TCP listeners.
>>>
>>> Why, you ask? We've been on a multi-year effort to move people to
>>> NFSv4, and with that, there's no reason to have mountd listen on the
>>> network at all.
>> True...
>>
>>>
>>> So personally, I think it would make sense to:
>>>
>>> a) allow people to disable listening on UDP in addition to TCP
>> I see no reason whatsoever to turn off TCP listeners especially
>> since that is the protocol of choice... something we have 
>> be spouting about for years...  
>>  
> 
> There are reasons to be able to turn off TCP listeners:
> 
> If you're running a NFSv4-only server, there's no reason to allow it to
> listen on TCP _or_ UDP sockets. I think that sort of environment is
> going to become more prevalent in the future, not less.
I ideally it would be best not to have mountd at all on NFSv4-only server.
Basically, have the kernel get its exports like it gets it ID mappings.
Until that day comes, which I hope fill be soon, the TCP listener 
only effects v3 mounts and we definitely want people to use TCP
with v3. 
 
 
> 
>>>
>>> ...or...
>>>
>>> b) add an option that prevents it from listening on any sockets for a
>>>    v4-only configuration
>> In this case it would optimal to not even start mountd, unfortunately
>> due to exports reasons, it not possible... but it should be!! :-) 
>>   
> 
> Right, mountd has 2 jobs:
> 
> 1) respond to MNT protocol requests from clients
> 
> ...and...
> 
> 2) feed exports info to the kernel
> 
> For v4, you obviously don't need the first role, so being able to
> disable network listeners is a good thing in such a configuration.
Again, I would rather build an v4 only environment where mountd
does not even run... 

steved.
 
> 
>>>
>>> In addition, we generally do want people to use UDP for the MNT
>>> protocol because it's less apt to cause issues with reserved port
>>> exhaustion. Given that it'll continue to listen on a UDP socket by
>>> default, that last point is less of an issue, but that might be a good
>>> reason to rethink this whole plan.
>>>
>> I did think of this.... UDP is on by default... Is up the admin... 
>>
> 
> That's good. I have no objection to adding an option to disable UDP
> listeners if the admin chooses. I just think it would be best to fix
> the ability to disable TCP listeners as well instead of removing it.
> 

  reply	other threads:[~2013-10-25 12:22 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-24 18:17 [PATCH 0/3] mountd: disabling turning off TCP listeners (v2) Steve Dickson
2013-10-24 18:17 ` [PATCH 1/3] mountd: Use protocol bit fields to turn protocols off Steve Dickson
2013-10-24 18:17 ` [PATCH 2/3] mountd: Deprecate the ability to disable TCP listeners Steve Dickson
2013-10-24 18:17 ` [PATCH 3/3] mountd: Add the ability to disable UDP listeners Steve Dickson
2013-10-24 18:45 ` [PATCH 0/3] mountd: disabling turning off TCP listeners (v2) Jeff Layton
2013-10-24 19:45   ` Steve Dickson
2013-10-25 11:43     ` Jeff Layton
2013-10-25 12:23       ` Steve Dickson [this message]
2013-10-25 12:29         ` Jeff Layton
2013-10-25 12:55           ` Steve Dickson
2013-10-25 13:03             ` Jeff Layton
2013-10-25 13:31               ` Steve Dickson
2013-10-25 14:20         ` J. Bruce Fields
2013-10-25 15:18           ` Steve Dickson
2013-10-26 18:55             ` J. Bruce Fields
2013-10-26 19:10               ` Stanislav Kinsbursky
2013-10-26 19:22                 ` J. Bruce Fields
2013-10-25 14:31 ` Chuck Lever

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=526A62C1.6060803@RedHat.com \
    --to=steved@redhat.com \
    --cc=jlayton@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    /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.