linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] manpage: explain why showmount doesn't really work against a v4-only server
@ 2019-05-10 21:54 Jeff Layton
  2019-05-11 13:54 ` J. Bruce Fields
  2019-06-03 14:27 ` Steve Dickson
  0 siblings, 2 replies; 9+ messages in thread
From: Jeff Layton @ 2019-05-10 21:54 UTC (permalink / raw)
  To: steved; +Cc: linux-nfs, jfajerski

From: Jeff Layton <jlayton@redhat.com>

I occasionally see people that expect valid info when running showmount
against a server that may export some or all filesystems via NFSv4.
Let's make it clear that it only works by talking to the remote MNT
service, and that that may not be available from a v4-only server.

Cc: Jan Fajerski <jfajerski@suse.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
---
 utils/showmount/showmount.man | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/utils/showmount/showmount.man b/utils/showmount/showmount.man
index a2f510fb5617..35818e1b61c5 100644
--- a/utils/showmount/showmount.man
+++ b/utils/showmount/showmount.man
@@ -56,5 +56,10 @@ Because
 .B showmount
 sorts and uniqs the output, it is impossible to determine from
 the output whether a client is mounting the same directory more than once.
+.P
+.B showmount
+works by contacting the server's MNT service directly. NFSv4-only servers have
+no need to advertise their exported root filehandles via this method, and may
+not expose their MNT service to clients.
 .SH AUTHOR
 Rick Sladkey <jrs@world.std.com>
-- 
2.21.0


^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH] manpage: explain why showmount doesn't really work against a v4-only server
  2019-05-10 21:54 [PATCH] manpage: explain why showmount doesn't really work against a v4-only server Jeff Layton
@ 2019-05-11 13:54 ` J. Bruce Fields
  2019-05-13  8:12   ` Jan Fajerski
                     ` (2 more replies)
  2019-06-03 14:27 ` Steve Dickson
  1 sibling, 3 replies; 9+ messages in thread
From: J. Bruce Fields @ 2019-05-11 13:54 UTC (permalink / raw)
  To: Jeff Layton; +Cc: steved, linux-nfs, jfajerski

On Fri, May 10, 2019 at 05:54:45PM -0400, Jeff Layton wrote:
> From: Jeff Layton <jlayton@redhat.com>
> 
> I occasionally see people that expect valid info when running showmount
> against a server that may export some or all filesystems via NFSv4.
> Let's make it clear that it only works by talking to the remote MNT
> service, and that that may not be available from a v4-only server.

Looks fine.

I wonder if it'd also be helpful for showmount to detect this case and
say something.  E.g. the following (not even compileable, but you get
the idea).

We've also talked about trying to cobble together an export list by
scanning the root filesystem over NFSv4, but that's likely to be
complicated and wouldn't give all the same results without further
protocol extensions anyway, so I think that idea's dead.

--b.

diff --git a/utils/showmount/showmount.c b/utils/showmount/showmount.c
index 394f5284a219..de9a6d38783a 100644
--- a/utils/showmount/showmount.c
+++ b/utils/showmount/showmount.c
@@ -115,6 +115,22 @@ static CLIENT *nfs_get_mount_client(const char *hostname, rpcvers_t vers)
 	exit(1);
 }
 
+void warn_if_v4_only(char *hostname)
+{
+	struct sockaddr_in server_addr, client_addr;
+
+	if (fill_ipv4_sockaddr(hostname, &serveraddr))
+		return;
+	server_addr.sin_port = htnos(NFS_PORT);
+	client_addr.sin_family = 0;
+	client_addr.sin_addr.s_addr = 0;
+	clnt_ping(&server_addr, NFS_PROGRAM, 4, "tcp", &client_addr);
+
+	if (rpc.createerr == RPC_SUCCESS)
+		printf("Server responding to NFSv4 but not MNT; try mounting "
+			"%s:/ instead of showmount", hostname);
+}
+
 int main(int argc, char **argv)
 {
 	char hostname_buf[MAXHOSTLEN];
@@ -199,6 +215,7 @@ int main(int argc, char **argv)
 		fprintf(stderr, "%s: unable to create RPC auth handle.\n",
 				program_name);
 		clnt_destroy(mclient);
+		warn_if_v4_only(hostname);
 		exit(1);
 	}
 	total_timeout.tv_sec = TOTAL_TIMEOUT;

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH] manpage: explain why showmount doesn't really work against a v4-only server
  2019-05-11 13:54 ` J. Bruce Fields
@ 2019-05-13  8:12   ` Jan Fajerski
  2019-05-13 13:29   ` Jeff Layton
  2019-05-29 13:15   ` Steve Dickson
  2 siblings, 0 replies; 9+ messages in thread
From: Jan Fajerski @ 2019-05-13  8:12 UTC (permalink / raw)
  To: J. Bruce Fields; +Cc: Jeff Layton, steved, linux-nfs

On Sat, May 11, 2019 at 09:54:42AM -0400, J. Bruce Fields wrote:
>On Fri, May 10, 2019 at 05:54:45PM -0400, Jeff Layton wrote:
>> From: Jeff Layton <jlayton@redhat.com>
>>
>> I occasionally see people that expect valid info when running showmount
>> against a server that may export some or all filesystems via NFSv4.
>> Let's make it clear that it only works by talking to the remote MNT
>> service, and that that may not be available from a v4-only server.
Looks good...thanks Jeff!
>
>Looks fine.
>
>I wonder if it'd also be helpful for showmount to detect this case and
>say something.  E.g. the following (not even compileable, but you get
>the idea).
This would be ideal of course.
>
>We've also talked about trying to cobble together an export list by
>scanning the root filesystem over NFSv4, but that's likely to be
>complicated and wouldn't give all the same results without further
>protocol extensions anyway, so I think that idea's dead.
>
>--b.
>
>diff --git a/utils/showmount/showmount.c b/utils/showmount/showmount.c
>index 394f5284a219..de9a6d38783a 100644
>--- a/utils/showmount/showmount.c
>+++ b/utils/showmount/showmount.c
>@@ -115,6 +115,22 @@ static CLIENT *nfs_get_mount_client(const char *hostname, rpcvers_t vers)
> 	exit(1);
> }
>
>+void warn_if_v4_only(char *hostname)
>+{
>+	struct sockaddr_in server_addr, client_addr;
>+
>+	if (fill_ipv4_sockaddr(hostname, &serveraddr))
>+		return;
>+	server_addr.sin_port = htnos(NFS_PORT);
>+	client_addr.sin_family = 0;
>+	client_addr.sin_addr.s_addr = 0;
>+	clnt_ping(&server_addr, NFS_PROGRAM, 4, "tcp", &client_addr);
>+
>+	if (rpc.createerr == RPC_SUCCESS)
>+		printf("Server responding to NFSv4 but not MNT; try mounting "
>+			"%s:/ instead of showmount", hostname);
>+}
>+
> int main(int argc, char **argv)
> {
> 	char hostname_buf[MAXHOSTLEN];
>@@ -199,6 +215,7 @@ int main(int argc, char **argv)
> 		fprintf(stderr, "%s: unable to create RPC auth handle.\n",
> 				program_name);
> 		clnt_destroy(mclient);
>+		warn_if_v4_only(hostname);
> 		exit(1);
> 	}
> 	total_timeout.tv_sec = TOTAL_TIMEOUT;
>

-- 
Jan Fajerski
Engineer Enterprise Storage
SUSE Linux GmbH, GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] manpage: explain why showmount doesn't really work against a v4-only server
  2019-05-11 13:54 ` J. Bruce Fields
  2019-05-13  8:12   ` Jan Fajerski
@ 2019-05-13 13:29   ` Jeff Layton
  2019-05-13 13:44     ` J. Bruce Fields
  2019-05-29 13:15   ` Steve Dickson
  2 siblings, 1 reply; 9+ messages in thread
From: Jeff Layton @ 2019-05-13 13:29 UTC (permalink / raw)
  To: J. Bruce Fields; +Cc: steved, linux-nfs, jfajerski

On Sat, 2019-05-11 at 09:54 -0400, J. Bruce Fields wrote:
> On Fri, May 10, 2019 at 05:54:45PM -0400, Jeff Layton wrote:
> > From: Jeff Layton <jlayton@redhat.com>
> > 
> > I occasionally see people that expect valid info when running showmount
> > against a server that may export some or all filesystems via NFSv4.
> > Let's make it clear that it only works by talking to the remote MNT
> > service, and that that may not be available from a v4-only server.
> 
> Looks fine.
> 
> I wonder if it'd also be helpful for showmount to detect this case and
> say something.  E.g. the following (not even compileable, but you get
> the idea).
> 
> We've also talked about trying to cobble together an export list by
> scanning the root filesystem over NFSv4, but that's likely to be
> complicated and wouldn't give all the same results without further
> protocol extensions anyway, so I think that idea's dead.
> 

Agreed.

> --b.
> 
> diff --git a/utils/showmount/showmount.c b/utils/showmount/showmount.c
> index 394f5284a219..de9a6d38783a 100644
> --- a/utils/showmount/showmount.c
> +++ b/utils/showmount/showmount.c
> @@ -115,6 +115,22 @@ static CLIENT *nfs_get_mount_client(const char *hostname, rpcvers_t vers)
>  	exit(1);
>  }
>  
> +void warn_if_v4_only(char *hostname)
> +{
> +	struct sockaddr_in server_addr, client_addr;
> +
> +	if (fill_ipv4_sockaddr(hostname, &serveraddr))
> +		return;
> +	server_addr.sin_port = htnos(NFS_PORT);
> +	client_addr.sin_family = 0;
> +	client_addr.sin_addr.s_addr = 0;
> +	clnt_ping(&server_addr, NFS_PROGRAM, 4, "tcp", &client_addr);
> +
> +	if (rpc.createerr == RPC_SUCCESS)
> +		printf("Server responding to NFSv4 but not MNT; try mounting "
> +			"%s:/ instead of showmount", hostname);
> +}
> +
>  int main(int argc, char **argv)
>  {
>  	char hostname_buf[MAXHOSTLEN];
> @@ -199,6 +215,7 @@ int main(int argc, char **argv)
>  		fprintf(stderr, "%s: unable to create RPC auth handle.\n",
>  				program_name);
>  		clnt_destroy(mclient);
> +		warn_if_v4_only(hostname);
>  		exit(1);
>  	}
>  	total_timeout.tv_sec = TOTAL_TIMEOUT;

Yeah, that certainly wouldn't hurt. I'd suggest we add that in a
separate patch though.

We will need to spell this out in the manpage either way. At least with
ganesha, you can export some filesystems via v3 and others via v4 only,
and the MNT service there will only report the v3 ones. In that case,
you have a reachable service, but the v4-only filesystems will be
missing from showmount's output.
-- 
Jeff Layton <jlayton@kernel.org>


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] manpage: explain why showmount doesn't really work against a v4-only server
  2019-05-13 13:29   ` Jeff Layton
@ 2019-05-13 13:44     ` J. Bruce Fields
  2019-05-13 14:19       ` Frank Filz
  0 siblings, 1 reply; 9+ messages in thread
From: J. Bruce Fields @ 2019-05-13 13:44 UTC (permalink / raw)
  To: Jeff Layton; +Cc: steved, linux-nfs, jfajerski

On Mon, May 13, 2019 at 09:29:42AM -0400, Jeff Layton wrote:
> Yeah, that certainly wouldn't hurt. I'd suggest we add that in a
> separate patch though.

Agreed.

> We will need to spell this out in the manpage either way. At least with
> ganesha, you can export some filesystems via v3 and others via v4 only,
> and the MNT service there will only report the v3 ones. In that case,
> you have a reachable service, but the v4-only filesystems will be
> missing from showmount's output.

That doesn't sound like a great idea to me, but maybe you have no choice
if for some reason you want to allow simultaneous support for v3-only
clients and for filesystems that require long filehandles?  Ugh.

Anyway, this kind of warning doesn't have to catch every odd case.

--b.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* RE: [PATCH] manpage: explain why showmount doesn't really work against a v4-only server
  2019-05-13 13:44     ` J. Bruce Fields
@ 2019-05-13 14:19       ` Frank Filz
  0 siblings, 0 replies; 9+ messages in thread
From: Frank Filz @ 2019-05-13 14:19 UTC (permalink / raw)
  To: 'J. Bruce Fields', 'Jeff Layton'
  Cc: steved, linux-nfs, jfajerski

> On Mon, May 13, 2019 at 09:29:42AM -0400, Jeff Layton wrote:
> > Yeah, that certainly wouldn't hurt. I'd suggest we add that in a
> > separate patch though.
> 
> Agreed.
> 
> > We will need to spell this out in the manpage either way. At least
> > with ganesha, you can export some filesystems via v3 and others via v4
> > only, and the MNT service there will only report the v3 ones. In that
> > case, you have a reachable service, but the v4-only filesystems will
> > be missing from showmount's output.
> 
> That doesn't sound like a great idea to me, but maybe you have no choice
if for
> some reason you want to allow simultaneous support for v3-only clients and
for
> filesystems that require long filehandles?  Ugh.
> 
> Anyway, this kind of warning doesn't have to catch every odd case.

Good conversation.

Another thing worth noting in the warning also is that some servers (Ganesha
for sure) will not list exports to showmount that the client issuing the
showmount doesn't have access to (and for NFSv4 they won't show up in the
directory listing).

Obviously the warning can't be perfect, but at least highlighting that the
issue of what exports are visible is complicated.

Frank


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] manpage: explain why showmount doesn't really work against a v4-only server
  2019-05-11 13:54 ` J. Bruce Fields
  2019-05-13  8:12   ` Jan Fajerski
  2019-05-13 13:29   ` Jeff Layton
@ 2019-05-29 13:15   ` Steve Dickson
  2019-05-29 13:24     ` J. Bruce Fields
  2 siblings, 1 reply; 9+ messages in thread
From: Steve Dickson @ 2019-05-29 13:15 UTC (permalink / raw)
  To: J. Bruce Fields, Jeff Layton; +Cc: linux-nfs, jfajerski

Bruce,

On 5/11/19 9:54 AM, J. Bruce Fields wrote:
> On Fri, May 10, 2019 at 05:54:45PM -0400, Jeff Layton wrote:
>> From: Jeff Layton <jlayton@redhat.com>
>>
>> I occasionally see people that expect valid info when running showmount
>> against a server that may export some or all filesystems via NFSv4.
>> Let's make it clear that it only works by talking to the remote MNT
>> service, and that that may not be available from a v4-only server.
> 
> Looks fine.
> 
> I wonder if it'd also be helpful for showmount to detect this case and
> say something.  E.g. the following (not even compileable, but you get
> the idea).
> 
> We've also talked about trying to cobble together an export list by
> scanning the root filesystem over NFSv4, but that's likely to be
> complicated and wouldn't give all the same results without further
> protocol extensions anyway, so I think that idea's dead.
> 
> --b.
I'm a bit confused... Does this patch go along with Jeff's manpage change?

steved.
> 
> diff --git a/utils/showmount/showmount.c b/utils/showmount/showmount.c
> index 394f5284a219..de9a6d38783a 100644
> --- a/utils/showmount/showmount.c
> +++ b/utils/showmount/showmount.c
> @@ -115,6 +115,22 @@ static CLIENT *nfs_get_mount_client(const char *hostname, rpcvers_t vers)
>  	exit(1);
>  }
>  
> +void warn_if_v4_only(char *hostname)
> +{
> +	struct sockaddr_in server_addr, client_addr;
> +
> +	if (fill_ipv4_sockaddr(hostname, &serveraddr))
> +		return;
> +	server_addr.sin_port = htnos(NFS_PORT);
> +	client_addr.sin_family = 0;
> +	client_addr.sin_addr.s_addr = 0;
> +	clnt_ping(&server_addr, NFS_PROGRAM, 4, "tcp", &client_addr);
> +
> +	if (rpc.createerr == RPC_SUCCESS)
> +		printf("Server responding to NFSv4 but not MNT; try mounting "
> +			"%s:/ instead of showmount", hostname);
> +}
> +
>  int main(int argc, char **argv)
>  {
>  	char hostname_buf[MAXHOSTLEN];
> @@ -199,6 +215,7 @@ int main(int argc, char **argv)
>  		fprintf(stderr, "%s: unable to create RPC auth handle.\n",
>  				program_name);
>  		clnt_destroy(mclient);
> +		warn_if_v4_only(hostname);
>  		exit(1);
>  	}
>  	total_timeout.tv_sec = TOTAL_TIMEOUT;
> 

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] manpage: explain why showmount doesn't really work against a v4-only server
  2019-05-29 13:15   ` Steve Dickson
@ 2019-05-29 13:24     ` J. Bruce Fields
  0 siblings, 0 replies; 9+ messages in thread
From: J. Bruce Fields @ 2019-05-29 13:24 UTC (permalink / raw)
  To: Steve Dickson; +Cc: Jeff Layton, linux-nfs, jfajerski

On Wed, May 29, 2019 at 09:15:35AM -0400, Steve Dickson wrote:
> Bruce,
> 
> On 5/11/19 9:54 AM, J. Bruce Fields wrote:
> > On Fri, May 10, 2019 at 05:54:45PM -0400, Jeff Layton wrote:
> >> From: Jeff Layton <jlayton@redhat.com>
> >>
> >> I occasionally see people that expect valid info when running showmount
> >> against a server that may export some or all filesystems via NFSv4.
> >> Let's make it clear that it only works by talking to the remote MNT
> >> service, and that that may not be available from a v4-only server.
> > 
> > Looks fine.
> > 
> > I wonder if it'd also be helpful for showmount to detect this case and
> > say something.  E.g. the following (not even compileable, but you get
> > the idea).
> > 
> > We've also talked about trying to cobble together an export list by
> > scanning the root filesystem over NFSv4, but that's likely to be
> > complicated and wouldn't give all the same results without further
> > protocol extensions anyway, so I think that idea's dead.
> > 
> > --b.
> I'm a bit confused... Does this patch go along with Jeff's manpage change?

It's separate.  And doesn't even compile.  You can ignore it for now.

--b.

> 
> steved.
> > 
> > diff --git a/utils/showmount/showmount.c b/utils/showmount/showmount.c
> > index 394f5284a219..de9a6d38783a 100644
> > --- a/utils/showmount/showmount.c
> > +++ b/utils/showmount/showmount.c
> > @@ -115,6 +115,22 @@ static CLIENT *nfs_get_mount_client(const char *hostname, rpcvers_t vers)
> >  	exit(1);
> >  }
> >  
> > +void warn_if_v4_only(char *hostname)
> > +{
> > +	struct sockaddr_in server_addr, client_addr;
> > +
> > +	if (fill_ipv4_sockaddr(hostname, &serveraddr))
> > +		return;
> > +	server_addr.sin_port = htnos(NFS_PORT);
> > +	client_addr.sin_family = 0;
> > +	client_addr.sin_addr.s_addr = 0;
> > +	clnt_ping(&server_addr, NFS_PROGRAM, 4, "tcp", &client_addr);
> > +
> > +	if (rpc.createerr == RPC_SUCCESS)
> > +		printf("Server responding to NFSv4 but not MNT; try mounting "
> > +			"%s:/ instead of showmount", hostname);
> > +}
> > +
> >  int main(int argc, char **argv)
> >  {
> >  	char hostname_buf[MAXHOSTLEN];
> > @@ -199,6 +215,7 @@ int main(int argc, char **argv)
> >  		fprintf(stderr, "%s: unable to create RPC auth handle.\n",
> >  				program_name);
> >  		clnt_destroy(mclient);
> > +		warn_if_v4_only(hostname);
> >  		exit(1);
> >  	}
> >  	total_timeout.tv_sec = TOTAL_TIMEOUT;
> > 

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] manpage: explain why showmount doesn't really work against a v4-only server
  2019-05-10 21:54 [PATCH] manpage: explain why showmount doesn't really work against a v4-only server Jeff Layton
  2019-05-11 13:54 ` J. Bruce Fields
@ 2019-06-03 14:27 ` Steve Dickson
  1 sibling, 0 replies; 9+ messages in thread
From: Steve Dickson @ 2019-06-03 14:27 UTC (permalink / raw)
  To: Jeff Layton; +Cc: linux-nfs, jfajerski



On 5/10/19 5:54 PM, Jeff Layton wrote:
> From: Jeff Layton <jlayton@redhat.com>
> 
> I occasionally see people that expect valid info when running showmount
> against a server that may export some or all filesystems via NFSv4.
> Let's make it clear that it only works by talking to the remote MNT
> service, and that that may not be available from a v4-only server.
> 
> Cc: Jan Fajerski <jfajerski@suse.com>
> Signed-off-by: Jeff Layton <jlayton@redhat.com>
Committed... 

steved.

> ---
>  utils/showmount/showmount.man | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/utils/showmount/showmount.man b/utils/showmount/showmount.man
> index a2f510fb5617..35818e1b61c5 100644
> --- a/utils/showmount/showmount.man
> +++ b/utils/showmount/showmount.man
> @@ -56,5 +56,10 @@ Because
>  .B showmount
>  sorts and uniqs the output, it is impossible to determine from
>  the output whether a client is mounting the same directory more than once.
> +.P
> +.B showmount
> +works by contacting the server's MNT service directly. NFSv4-only servers have
> +no need to advertise their exported root filehandles via this method, and may
> +not expose their MNT service to clients.
>  .SH AUTHOR
>  Rick Sladkey <jrs@world.std.com>
> -- 2.21.0
> 

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2019-06-03 14:27 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-10 21:54 [PATCH] manpage: explain why showmount doesn't really work against a v4-only server Jeff Layton
2019-05-11 13:54 ` J. Bruce Fields
2019-05-13  8:12   ` Jan Fajerski
2019-05-13 13:29   ` Jeff Layton
2019-05-13 13:44     ` J. Bruce Fields
2019-05-13 14:19       ` Frank Filz
2019-05-29 13:15   ` Steve Dickson
2019-05-29 13:24     ` J. Bruce Fields
2019-06-03 14:27 ` Steve Dickson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).