On 08/15/2016 11:16 AM, Chuck Lever wrote: > >> On Aug 15, 2016, at 10:57 AM, Steve Dickson <SteveD@xxxxxxxxxx> wrote: >> >> >> >> On 08/14/2016 02:59 PM, Chuck Lever wrote: >>> Hey Steve- >>> >>> Sorry for the delay, and thanks for putting this together! >>> >>> >>>> On Aug 11, 2016, at 5:26 PM, Steve Dickson <SteveD@xxxxxxxxxx> wrote: >>>> >>>> In domain_from_dns(), when at the hostname is a FQHN >>>> query the DNS server for the _nfsv4idmapdomain TXT >>>> record. If the record exists, use that as the >>>> NFSv4 domain. >>>> >>>> Note, this query will only happen if the domain name >>>> is not set in the /etc/idmapd.conf >>> >>> Is there a man page update that goes with this? The order in >>> which the library searches for the domain name should be >>> documented. idmapd.conf(5), maybe. >> Yes... I should have made this an RFC patch since I just >> wanted to get core out there for for comments... >> The man page needs to updated as well as the configure.ac. > > To enable this feature IMO a better choice is to use a command > line option on nfsidmap and rpc.idmapd. With Solaris, is this on by default or off? If needed.. (a big if) I think I would rather have a way to disable it. > > >>> Also, some indication of when a change to the TXT record can >>> be observed by users could be mentioned. >> I'm not sure what you are asking here... There is the TTL time >> for TXT that is returned in the query but that is completely >> controlled by the admin... > > Mostly this is about what might go into a man page update. > > After the TXT record is changed, how long before the client > moves a mapped user ID from the old domain to the new one? >From a DNS standpoint all depends on the TTL on the TXT record >From an NFS standpoint the next call to DNS. > How long before all the mapped user IDs are converted to the new > domain? (I think I know the answer, but what should the man > page say about it). The keys all have timeouts on them... so when they timeout... I guess maybe the key chain can be invalidate when a change is noticed? That would be easy with a daemon not so easy with a command. > > For instance, the kernel's cache of keys delays the effect of > changing the result of that TXT query. Should the man page > recommend a flush of that cache on clients? Hmm... adding a second step.. it probably should be automatic. steved. > > > -- > Chuck Lever > > > -- 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
