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 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.