[PATCH] mount.nfs: restore admin-specified clientaddr option

[PATCH] mount.nfs: restore admin-specified clientaddr option

[Chuck Lever]

Revert an earlier change to make specifying the clientaddr= option illegal.

Jeff Layton pointed out that admins may want to specify the clientaddr=
option to advertise a different callback address when accessing an NFSv4
server through a NAT router.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
---

 utils/mount/stropts.c |   11 ++++-------
 1 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/utils/mount/stropts.c b/utils/mount/stropts.c
index 12f6423..236a3b4 100644
--- a/utils/mount/stropts.c
+++ b/utils/mount/stropts.c
@@ -201,7 +201,9 @@ static int append_addr_opt(struct sockaddr_in *saddr, char **extra_opts)
 }
 
 /*
- * Append the 'clientaddr=' option to the options string.
+ * Called if no 'clientaddr=' option was specified in the options string
+ * to discover our address and append an appropriate 'clientaddr=' option
+ * to the options string.
  *
  * Returns 1 if 'clientaddr=' option created successfully;
  * otherwise zero.
@@ -319,15 +321,10 @@ int nfs4mount_s(const char *spec, const char *node, int flags,
 		return EX_FAIL;
 	}
 
-	if (ca_opt) {
-		nfs_error(_("%s: Illegal option: 'clientaddr='"), progname);
-		return EX_FAIL;
-	}
-
 	if (!append_addr_opt(&saddr, extra_opts))
 		return EX_FAIL;
 
-	if (!append_clientaddr_opt(&saddr, extra_opts))
+	if (!ca_opt && !append_clientaddr_opt(&saddr, extra_opts))
 		return EX_FAIL;
 
 	if (verbose)


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [PATCH] mount.nfs: restore admin-specified clientaddr option

[Trond Myklebust]

clientaddr= MUST be allowed, damnit! Who the hell tried to disable it?

'clientaddr' was set up because there is no way for the kernel (or an
automated userland mount program) to determine exactly which IP address
the server should be using for callbacks in the case where there are
more than 1 options.
That all depends on the local network topology, and routing policies,
which may not be visible to the client.

Trond

On Thu, 2007-08-30 at 13:46 -0400, Chuck Lever wrote:
> Revert an earlier change to make specifying the clientaddr= option illegal.
> 
> Jeff Layton pointed out that admins may want to specify the clientaddr=
> option to advertise a different callback address when accessing an NFSv4
> server through a NAT router.
> 
> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
> ---
> 
>  utils/mount/stropts.c |   11 ++++-------
>  1 files changed, 4 insertions(+), 7 deletions(-)
> 
> diff --git a/utils/mount/stropts.c b/utils/mount/stropts.c
> index 12f6423..236a3b4 100644
> --- a/utils/mount/stropts.c
> +++ b/utils/mount/stropts.c
> @@ -201,7 +201,9 @@ static int append_addr_opt(struct sockaddr_in *saddr, char **extra_opts)
>  }
>  
>  /*
> - * Append the 'clientaddr=' option to the options string.
> + * Called if no 'clientaddr=' option was specified in the options string
> + * to discover our address and append an appropriate 'clientaddr=' option
> + * to the options string.
>   *
>   * Returns 1 if 'clientaddr=' option created successfully;
>   * otherwise zero.
> @@ -319,15 +321,10 @@ int nfs4mount_s(const char *spec, const char *node, int flags,
>  		return EX_FAIL;
>  	}
>  
> -	if (ca_opt) {
> -		nfs_error(_("%s: Illegal option: 'clientaddr='"), progname);
> -		return EX_FAIL;
> -	}
> -
>  	if (!append_addr_opt(&saddr, extra_opts))
>  		return EX_FAIL;
>  
> -	if (!append_clientaddr_opt(&saddr, extra_opts))
> +	if (!ca_opt && !append_clientaddr_opt(&saddr, extra_opts))
>  		return EX_FAIL;
>  
>  	if (verbose)
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> NFS maillist  -  NFS@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [PATCH] mount.nfs: restore admin-specified clientaddr option

[Chuck Lever]

[-- Attachment #1: Type: text/plain, Size: 1564 bytes --]

Trond Myklebust wrote:
> 'clientaddr' was set up because there is no way for the kernel (or an
> automated userland mount program) to determine exactly which IP address
> the server should be using for callbacks in the case where there are
> more than 1 options.
> That all depends on the local network topology, and routing policies,
> which may not be visible to the client.

The patch corrects a mistaken assumption I made while working on the 
text-based mount implementation.  The broken behavior is only a week or 
so old, doesn't affect legacy nfs4_mount_data style mounts, and was 
never part of an nfs-utils release.

It would be wonderful if we had some of these requirements written down 
somewhere, so we wouldn't be dependent on individuals who are 
unavailable at times when we need some historical perspective.  I've 
started doing this here:

http://wiki.linux-nfs.org/wiki/index.php/NewMountDesignSpec

You have to admit that existing mount option documentation is pretty 
scant on history and rationale.  Look at what nfs(5) says about 
clientaddr= :

> clientaddr=n   On a multi-homed client, this causes the client to use a
>                specific callback address when communicating with an NFS
>                version 4 server.  This option is currently ignored.

"This option is currently ignored."  Ummm....

And Neil just fixed the "multi-homed" part of mount's automated 
clientaddr generation.

And nfs(5) doesn't say Jack about NAT routers or network topology or 
routing policies.

I will send in a patch that also corrects nfs(5).

[-- Attachment #2: chuck.lever.vcf --]
[-- Type: text/x-vcard, Size: 290 bytes --]

begin:vcard
fn:Chuck Lever
n:Lever;Chuck
org:Oracle Corporation;Corporate Architecture: Linux Projects Group
adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA
title:Principal Member of Staff
tel;work:+1 248 614 5091
x-mozilla-html:FALSE
url:http://oss.oracle.com/~cel
version:2.1
end:vcard


[-- Attachment #3: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

[-- Attachment #4: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [PATCH] mount.nfs: restore admin-specified clientaddr option

[Trond Myklebust]

On Thu, 2007-08-30 at 15:23 -0400, Chuck Lever wrote:

> It would be wonderful if we had some of these requirements written down 
> somewhere, so we wouldn't be dependent on individuals who are 
> unavailable at times when we need some historical perspective.  I've 
> started doing this here:

Nobody ever asked me either before or after disabling this in the
mainline nfs-utils. It came as a complete surprise to me to learn now
that it had been done.

Yes, that irritates me.

Trond


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs