On Thu, 2012-06-07 at 22:52 +0400, Michael Tokarev wrote: > 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. Even though your suggesting the use of $SUBJECT it seems to me that the actual issue we need to fix is inappropriate portmapper requests. I've already mentioned that I need to look into that as I've had a report about it, other than this one, so let me do that before we talk further. > > 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. It looks like your mistaken, or I have another mistake somewhere. sun_mount: parse(sun): mounting root /misc, mountpoint test, what gnome:/data, fstype nfs, options vers=4 mount_mount: mount(nfs): root=/misc name=test what=gnome:/data, fstype=nfs, options=vers=4 --------^ which is not fstype=nfs4 and, as I mentioned already, automount doesn't look at the mount options at the moment so it doesn't know the request is v4 only. Once again that's worth changing but I want to avoid changing mount options as much as possible because that could easily become something that changes what the user actually wants. But this particular case should not lead to that. > > Note that MOUNT_WAIT description is wrong in > samples/autofs.conf.default: the description talks about > umount, while apparently it applies to mount. I know, I need to get around to fixing that some time. > > > 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. Right, but I think you didn't get the whole picture of what I was trying to describe. Maybe we'll return to that later. Recent (it's even not so recent now) mount.nfs(8) will do nfs version fallback. Obviously you need an nfs server and client that support it but that's not so recent now either. > > > 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 auto.net script is installed for people that still want to use it, it isn't what is recommended for the hosts map. It is essentially a simple example program map, nothing more. There's no need to change automount to use the showmount mechanism because that is already the way it is done. That has been the case for several years now. > > > 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. Yeah, I must admit I've been stuck on needing mountd to obtain the list of exports. Certainly, for a server to be able to support fallback to earlier nfs versions on mount then mountd must be used and the export paths returned by it must correspond to what is used as the path in the mount request. But for a server that is nfsv4 only and exports only the global root (the fsid=0 export) then the hosts map entry (that would be returned by the internal hosts map module) becomes trivial: <server> <mount options> &:/ and the nfs kernel client takes care of automounting on crossing mount points. So there's no need for automount to use nfs LOOKUP and READDIR RPC calls to construct the global root mount tree, or contact portmapper or mountd. I guess if the server (possibly also nfs4 only) has other exports that are v4, but not under the global root tree, restricting the hosts map to only the fsid=0 tree when fstype=nfs4 might be what I should have done in the beginning. Maybe we could come up with a sensibly named autofs pseudo option for this case ..... But what I don't know is how to work out when a server is nfsv4 only if there is no option to indicate it. Not sure about side effects of a change like that though, because that would change what people expect from the existing behavior, but certainly worth more thought. > > > 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 -- 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
