managing the system's NFSv4 domain name

managing the system's NFSv4 domain name

[Chuck Lever]

Hi-

At least for testing purposes, it would be great to be able to
manage a system's NFSv4 domain name from the command line. I'm
frequently asked how to determine a system's NFSv4 domain name,
and I'm forced to answer something like this:

> Linux does not currently have a command line tool for managing
> the system's NFSv4 idmapping domain. Use:
> 
> awk '/^Domain/ { print $3 }' < /etc/idmapd.conf
> 
> If that fails to find anything, then use `dnsdomainname` . That
> won't be helpful if the system has multiple i/f's.


This doesn't even get into /proc/keys, or what to do to change
the NFSv4 domainname, or the differences between rpc.idmapd and
the keyring-based idmapper.

Linux now has hostnamectl and other tools to manage a system's
hostname and so on. Solaris has sharectl, which can display and
update the nfs4mapid_domain.

Does it make sense to extend the nfsidmap command to display and
modify the NFSv4 domain name?


--
Chuck Lever

Re: managing the system's NFSv4 domain name

[Steve Dickson]

On 07/29/2015 10:28 PM, Chuck Lever wrote:
> Hi-
> 
> At least for testing purposes, it would be great to be able to
> manage a system's NFSv4 domain name from the command line. I'm
> frequently asked how to determine a system's NFSv4 domain name,
> and I'm forced to answer something like this:
> 
>> Linux does not currently have a command line tool for managing
>> the system's NFSv4 idmapping domain. Use:
>>
>> awk '/^Domain/ { print $3 }' < /etc/idmapd.conf
>>
>> If that fails to find anything, then use `dnsdomainname` . That
>> won't be helpful if the system has multiple i/f's.
> 
> 
> This doesn't even get into /proc/keys, or what to do to change
> the NFSv4 domainname, or the differences between rpc.idmapd and
> the keyring-based idmapper.
> 
> Linux now has hostnamectl and other tools to manage a system's
> hostname and so on. Solaris has sharectl, which can display and
> update the nfs4mapid_domain.
> 
> 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... 

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... 

steved. 

Re: managing the system's NFSv4 domain name

[Chuck Lever]

On Jul 30, 2015, at 9:39 AM, Steve Dickson <SteveD@redhat.com> wrote:

> On 07/29/2015 10:28 PM, Chuck Lever wrote:
>> Hi-
>> 
>> At least for testing purposes, it would be great to be able to
>> manage a system's NFSv4 domain name from the command line. I'm
>> frequently asked how to determine a system's NFSv4 domain name,
>> and I'm forced to answer something like this:
>> 
>>> Linux does not currently have a command line tool for managing
>>> the system's NFSv4 idmapping domain. Use:
>>> 
>>> awk '/^Domain/ { print $3 }' < /etc/idmapd.conf
>>> 
>>> If that fails to find anything, then use `dnsdomainname` . That
>>> won't be helpful if the system has multiple i/f's.
>> 
>> 
>> This doesn't even get into /proc/keys, or what to do to change
>> the NFSv4 domainname, or the differences between rpc.idmapd and
>> the keyring-based idmapper.
>> 
>> Linux now has hostnamectl and other tools to manage a system's
>> hostname and so on. Solaris has sharectl, which can display and
>> update the nfs4mapid_domain.
>> 
>> 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

On the client, updating the domain name requires "nfsidmap -c"
to clear the kernel idmap keyring. That can be built in to -U.

On the server, I guess restarting rpc.idmapd would also be
required. Would be nice if server and client idmapping both used
request-key.


> 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.

Something like "nfsidmap -l" would be simple, and could show
both legacy and id_resolv keys, if we like.

Btw, it looks like most recent kernels ignore the "-t" option.
It should be fixed or removed.


--
Chuck Lever

Re: managing the system's NFSv4 domain name

[Steve Dickson]

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.

Re: managing the system's NFSv4 domain name

[Chuck Lever]

On Jul 30, 2015, at 2:29 PM, Steve Dickson <SteveD@redhat.com> wrote:

> 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...

"-u user" is already taken. "-d" is typically used to enable
debugging.

> I was thinking  -s / -d domain.name 
> no big deal... either way is fine... 

The important aspect is one dash option, one dash option
with required positional parameter. We can finalize the
exact letters after a prototype materializes.


>> Something like "nfsidmap -l" would be simple, and could show
>> both legacy and id_resolv keys, if we like.
> Perfect! 

I'm guessing the way this needs to work is to do the same
thing a "keyctl list" does, and then prettify the output.

I still wonder about including legacy keys. This version
of nfsidmap would probably never be run on a system that
uses the legacy upcall, unless you intend to backport
this to RHEL 6.


--
Chuck Lever

Re: managing the system's NFSv4 domain name

[Chuck Lever]

On Jul 30, 2015, at 9:39 AM, Steve Dickson <SteveD@redhat.com> wrote:

> 
> 
> On 07/29/2015 10:28 PM, Chuck Lever wrote:
>> Hi-
>> 
>> At least for testing purposes, it would be great to be able to
>> manage a system's NFSv4 domain name from the command line. I'm
>> frequently asked how to determine a system's NFSv4 domain name,
>> and I'm forced to answer something like this:
>> 
>>> Linux does not currently have a command line tool for managing
>>> the system's NFSv4 idmapping domain. Use:
>>> 
>>> awk '/^Domain/ { print $3 }' < /etc/idmapd.conf
>>> 
>>> If that fails to find anything, then use `dnsdomainname` . That
>>> won't be helpful if the system has multiple i/f's.
>> 
>> 
>> This doesn't even get into /proc/keys, or what to do to change
>> the NFSv4 domainname, or the differences between rpc.idmapd and
>> the keyring-based idmapper.
>> 
>> Linux now has hostnamectl and other tools to manage a system's
>> hostname and so on. Solaris has sharectl, which can display and
>> update the nfs4mapid_domain.
>> 
>> 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...

Displaying the effective NFSv4 domain name is easy, but I don't
see anything in libnfsidmap's cfg.c that can write an updated
idmapd.conf file. As far as I can tell, cfg.c is only for reading
and parsing an existing config file.

Is anyone aware of extensions to cfg.c that can update a conf file?


--
Chuck Lever