On 07.06.2012 07:11, Ian Kent wrote: > On Wed, 2012-06-06 at 11:44 +0400, Michael Tokarev wrote: [] > It's not quite that simple for the case below. > > Exactly what your asking and what your trying to solve is not clear. Please take a look at the $SUBJECT. > Above you quote what looks like a simple indirect map mount request but > below you're talking about the internal hosts map (I think) which is a > completely different story. I was talking about indirect NFS map, which, even when specifying -fstype=nfs4, still tries to contact the portmapper to determine port number (unless port= option is given), and I demonstrated how it does that and where it sleeps. Using connected UDP sockets will eliminate this delay if the portmapper UDP port is not firewalled. As Chuk Lever pointed out, this will prevent old/misconfigured/broken portmappers, who send UDP replies from a wrong IP address in case of multihoming setup, from working. So I think it is not the right way to go. [] > I think the trivial fix for simple mounts like the one above is to > specify the fstype=nfs4 option and set MOUNT_WAIT, in the autofs > configuration, to some sensible value for the site in question. No. fstype=nfs4 is already set, the fix to stop automount from trying to contact portmapper is to specify port= mount option. Note that MOUNT_WAIT description is wrong in samples/autofs.conf.default: the description talks about umount, while apparently it applies to mount. > The fstype option will tell autofs you want only nfs4 mounts and pass > "-t nfs4" to mount(8) so that it doesn't attempt to fall back to v3 etc. Right now mount does not do any fallbacks. It is autofs (automount) which tries to contact remote portmapper, and this is what I demonstated in the debug trace I provided. This can be fixed by specifying the port= explicitly. Mount does its job instantly. > and the MOUNT_WAIT setting will tell autofs not to probe when performing > simple mounts. This was done to provide a way to use the previous autofs Apparently it does not work, since -fstype=nfs4 is already specified. > mechanism without having to endure lengthy timeouts. Using MOUNT_WAIT > isn't ideal but that's a discussion for another day. > >> >> This will keep the general potential problem of using >> UDP in the first place, and this might want a separate >> solution (maybe eliminating UDP altogether), but I'm >> not sure I want to change that much in one go :) >> >>>> Alternatively, we may try to contact 2049 port first, >>>> and if that one does not respond, try to contact the >>>> portmapper. But I'm not sure if this is right thing >>>> to do to start with. >>> >>> Don't know that yet either. >> >> Currently it doesn't work with at all /net map. I asked >> several times on IRC about this very case, -- whenever it >> is ever possible to enumerate (nfsv4) exports without >> portmapper, but no one replied :( Note: I know right to >> nothing about this RPC internals. > > Since the recommended way to use a hosts map is by using the internal > autofs hosts map I'll talk about that. If the customer is using the > example program map auto.net then they can work out how they wish to do > it themselves. I'm not questioning indirect /net map here, I just mentioned it since in this context. The provided shell script uses showmount, which does not work without portmapper running and accessible on the server. The only way to "fix" this issue and allow NFSv4 mounts without portmapper on the server is to implement showmount -e in automount (should be more or less easy since it already implements some RPC required for this), and/or fix the showmount utility to try port 2049 directly somehow (which is out of scope for autofs mailinglist obviously) > The internal hosts map gets the list of exports from the nfs server and > constructs a multi-mount map entry from that. > > To do that it must consult rpc.mountd(8) on the server which means it > must consult the port mapping service to get the port it's available on. With NFSv4 all this is available on port 2049. > So that's one reason the hosts map is having a problem. It wouldn't too This is just a related problem. > hard to add a configuration option for the mountd port and update the > hosts map code to behave itself when the fstype=nfs4 option is also > present. Clearly the mountd service might not be running on the same > port on all servers but we're talking about firewalls which should be > able to do port redirects based on ip address. In any case that's not > really an autofs problem. Well, it is not: since automount already tries to do some NFS-related RPC, it can implement showmount directly, and can probe NFS4 port (2049) -- say, if portmappeer does not respond, or maybe if some option is given (it needs to support mixed environments too, somehow). But yes, this is a separate topic. > The next problem is that rpc.mountd(8) provides limited information. We > only get the export path and access list. There is no information about > nfs protocol version. There's also no way to tell if the exports use the > global root. If the server exports are using a global root there's no > way to know what the base path of the global root is. That means autofs > has no (reliable) way to find out what path to use to alter the path > used in mounts to the server. > > Essentially, nfs setups that use the global root only are not supported > by the internal hosts map. Thanks, /mjt -- To unsubscribe from this list: send the line "unsubscribe autofs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
