Hey Chuck On 07/30/2015 11:17 AM, Chuck Lever wrote: >>> >> Does it make sense to extend the nfsidmap command to display and >>> >> modify the NFSv4 domain name? >> > I would think so... All the tools (aka conf_XXX() calls) are there >> > and I think it would be relatively simple... > Any opinions about what command line options to use? How about: > > To view: nfsidmap -D > > To update: [sudo] nfsidmap -U new.domain.name Just curious as to why upcase... I was thinking -s / -d domain.name no big deal... either way is fine... > > On the client, updating the domain name requires "nfsidmap -c" > to clear the kernel idmap keyring. That can be built in to -U. That makes sense... as long as its documented... > > On the server, I guess restarting rpc.idmapd would also be > required. Would be nice if server and client idmapping both used > request-key. I totally agree with this... Since the default on the server is to use uid/gid strings instead of name@domain strings it not clear how much the new up-call would be used. > > >> > Another thing I always thought would be nice is a way >> > to show the existing uid/gid keys in a human format. >> > Now to see what keys exist one has to cat /proc/keys >> > which is not very readable... > Or use keyctl. > > Either works for debugging and development, but neither are > appropriate as an administrative interface, IMO. Probably... but admin are curious people they might find some use for the interface. > > Something like "nfsidmap -l" would be simple, and could show > both legacy and id_resolv keys, if we like. Perfect! > > Btw, it looks like most recent kernels ignore the "-t" option. > It should be fixed or removed. I guess we could deprecate it. Its not clear how that was ever used in the first place... I just added because I could... ;-) 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
