Re: managing the system's NFSv4 domain name

[Steve Dickson <SteveD@redhat.com>]

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.