All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chuck Lever <chuck.lever@oracle.com>
To: Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Strange rpc.svcgssd behavior
Date: Mon, 15 Nov 2010 12:39:49 -0500	[thread overview]
Message-ID: <1C8B051A-5DC1-4871-B9B9-96E571036A9B@oracle.com> (raw)

I've just set up a Linux KDC with a Linux NFS server (Fedora 13 with the latest updates).

rpc.svcgssd fails to start on the NFS server.

 ERROR: GSS-API: error in gss_acquire_cred(): Unspecified GSS failure.  Minor code may provide more information - Key table entry not found
 unable to obtain root (machine) credentials
 do you have a keytab entry for nfs/<your.host>@<YOUR.REALM> in /etc/krb5.keytab?

I do have an entry for nfs/<your.host>@<YOUR.REALM> in /etc/krb5.keytab.  The problem is that /etc/hosts looks like this:

 192.168.1.58	your.host	your	# Added by NetworkManager
 127.0.0.1	localhost.localdomain	localhost
 ::1		your.host your	localhost6.localdomain6 localhost6

Removing "your.host	your" from the "::1" entry makes this problem go away -- rpc.svcgssd starts up as expected.

Now I reboot, and NetworkManager happily adds "your.host	your" back to the "::1" entry, and rpc.svcgssd fails again.  I haven't tried this, but I suspect if the ::1 entry weren't there, NM would add "your.host.net	your" to the IPv4 loopback entry, and we'd have the same problem.

At a glance, it looks like the local hostname is determined in a library, and not in rpc.svcgssd.  This really needs to be more robust.

I see the "-p principal" option in the latest nfs-utils, but it doesn't seem to be supported in Fedora 13's rpc.svcgssd.  Is this the workaround?

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com





             reply	other threads:[~2010-11-15 17:40 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-15 17:39 Chuck Lever [this message]
2010-11-16 15:58 ` Strange rpc.svcgssd behavior Valentijn Sessink
2010-11-16 19:44   ` Valentijn Sessink
2010-11-16 20:17     ` Jim Rees
2010-11-16 20:22       ` Chuck Lever
2010-11-16 20:54         ` Jim Rees
2010-11-16 21:41           ` J. Bruce Fields
2010-11-16 21:42           ` Chuck Lever
2010-11-17 15:18             ` Steve Dickson
2010-11-17 15:30               ` Chuck Lever
2010-11-17 15:54                 ` Kevin Coffman
2010-11-17 16:05                   ` Chuck Lever
2010-11-17 16:26                     ` Kevin Coffman
2010-11-17 17:51                       ` Chuck Lever
2010-11-17 18:52                         ` Valentijn Sessink
2010-11-17 16:15                   ` Valentijn Sessink

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1C8B051A-5DC1-4871-B9B9-96E571036A9B@oracle.com \
    --to=chuck.lever@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.