On Nov 17, 2010, at 10:54 AM, Kevin Coffman wrote: > On Wed, Nov 17, 2010 at 10:30 AM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: >> Hey- >> >> On Nov 17, 2010, at 10:18 AM, Steve Dickson wrote: >> >>> Sorry for the delayed response... I had my >>> head down for last couple of days... >>> >>> On 11/16/2010 04:42 PM, Chuck Lever wrote: >>>> >>>> On Nov 16, 2010, at 3:54 PM, Jim Rees wrote: >>>> >>>>> Chuck Lever wrote: >>>>> >>>>> Before we go too far down the NM path of no return, I was under the >>>>> impression that some applications require the host's name on the localhost >>>>> entries in /etc/hosts. That's why NM puts it there. >>>>> >>>>> There's nothing invalid about having a hostname on the localhost entries >>>>> in /etc/hosts, is there? >>>>> >>>>> So I wonder if removing NM is really the solution here. >>>>> >>>>> No, it's not. I just like to complain about NM. >>>>> >>>>> The original problem was that rpc.svcgssd couldn't figure out the correct >>>>> kerberos realm. The fix in this particular case, I think, is to set the >>>>> realm explicitly in /etc/idmapd.conf. >>>> >>>> It's having trouble determining the NFS server's hostname. It needs to find the right nfs/your.host key in /etc/krb5.keytab. >>>> >>>> I don't know if realm self-discovery is an issue too. >>> I think the problem is a reverse lookup is done on hostname that >>> is found in the /etc/krb5.keytab. Instead of the FQDN being >>> returned, localhost is returned because the FQDN was added to >>> the localhost line in /etc/hosts. >>> >>> Actually I didn't realize it was NM doing that... I thought >>> it was the installer... >> >> No matter who does it, I think there are applications >> (gdm? rusty recollection) that require this network configuration >> in /etc/hosts, so our best bet IMO is to fix rpc.svcgssd, or more >> likely the gss library it depends on, to get it right in this situation. >> If we all agree this is a bug (and sounds like we do) then I can >> create a bug report on bugzilla.linux-nfs.org, as a starting point. > > Hi Chuck and Steve, > This issue affects gss authentication in sshd as well. I believe this > is all the way down in the Kerberos code, which has been this way for > years. I'm not sure what needs to be changed to "get it right". I was afraid of that. Do you know if this has this ever been brought up with the upstream Kerberos maintainers? -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- 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
