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