On Nov 17, 2010, at 11:26 AM, Kevin Coffman wrote: > On Wed, Nov 17, 2010 at 11:05 AM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: >> >> 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? > > Not that I am aware of. Like Valentin, I believe it to be a > NetworkManager bug. (The Kerberos code works fine on all other Unix > platforms.) The hostname is added to localhost entries in /etc/hosts because some applications require at least one entry with the local host's hostname in /etc/hosts. When a system comes up with all of its network interfaces offline and without any IP addresses assigned, what else can be done? One way to address this via NetworkManager might be to have the hostname removed from the localhost entries when a real IP address for the host is added to /etc/hosts, and then added back to the localhost entries when all network interfaces are disabled. -- 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
