mount.nfs: Don't fail mounts when /etc/netconfig is nonexistent

PATCH In review Steve Dickson 4 participants 9 messages Jan 27, 2010 – Jan 28, 2010

Subsystems (2)

NFS client NFS server

lore

Share & tools

lore

Steve Dickson

author

2010-01-27 16:41 UTC #0 lore raw

PATCH 1/1 mount.nfs: Don't fail mounts when /etc/netconfig is nonexistent

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 <[email protected]>
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 <[email protected]>

support/nfs/getport.c +14 -1

index c930539..e490dd4 100644
@@ -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;
 }

utils/mount/network.c +34 -5

index 06cab6a..fa99bc1 100644
@@ -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 Lever

2010-01-27 18:10 UTC #1 lore raw

Quoted 17 lines · Steve Dickson

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<[email protected]>
Date:   Wed Jan 27 11:19:00 2010 -0500

Quoted 6 lines

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<[email protected]>

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?

Quoted 97 lines

support/nfs/getport.c +14 -1

index c930539..e490dd4 100644
@@ -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;
  }

utils/mount/network.c +34 -5

index 06cab6a..fa99bc1 100644
@@ -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

Signature · 1 line

chuck[dot]lever[at]oracle[dot]com

Steve Dickson

author

2010-01-27 18:42 UTC #2 lore raw

Quoted 8 lines · Chuck Lever

Quoted 8 lines
Author: Steve Dickson<[email protected]>
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.

Quoted 6 lines

Quoted 1 line
Signed-off-by Steve Dickson<[email protected]>
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.

Well in some environments "all bets are off" is just not good enough... Mount has always worked in these type of environments before and I think we should continue to...

Quoted 8 lines

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.

Sparse environments generally have a finite amount of space, that is simple unchangeable... so the above "luxuries" are simply not available...

Quoted 5 lines

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?

Lets keep this in perspective... the "well-known" values in this patch things like TCP and UDP... when protocol == IPPROTO_TCP the well known value is "tcp" (or "tcp6" depending on the family)... Values that have not changed for years and will not change for years...

On the umount side, the file should not be consulted in the first place since all the information needed in /etc/mtab... Of course things can change between mount and umounts but I truly do no think the meaning of "udp" will change from being IPPROTO_UDP....

Making mount more bullet proof and allowing it (continue to) work in all different types of environments is a good thing... imho...

steved.

Chuck Lever

2010-01-27 20:57 UTC #3 lore raw

Quoted 9 lines · Steve Dickson

Quoted 8 lines · Chuck Lever
Quoted 8 lines
Author: Steve Dickson<[email protected]>
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.

Quoted 7 lines

Quoted 6 lines
Quoted 1 line
Signed-off-by Steve Dickson<[email protected]>
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.
Well in some environments "all bets are off" is just not good enough...

Limited disk space does not mean that RPM is suddenly allowed to ignore dependencies. Clearly someone decided that it was OK to install only part of the TI-RPC run-time on this system, despite the dependency nfs-utils has on libtirpc.

Quoted 2 lines

Mount has always worked in these type of environments before and I think we should continue to...

No one is arguing that point.

Quoted 10 lines

Quoted 7 lines
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.
Sparse environments generally have a finite amount of space, that is simple unchangeable... so the above "luxuries" are simply not available...

I'm sorry you feel that /etc/netconfig is a luxury, but the fact is it's currently a mandatory part of the TI-RPC run-time. Why be surprised if TI-RPC based applications stop working when the run-time they depend on is incorrectly installed?

If /etc/rpc and /etc/protocols are installed on this system, then there's no reason to exclude /etc/netconfig. The file is all of 768 bytes (and can be made smaller immediately by leaving out the block comment at the top). If there really is no room for an additional file, then you need a different solution (see below).

Frankly, if disk space is so tight on this system, you should embrace using the non-TI-RPC mount.nfs, because it's disk footprint is significantly smaller than the current TI-RPC based mount.nfs, and you get exactly the functionality that you get with your patch applied.

Quoted 9 lines

Quoted 4 lines
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?
Lets keep this in perspective... the "well-known" values in this patch things like TCP and UDP... when protocol == IPPROTO_TCP the well known value is "tcp" (or "tcp6" depending on the family)... Values that have not changed for years and will not change for years...

Quoted 7 lines

On the umount side, the file should not be consulted in the first place since all the information needed in /etc/mtab... Of course things can change between mount and umounts but I truly do no think the meaning of "udp" will change from being IPPROTO_UDP....
Making mount more bullet proof and allowing it (continue to) work in all different types of environments is a good thing... imho...

You've fundamentally misunderstood my objection to your patch.

In nfs-utils, we've replaced the glibc RPC implementation with TI-RPC. Today, if you want the TI-RPC versions of these utilities to "just work" then the whole TI-RPC run-time must be installed on the target systems. Note well that the TI-RPC enabled statd will also fail to start if /etc/netconfig does not exist, and this will cause NFS mounts to fail as well. Likewise, a TI-RPC enabled mountd will fail to start in this situation.

Now, if you want to ensure that TI-RPC applications will continue to work in the absence of parts of the TI-RPC run-time, then you should address that in libtirpc, not in every application that uses it. /etc/netconfig is not a part of mount.nfs, it's a part of TI-RPC.

It also appears that your new logic might assume the values of "tcp" and "udp" when an admin purposely excludes them from /etc/netconfig. What if an admin wants to start only IPv6 listeners for statd, nfsd, and mountd? Somehow, mounting "tcp" and "udp" still work, even though we claim in the man page that these are netids, not protocol names. That would be a bug.

Signature · 2 lines

Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Peter Staubach

2010-01-27 22:30 UTC #4 lore raw

Quoted 88 lines · Chuck Lever

Quoted 9 lines · Steve Dickson
Quoted 8 lines · Chuck Lever
Quoted 8 lines
Author: Steve Dickson<[email protected]>
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.
Quoted 7 lines
Quoted 6 lines
Quoted 1 line
Signed-off-by Steve Dickson<[email protected]>
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.
Well in some environments "all bets are off" is just not good enough...
Limited disk space does not mean that RPM is suddenly allowed to ignore dependencies. Clearly someone decided that it was OK to install only part of the TI-RPC run-time on this system, despite the dependency nfs-utils has on libtirpc.
Quoted 2 lines
Mount has always worked in these type of environments before and I think we should continue to...
No one is arguing that point.
Quoted 10 lines
Quoted 7 lines
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.
Sparse environments generally have a finite amount of space, that is simple unchangeable... so the above "luxuries" are simply not available...
I'm sorry you feel that /etc/netconfig is a luxury, but the fact is it's currently a mandatory part of the TI-RPC run-time. Why be surprised if TI-RPC based applications stop working when the run-time they depend on is incorrectly installed?
If /etc/rpc and /etc/protocols are installed on this system, then there's no reason to exclude /etc/netconfig. The file is all of 768 bytes (and can be made smaller immediately by leaving out the block comment at the top). If there really is no room for an additional file, then you need a different solution (see below).
Frankly, if disk space is so tight on this system, you should embrace using the non-TI-RPC mount.nfs, because it's disk footprint is significantly smaller than the current TI-RPC based mount.nfs, and you get exactly the functionality that you get with your patch applied.
Quoted 10 lines
Quoted 4 lines
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?
Lets keep this in perspective... the "well-known" values in this patch things like TCP and UDP... when protocol == IPPROTO_TCP the well known value
is "tcp" (or "tcp6" depending on the family)... Values that have not changed for years and will not change for years...
Quoted 7 lines
On the umount side, the file should not be consulted in the first place since all the information needed in /etc/mtab... Of course things can change between mount and umounts but I truly do no think the meaning of "udp" will change from being IPPROTO_UDP....
Making mount more bullet proof and allowing it (continue to) work in all different types of environments is a good thing... imho...
You've fundamentally misunderstood my objection to your patch.
In nfs-utils, we've replaced the glibc RPC implementation with TI-RPC. Today, if you want the TI-RPC versions of these utilities to "just work" then the whole TI-RPC run-time must be installed on the target systems. Note well that the TI-RPC enabled statd will also fail to start if /etc/netconfig does not exist, and this will cause NFS mounts to fail as well. Likewise, a TI-RPC enabled mountd will fail to start in this situation.
Now, if you want to ensure that TI-RPC applications will continue to work in the absence of parts of the TI-RPC run-time, then you should address that in libtirpc, not in every application that uses it. /etc/netconfig is not a part of mount.nfs, it's a part of TI-RPC.

Quoted 7 lines

It also appears that your new logic might assume the values of "tcp" and "udp" when an admin purposely excludes them from /etc/netconfig. What if an admin wants to start only IPv6 listeners for statd, nfsd, and mountd? Somehow, mounting "tcp" and "udp" still work, even though we claim in the man page that these are netids, not protocol names. That would be a bug.

Chuck, it feels as if you are under the impression that this is a general purpose deployment that Steve is attempting to make to work. It is not. It is a very restricted use, ie. to install a system. Thus, the resources available are very restricted. The restriction is not diskspace, per se, but the memory footprint which would be required to hold it.

The suggestion to use the non-TI-RPC version is interesting, but has some very negative ramifications. It would mean that we would have to test the TI-RPC flavor and the non-TI-RPC flavor. It would also limit future development to that which could be supported via the non-TI-RPC version. This seems unnecessarily limiting.

While I don't agree with what the anaconda folks have done, picking and choosing as they have, they have done so. I think that we should work with them to figure out why they have chosen to do so and whether it is valid or not.

All that said, what is the technical problem with including this support? There is no possibility that "tcp" or "udp" will ever change meaning, at least not in our lifetimes.

The bottom line is that I could agree, that this isn't the most aesthetically pleasing architecture and implementation. However, sometimes, the code must run in a non-perfect world and hence, compromises must be made.

	Thanx...

		ps

J. Bruce Fields

2010-01-28 03:19 UTC #5 lore raw

Quoted 6 lines · Peter Staubach

Chuck, it feels as if you are under the impression that this is a general purpose deployment that Steve is attempting to make to work. It is not. It is a very restricted use, ie. to install a system. Thus, the resources available are very restricted. The restriction is not diskspace, per se, but the memory footprint which would be required to hold it.

The memory footprint for /etc/netconfig? What are the numbers here? Is this a real problem? And couldn't you get most of the savings as Chuck suggests just by removing the comments from /etc/netconfig?

Quoted 11 lines

The suggestion to use the non-TI-RPC version is interesting, but has some very negative ramifications. It would mean that we would have to test the TI-RPC flavor and the non-TI-RPC flavor. It would also limit future development to that which could be supported via the non-TI-RPC version. This seems unnecessarily limiting.
While I don't agree with what the anaconda folks have done, picking and choosing as they have, they have done so. I think that we should work with them to figure out why they have chosen to do so and whether it is valid or not.

OK.

Quoted 8 lines

All that said, what is the technical problem with including this support? There is no possibility that "tcp" or "udp" will ever change meaning, at least not in our lifetimes.
The bottom line is that I could agree, that this isn't the most aesthetically pleasing architecture and implementation. However, sometimes, the code must run in a non-perfect world and hence, compromises must be made.

If we have to have this hack, I also wonder (with Chuck) why the same hack couldn't be done in libtirpc itself.

--b.

Steve Dickson

author

2010-01-28 15:39 UTC #8 lore raw

In reply to Chuck Lever

Quoted 16 lines · Chuck Lever

Quoted 15 lines · Steve Dickson
Quoted 14 lines · Chuck Lever
Quoted 9 lines
Author: Steve Dickson<[email protected]>
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<[email protected]>
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.

Quoted 6 lines

Quoted 1 line
Well in some environments "all bets are off" is just not good enough...
Limited disk space does not mean that RPM is suddenly allowed to ignore dependencies. Clearly someone decided that it was OK to install only part of the TI-RPC run-time on this system, despite the dependency nfs-utils has on libtirpc.

This has been a practice (cherry picking pieces from RPMS) for a very long time (so I'm told)....

Quoted 22 lines

Quoted 3 lines
Mount has always worked in these type of environments before and I think we should continue to...
No one is arguing that point.
Quoted 10 lines
Quoted 7 lines
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.
Sparse environments generally have a finite amount of space, that is simple unchangeable... so the above "luxuries" are simply not available...
I'm sorry you feel that /etc/netconfig is a luxury, but the fact is it's currently a mandatory part of the TI-RPC run-time. Why be surprised if TI-RPC based applications stop working when the run-time they depend on is incorrectly installed?

Quoted 5 lines

If /etc/rpc and /etc/protocols are installed on this system, then there's no reason to exclude /etc/netconfig. The file is all of 768 bytes (and can be made smaller immediately by leaving out the block comment at the top). If there really is no room for an additional file, then you need a different solution (see below).

/etc/protocols is but /etc/rpc is not.

Quoted 5 lines

Frankly, if disk space is so tight on this system, you should embrace using the non-TI-RPC mount.nfs, because it's disk footprint is significantly smaller than the current TI-RPC based mount.nfs, and you get exactly the functionality that you get with your patch applied.

I don't think supporting two different packages is the answer...

Quoted 21 lines

Quoted 11 lines
Quoted 5 lines
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?
Lets keep this in perspective... the "well-known" values in this patch things like TCP and UDP... when protocol == IPPROTO_TCP the well known value
is "tcp" (or "tcp6" depending on the family)... Values that have not changed for years and will not change for years...
Quoted 7 lines
On the umount side, the file should not be consulted in the first place since all the information needed in /etc/mtab... Of course things can change between mount and umounts but I truly do no think the meaning of "udp" will change from being IPPROTO_UDP....
Making mount more bullet proof and allowing it (continue to) work in all different types of environments is a good thing... imho...
You've fundamentally misunderstood my objection to your patch.

Quoted 7 lines

In nfs-utils, we've replaced the glibc RPC implementation with TI-RPC. Today, if you want the TI-RPC versions of these utilities to "just work" then the whole TI-RPC run-time must be installed on the target systems. Note well that the TI-RPC enabled statd will also fail to start if /etc/netconfig does not exist, and this will cause NFS mounts to fail as well. Likewise, a TI-RPC enabled mountd will fail to start in this situation.

The -o nolock option used so statd or rpcbind, for that matter, is not needed...

Quoted 5 lines

Now, if you want to ensure that TI-RPC applications will continue to work in the absence of parts of the TI-RPC run-time, then you should address that in libtirpc, not in every application that uses it. /etc/netconfig is not a part of mount.nfs, it's a part of TI-RPC.

Technically I see no difference whether its done in the mount command or library... theoretically I think it makes more sense to leave it up to the applications to decide if they want to fail if /etc/netconfig does not exist... Why should a library make that type of assumption on behalf of an application?

Quoted 7 lines

It also appears that your new logic might assume the values of "tcp" and "udp" when an admin purposely excludes them from /etc/netconfig. What if an admin wants to start only IPv6 listeners for statd, nfsd, and mountd? Somehow, mounting "tcp" and "udp" still work, even though we claim in the man page that these are netids, not protocol names. That would be a bug.

If values are read out /etc/netconfig, this code will not be deployed... that's now people can setup IPv6 only listeners...

steved.

Chuck Lever

2010-01-28 16:05 UTC #6 lore raw

In reply to Peter Staubach

Hi Peter-

Quoted 96 lines · Peter Staubach

Quoted 88 lines · Chuck Lever
Quoted 9 lines · Steve Dickson
Quoted 8 lines · Chuck Lever
Quoted 8 lines
Author: Steve Dickson<[email protected]>
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.
Quoted 7 lines
Quoted 6 lines
Quoted 1 line
Signed-off-by Steve Dickson<[email protected]>
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.
Well in some environments "all bets are off" is just not good enough...
Limited disk space does not mean that RPM is suddenly allowed to ignore dependencies. Clearly someone decided that it was OK to install only part of the TI-RPC run-time on this system, despite the dependency nfs-utils has on libtirpc.
Quoted 2 lines
Mount has always worked in these type of environments before and I think we should continue to...
No one is arguing that point.
Quoted 10 lines
Quoted 7 lines
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.
Sparse environments generally have a finite amount of space, that is simple unchangeable... so the above "luxuries" are simply not available...
I'm sorry you feel that /etc/netconfig is a luxury, but the fact is it's currently a mandatory part of the TI-RPC run-time. Why be surprised if TI-RPC based applications stop working when the run-time they depend on is incorrectly installed?
If /etc/rpc and /etc/protocols are installed on this system, then there's no reason to exclude /etc/netconfig. The file is all of 768 bytes (and can be made smaller immediately by leaving out the block comment at the top). If there really is no room for an additional file, then you need a different solution (see below).
Frankly, if disk space is so tight on this system, you should embrace using the non-TI-RPC mount.nfs, because it's disk footprint is significantly smaller than the current TI-RPC based mount.nfs, and you get exactly the functionality that you get with your patch applied.
Quoted 10 lines
Quoted 4 lines
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?
Lets keep this in perspective... the "well-known" values in this patch things like TCP and UDP... when protocol == IPPROTO_TCP the well known value
is "tcp" (or "tcp6" depending on the family)... Values that have not changed for years and will not change for years...
Quoted 7 lines
On the umount side, the file should not be consulted in the first place since all the information needed in /etc/mtab... Of course things can change between mount and umounts but I truly do no think the meaning of "udp" will change from being IPPROTO_UDP....
Making mount more bullet proof and allowing it (continue to) work in all different types of environments is a good thing... imho...
You've fundamentally misunderstood my objection to your patch.
In nfs-utils, we've replaced the glibc RPC implementation with TI-RPC. Today, if you want the TI-RPC versions of these utilities to "just work" then the whole TI-RPC run-time must be installed on the target systems. Note well that the TI-RPC enabled statd will also fail to start if /etc/netconfig does not exist, and this will cause NFS mounts to fail as well. Likewise, a TI-RPC enabled mountd will fail to start in this situation.
Now, if you want to ensure that TI-RPC applications will continue to work in the absence of parts of the TI-RPC run-time, then you should address that in libtirpc, not in every application that uses it. /etc/netconfig is not a part of mount.nfs, it's a part of TI-RPC.
Quoted 6 lines
It also appears that your new logic might assume the values of "tcp" and "udp" when an admin purposely excludes them from /etc/netconfig. What if an admin wants to start only IPv6 listeners for statd, nfsd, and mountd? Somehow, mounting "tcp" and "udp" still work, even though we claim in the man page that these are netids, not protocol names. That would be a bug.

Quoted 4 lines

Chuck, it feels as if you are under the impression that this is a general purpose deployment that Steve is attempting to make to work. It is not. It is a very restricted use, ie. to install a system.

This request was made to the upstream maintainer and he has passed it to the community, thus someone thought it might have generic interest (or, perhaps they just wanted someone else to maintain this hack).

If we are to maintain this new behavior, we (not being the original authors) should attempt to understand what is required, and try to fit this into our plans and the provided code and APIs. Unfortunately there were very few details offered in the patch description, so we are left to assume.

Quoted 11 lines

Thus, the resources available are very restricted. The restriction is not diskspace, per se, but the memory footprint which would be required to hold it.
The suggestion to use the non-TI-RPC version is interesting, but has some very negative ramifications. It would mean that we would have to test the TI-RPC flavor and the non-TI-RPC flavor. It would also limit future development to that which could be supported via the non-TI-RPC version. This seems unnecessarily limiting.

Quoted 8 lines

While I don't agree with what the anaconda folks have done, picking and choosing as they have, they have done so. I think that we should work with them to figure out why they have chosen to do so and whether it is valid or not.
All that said, what is the technical problem with including this support? There is no possibility that "tcp" or "udp" will ever change meaning, at least not in our lifetimes.

If this is for Anaconda, I assume that eventually they will want to support NFS/IPv6, so we are going to have to make user space TI-RPC work in a restricted environment.

The technical issues are:

1. /etc/netconfig is a mandatory part of TI-RPC (as it is currently implemented), so not having it means that the library _will_ be broken in all kinds of ways. That must be addressed if we want our TI-RPC-based tools to operate without /etc/netconfig.

2. All TI-RPC applications that run in a restricted environment will have the same problem. Thus the problem should be addressed in TI-RPC, not in any particular application that uses it. That would affect rpcbind, statd, ypbind, showmount, and maybe others.

3. The absence of a particular netid has specific semantics. You can't just assume "tcp" if there's no "tcp" netid in the /etc/netconfig file. It doesn't matter how traditional the string "tcp" is -- that's simply not the way this API works.

4. We've changed mount.nfs to make "proto=" take a netid, not a protocol name without deference to an address family. We are now being asked to go back to the original behavior, which was that "tcp" means either tcp over IPv4 or over IPv6.

Quoted 4 lines

The bottom line is that I could agree, that this isn't the most aesthetically pleasing architecture and implementation. However, sometimes, the code must run in a non-perfect world and hence, compromises must be made.

I should have said "I totally disagree with this _approach_." I don't have a problem with supporting a restricted environment. But we do need to understand what is required first. In general, there's no possible way we can take a significant feature change and support it if we don't understand how it's supposed to work.

My current proposal to address this problem is to emulate the contents of /etc/netconfig inside libtirpc (specifically in the set/endnetconfigent code) if the /etc/netconfig file does not exist. The emulated contents of the file would essentially match the semantics of what we have soldered into the kernel.

Signature · 2 lines

Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Chuck Lever

2010-01-28 16:38 UTC #7 lore raw

In reply to Peter Staubach

Quoted 4 lines · Peter Staubach

While I don't agree with what the anaconda folks have done, picking and choosing as they have, they have done so. I think that we should work with them to figure out why they have chosen to do so and whether it is valid or not.

If it wasn't clear from my previous e-mail, I think this is a very good idea.

Signature · 2 lines

Chuck Lever
chuck[dot]lever[at]oracle[dot]com