On Sep 30, 2010, at 1:07 PM, Trond Myklebust wrote: > On Thu, 2010-09-30 at 11:42 -0400, Chuck Lever wrote: > >> I might choose a less generic name for this program, unless there are plans to make it handle all NFS upcalls, eventually. How about nfs.idmap ? > > nfs.idmap sounds good. > >> Should nfs.upcall have its own man page? My opinion is that it should. That might be a better place for the setup information (needed by mortal system administrators) added under Documentation/ by an earlier patch. Documentation/ is an appropriate place for the upcall design information, though. > > Agreed. We do need to help people who want to edit /etc/request-key.conf > themselves. > >> Also, I've been looking at the Mesta-Adamson draft that provides NFSv4 domain information via DNS. I'd like to see Linux make use of this TXT record, as Solaris does today. It would help make Linux NFSv4 more automatically configurable, especially in heterogeneous environments. > > That looks like something that needs to be added to libnfsidmap. I don't > think we need to make the kernel domain-aware. > >> As I understand it, nfs.upcall would obviate rpc.idmapd, correct? In that case, what entity would be responsible for a putative DNS lookup to determine the local NFSv4 domain name? How would this information be cached? > > See above. OK, makes sense. My only concern here is that the new design does not preclude the easy ability to get the TXT record and cache its value locally for a reasonable period of time. Replacing a long-running daemon with a multiple invocation program may change the picture a little, if I understand the new design correctly. In the end, we could rely on local caching of DNS results (by, say, nscd) and let libnfsidmap do the DNS search whenever it wants. >> Finally, if at all possible, it would be better if the kernel could automatically recognize and use nfs.upcall rather than the legacy idmapping mechanism. My experience with CONFIG options is that people will almost always choose the wrong setting no matter how many large neon arrows you add. I know there are likely some technical challenges here. > > I don't think that is easy to do. The keyring upcall mechanism will > almost always succeed, no matter whether or not there is a handler for > the type of key requested. Instead, it will result in a negative lookup. > Unfortunately, seeing a negative key isn't sufficient to determine that > no handler exists. Yes, I acknowledge it may be difficult. And perhaps using the keyring mechanism as it stands today to detect which mechanism to use might not be trivial. Maybe the keyring mechanism is deficient in this regard and could be fixed? However, the general principal still holds (based on experience we both have! :-) that having an automated mechanism is better than a build-time CONFIG option. If we consider this for a bit and decide it's too hard, then so be it. -- chuck[dot]lever[at]oracle[dot]com -- 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
