On 01/27/2010 03:57 PM, Chuck Lever wrote: > On Jan 27, 2010, at 1:42 PM, Steve Dickson wrote: >> On 01/27/2010 01:09 PM, Chuck Lever wrote: >>>> Author: Steve Dickson<steved@xxxxxxxxxx> >>>> 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@xxxxxxxxxx> >>> >>> 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. This has been a practice (cherry picking pieces from RPMS) for a very long time (so I'm told).... > >> Mount has always worked in these type of environments before and >> I think we should continue to... > > No one is arguing that point. > >>> 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). /etc/protocols is but /etc/rpc is not. > > 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... > >>> 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... > > 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. The -o nolock option used so statd or rpcbind, for that matter, is not needed... > > 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? > > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
