diff mbox series

manpage: explain why showmount doesn't really work against a v4-only server

Message ID 20190510215445.1823-1-jlayton@kernel.org (mailing list archive)
State New, archived
Headers show
Series manpage: explain why showmount doesn't really work against a v4-only server | expand

Commit Message

Jeff Layton May 10, 2019, 9:54 p.m. UTC 
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(+)

Comments

J. Bruce Fields May 11, 2019, 1:54 p.m. UTC | #1 
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;
Jan Fajerski May 13, 2019, 8:12 a.m. UTC | #2 
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;
>
Jeff Layton May 13, 2019, 1:29 p.m. UTC | #3 
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.
J. Bruce Fields May 13, 2019, 1:44 p.m. UTC | #4 
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.
Frank Filz May 13, 2019, 2:19 p.m. UTC | #5 
> 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
Steve Dickson May 29, 2019, 1:15 p.m. UTC | #6 
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;
>
J. Bruce Fields May 29, 2019, 1:24 p.m. UTC | #7 
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;
> >
Steve Dickson June 3, 2019, 2:27 p.m. UTC | #8 
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
>
diff mbox series

Patch

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>