Hello, On 05/23/2016 01:22 PM, Chuck Lever wrote: > >> On May 23, 2016, at 12:18 PM, Steve Dickson <SteveD@xxxxxxxxxx> wrote: >> >> I have a customer that requested the domain used >> to do the ID mapping be available via DNS SVR >> record. I didn't think was that bad of an idea. > > Solaris NFS peers look for a TXT record. This > facility has been around for a decade or more. > > ;; NFSv4 domain (for idmapping). See Sun doc 819-1634 and > ;; http://tools.ietf.org/html/draft-mesta-nfsv4-domain-01.html > _nfsv4idmapdomain IN TXT "oracle.com" I see... Looks reasonable > > But there's no standard in this area. mesta-nfsv4-domain > was a personal I-D that never advanced. I brought it > up again in Orlando, and the WG decided to table it. > > At the time it was decided that the right course of > action was for the NFSv4 idmapping domain to be set > based on security realm or other criteria. There was > no interest in involving DNS at all. Hmm... it seems pretty convenient to me... although its just another place for rpc.idmap to get hung. ;-) > > >> IPA and FedFS use SRV records which seem to work out >> pretty well. This patch is heavily based on the >> FedFS code. ;-) >> >> My only question is do we want libnfsidmap to be >> dependent on the resolver library. There has been >> some talk about moving libnfsidmap into nfs-utils >> which means nfs-utils would be dependent the >> resolver library. >> >> Note, this is not complete. If we are going to do >> this I have to document it somehow, either in >> the man page or idmap.conf or both. >> >> Just looking for thoughts... good/bad idea?? > > If you really do want to go down this path, I > think Linux should follow the existing de facto > standard (TXT), not invent its own. Maybe also > check how SMB does this. I think I will and I agree using a TXT RR is the way to go... Why reinvent the wheel?? 8-) > > Involving a published DNS record format should > require standards action. But I was discouraged > from pursuing this further. I think if everybody is doing the same thing would be good enough... > > I think it's important to ask in what cases > will the ID mapping domain be different than > the system's DNS domain name, and is there a > preferable mechanism for determining the ID > mapping domain in those cases? Knowing more > about how your customer plans to use this > feature would help us discuss this more fully. This would help me here at Red Hat. I live on at (eat your own dog food) test network that has its own DNS So steved@xxxxxxxxxx maps into a valid id/gid but steved@xxxxxxxxxxxxxxxx does not so I need to add a Domain=redhat.com in /etc/idmapd.conf to get v4 working. Having the domain in our test DNS would work out well. Also, the person that is asking for this is probably moving from a Solaris env to Linx env... That's just a guess. > > I've also proposed the ability to set the ID > mapping domain via a command line tool like > nfsidmap. But I never got past the difficulties > of parsing and updating the /etc/idmapd.conf > file. It makes sense to add an API to libnfsidmap > for setting the system's ID mapping domain name. Does having the domain in DNS help with this? I'm thinking not... > > How would "nfsidmap -d" work if the ID mapping > domain was set via DNS? I guess we would have to teach nfs4_get_default_domain() to check DNS like nfs4_init_name_mapping() would. > > Would the DNS-derived ID domain name be cached > somewhere? Currently its stored in the global default_domain variable in libnfsidmap... I think its a good place for it to live. 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
