From: Chuck Lever <chuck.lever@oracle.com>
To: Steve Dickson <SteveD@redhat.com>
Cc: Linux NFS Mailing list <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH] mount.nfs: Don't fail mounts when /etc/netconfig is nonexistent
Date: Wed, 27 Jan 2010 13:09:50 -0500 [thread overview]
Message-ID: <4B60816E.5070108@oracle.com> (raw)
In-Reply-To: <4B606CA5.2090607@RedHat.com>
On 01/27/2010 11:41 AM, Steve Dickson wrote:
> During some recent testing, mounts were mysteriously failing to some
> servers but not to others. The mounts that were failure were in a very sparse
> environment. Meaning very little in any supporting utilities, like
> /bin/cat, /bin/ls or system-wide configuration files.
>
> The reason the mounts were failing was /etc/netconfig did not exist.
> Even in the cases when all the information that would have been pulled
> from /etc/netconfig already existed or was easily attainable
>
> So the patch tries to recover from when system files are inaccessible
> and the need information already exists or is well known.
>
> steved.
>
> Author: Steve Dickson<steved@redhat.com>
> Date: Wed Jan 27 11:19:00 2010 -0500
>
> In a very sparse environments certain system files (like
> /etc/netconfig) may not exist. In these environments don't
> fail mount if all the need information (like network protocols)
> exist and are well known.
>
> Signed-off-by: Steve Dickson<steved@redhat.com>
I totally disagree with this. If HAVE_LIBTIRPC is set, then the runtime
TI-RPC package should be installed, in its entirety, on the run-time
systems. If autoconf and RPM can't trust the given dependency
information, then all bets are off.
The right fix is to either:
a) install a non-TI-RPC version of mount.nfs, or
b) make sure /etc/netconfig is available when RPM, pkgconfig, and
autoconf say it should be.
Mount.nfs is not the only program that needs to have this information.
I assume since you are not patching other parts of mount.nfs that look
for /etc/rpc and /etc/protocols that these files _do_ exist? Or does
glibc also do this hack of filling in well-known values?
> diff --git a/support/nfs/getport.c b/support/nfs/getport.c
> index c930539..e490dd4 100644
> --- a/support/nfs/getport.c
> +++ b/support/nfs/getport.c
> @@ -277,7 +277,7 @@ nfs_get_proto(const char *netid, sa_family_t *family, unsigned long *protocol)
> #ifdef HAVE_LIBTIRPC
> char *nfs_get_netid(const sa_family_t family, const unsigned long protocol)
> {
> - char *nc_protofmly, *nc_proto, *nc_netid;
> + char *nc_protofmly, *nc_proto, *nc_netid = NULL;
> struct netconfig *nconf;
> struct protoent *proto;
> void *handle;
> @@ -319,6 +319,19 @@ char *nfs_get_netid(const sa_family_t family, const unsigned long protocol)
> endnetconfig(handle);
>
> out:
> + /*
> + * The system configuration files are inaccessible
> + * so see if these are well known protocols
> + */
> + if (protocol == IPPROTO_TCP)
> + nc_netid = (family == AF_INET6 ?
> + strdup("tcp6") : strdup("tcp"));
> + else if (protocol == IPPROTO_UDP)
> + nc_netid = (family == AF_INET6 ?
> + strdup("udp6") : strdup("udp"));
> + if (nc_netid != NULL)
> + return nc_netid;
> +
> rpc_createerr.cf_stat = RPC_UNKNOWNPROTO;
> return NULL;
> }
> diff --git a/utils/mount/network.c b/utils/mount/network.c
> index 06cab6a..fa99bc1 100644
> --- a/utils/mount/network.c
> +++ b/utils/mount/network.c
> @@ -1270,7 +1270,26 @@ nfs_nfs_version(struct mount_options *options, unsigned long *version)
> *version = 0;
> return 1;
> }
> -
> +/*
> + * Returns TRUE if the option string is a well known protocol
> + */
> +int
> +nfs_set_proto(char *option, unsigned long *protocol)
> +{
> + if (strcmp(option, "tcp") == 0 ||
> + strcmp(option, "tcp6") == 0) {
> + *protocol = IPPROTO_TCP;
> + return 1;
> + }
> + if (strcmp(option, "udp") == 0 ||
> + strcmp(option, "udp6") == 0) {
> + *protocol = IPPROTO_UDP;
> + return 1;
> + }
> + if (verbose)
> + nfs_error(_("%s: unkown protocol: '%s'"), progname, option);
> + return 0;
> +}
> /*
> * Returns TRUE if @protocol contains a valid value for this option,
> * or FALSE if the option was specified with an invalid value.
> @@ -1290,8 +1309,13 @@ nfs_nfs_protocol(struct mount_options *options, unsigned long *protocol)
> return 1;
> case 2: /* proto */
> option = po_get(options, "proto");
> - if (option != NULL)
> - return nfs_get_proto(option,&family, protocol);
> + if (option != NULL) {
> + if (nfs_get_proto(option,&family, protocol))
> + return 1;
> + if (nfs_set_proto(option, protocol))
> + return 1;
> + return 0;
> + }
> }
>
> /*
> @@ -1438,8 +1462,13 @@ nfs_mount_protocol(struct mount_options *options, unsigned long *protocol)
> char *option;
>
> option = po_get(options, "mountproto");
> - if (option != NULL)
> - return nfs_get_proto(option,&family, protocol);
> + if (option != NULL) {
> + if (nfs_get_proto(option,&family, protocol))
> + return 1;
> + if (nfs_set_proto(option, protocol))
> + return 1;
> + return 0;
> + }
>
> /*
> * MNT transport protocol wasn't specified. If the NFS
--
chuck[dot]lever[at]oracle[dot]com
next prev parent reply other threads:[~2010-01-27 18:10 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-27 16:41 [PATCH] mount.nfs: Don't fail mounts when /etc/netconfig is nonexistent Steve Dickson
2010-01-27 18:09 ` Chuck Lever [this message]
2010-01-27 18:42 ` Steve Dickson
2010-01-27 20:57 ` Chuck Lever
2010-01-27 22:30 ` Peter Staubach
2010-01-28 3:20 ` J. Bruce Fields
2010-01-28 16:05 ` Chuck Lever
2010-01-28 16:36 ` Chuck Lever
2010-01-28 15:39 ` Steve Dickson
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=4B60816E.5070108@oracle.com \
--to=chuck.lever@oracle.com \
--cc=SteveD@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox