* Brian Murray [2014-06-25 18:54:46 -0000]:
> Sergio - could you provide a test case which is part of the Stable
> Release Update process so that we can get this fixed in 14.04?
Let me try. The problem manifested itself spontaneously in my production
environment so I'm not sure exactly which ingredients are required
and which are optional. The following is probably overspecified.
Prerequisites:
-- a Kerberos realm (EXAMPLE.ORG); my KDC runs Heimdal (slightly modified
from Debian wheezy) but I see no reason why this should matter here.
-- an NFS server host (server.example.org) with /etc/krb5.keytab containing
valid keys for nfs/server.example....@example.org, package nfs-kernel-server
installed, a filesystem at /export/nfs and an entry for it in /etc/exports:
/export/nfs client.example.org(sec=krb5p,rw,root_squash,sync,no_subtree_check)
This server can but need not be running Ubuntu 14.04 (in my tests it was
running Debian wheezy).
-- an NFS client host (client.example.org) with autofs configured to automount
server.example.org:/export/nfs somewhere (say, on /srv/nfs), running
the version of rpc.gssd that is to be tested. Remember to include sec=krb5p
in the mount options. It is recommended to run rpc.gssd with a short timeout
(e.g., rpc.gssd -t 60) at least for the purposes of this test: the bug
manifests itself when rpc.gssd prepares a new GSS context for the kernel,
so it helps to force this to happen often. In my environment the client
has machine credentials in /etc/krb5.keytab
(host/client.example....@example.org, nfs/client.example....@example.org
and root/client.example....@example.org) though this is probably overkill
for the purposes of this test. The problem should be reproducible with a
static mount (no autofs) as well but I haven't actually tried that.
Testing procedure:
1. Log in to client.example.org as a non-root user with a corresponding
principal in EXAMPLE.ORG.
2. Obtain a Kerberos TGT for this user, either as part of the login process
(pam_krb5) or interactively by running kinit.
3. Try to access the mountpoint of the NFS share (/srv/nfs). A simple
ls /srv/nfs
should be enough. This is expected to succeed even when the bug is present;
if it doesn't, the setup must be incorrect.
4. Look for warning messages from rpc.gssd (as in the subject of this bug
report) in the client's syslog (or, if running rpc.gssd -f, on standard
error) triggered by the NFS activity at step 3. These messages should no
longer appear once the patch is applied.
I've glossed over the configuration of /etc/idmapd.conf since I expect it
should all work with default settings there.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1331201
Title:
rpc.gssd: ERROR: GSS-API: error in gss_free_lucid_sec_context():
GSS_S_NO_CONTEXT
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1331201/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
