From: Steve Dickson <SteveD@redhat.com>
To: Chuck Lever <chuck.lever@oracle.com>,
Benjamin Coddington <bcodding@redhat.com>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: building upstream nfs-utils on EL6 fails
Date: Sun, 02 Nov 2014 11:44:28 -0500 [thread overview]
Message-ID: <54565F6C.60204@RedHat.com> (raw)
In-Reply-To: <0ED5691C-39ED-4132-B6C9-5B6FB40D4CF1@oracle.com>
On 10/30/2014 01:19 PM, Chuck Lever wrote:
>> Yes, I agree. It occurs to me that you can also call these through the
>> > syscall keyctl(), and pass the function number - so we can bypass a
>> > non-compatible libkeyutils with something like (the untested):
>> >
>> > diff --git a/utils/nfsidmap/nfsidmap.c b/utils/nfsidmap/nfsidmap.c
>> > index e0d31e7..99ae07e 100644
>> > --- a/utils/nfsidmap/nfsidmap.c
>> > +++ b/utils/nfsidmap/nfsidmap.c
>> > @@ -209,10 +209,17 @@ static int key_invalidate(char *keystr, int keymask)
>> > *(strchr(buf, ' ')) = '\0';
>> > sscanf(buf, "%x", &key);
>> >
>> > - if (keyctl_invalidate(key) < 0) {
>> > - xlog_err("keyctl_invalidate(0x%x) failed: %m", key);
>> > - fclose(fp);
>> > - return 1;
>> > +/* older libkeyutils compatibility */
>> > +#ifndef KEYCTL_INVALIDATE
>> > +#define KEYCTL_INVALIDATE 21 /* invalidate a key */
>> > +#endif
>> > + if (keyctl(KEYCTL_INVALIDATE, key) < 0 && errno == EOPNOTSUPP) {
>> > + /* older kernel compatibility attempt: */
>> > + if (keyctl_revoke(key) < 0) {
>> > + xlog_err("keyctl_invalidate(0x%x) failed: %m", key);
>> > + fclose(fp);
>> > + return 1;
>> > + }
>> > }
>> >
>> > keymask &= ~mask;
>> >
>> > This should try to do the keyctl_invalidate if the kernel has it instead
>> > of relying on the stub in libkeyutils.
> I tested this with upstream 3.17, 2.6.39-400.209.1.el6uek.x86_64 (UEK2),
> and 2.6.32-504.el6.x86_64. I think this approach can work.
>
> Upstream 3.17 worked as expected.
Can we add this to the upcoming RH bz....
>
> UEK2 seems to use only the rpc.idmapd interface, no keys were created,
> and the test workload ran normally.
>
> 2.6.32-504.el6.x86_64 almost worked.
>
> Oct 30 13:01:58 dali nfsidmap_new[2321]: key: 0x249ea9d9 type: uid value: cel@oracle.com timeout 600
> Oct 30 13:01:58 dali nfsidmap_new[2321]: nfs4_name_to_uid: calling nsswitch->name_to_uid
> Oct 30 13:01:58 dali nfsidmap_new[2321]: nss_getpwnam: name 'cel@oracle.com' domain 'oracle.com': resulting localname 'cel'
> Oct 30 13:01:58 dali nfsidmap_new[2321]: nfs4_name_to_uid: nsswitch->name_to_uid returned 0
> Oct 30 13:01:58 dali nfsidmap_new[2321]: nfs4_name_to_uid: final return value is 0
> Oct 30 13:01:58 dali nfsidmap_new[2323]: key: 0x2944b451 type: gid value: users@oracle.com timeout 600
> Oct 30 13:01:58 dali nfsidmap_new[2323]: nfs4_name_to_gid: calling nsswitch->name_to_gid
> Oct 30 13:01:58 dali nfsidmap_new[2323]: nfs4_name_to_gid: nsswitch->name_to_gid returned 0
> Oct 30 13:01:58 dali nfsidmap_new[2323]: nfs4_name_to_gid: final return value is 0
>
> Golden. But nfsidmap_new was not able to set the key timeouts:
>
> [root@dali ~]# cat /proc/keys
> 020d3315 I--Q-- 3 perm 1f3f0000 0 -1 keyring _uid.0: empty
> 0bf90e2d I--Q-- 5 perm 1f3f0000 0 0 keyring _ses: 1/4
> 1a94e9ce I--Q-- 1 perm 1f3f0000 0 -1 keyring _uid_ses.0: 1/4
> 1f77c0ad I--Q-- 1 perm 3f050000 0 0 id_resolv gid:root@oracle.com: 2
> 249ea9d9 I--Q-- 1 perm 3f050000 0 0 id_resolv uid:cel@oracle.com: 5
> 2944b451 I--Q-- 1 perm 3f050000 0 0 id_resolv gid:users@oracle.com: 4
> 3641d485 I----- 1 perm 1f030000 0 0 keyring .id_resolver: 4/4
> 3b10283e I--Q-- 1 perm 3f050000 0 0 id_resolv uid:root@oracle.com: 2
>
> I’m not sure if that’s normal for EL6 kernels, since I haven’t
> used one of the stock EL6 kernels in a while.
>
> An unrelated problem: upstream nfs-utils still doesn’t build
> properly on EL6: nfsdcltrack can’t find the exact sqlite3 calls
> it needs, and the build bails (fortunately after building
> nfsidmap). More autoconf goo is needed to fix that.
Sounds like another RH bz to me... ;-)
steved.
next prev parent reply other threads:[~2014-11-02 16:44 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-29 21:54 building upstream nfs-utils on EL6 fails Chuck Lever
2014-10-29 23:27 ` Benjamin Coddington
2014-10-30 0:24 ` Chuck Lever
2014-10-30 14:53 ` Benjamin Coddington
2014-10-30 15:31 ` Chuck Lever
2014-10-30 16:06 ` Chuck Lever
2014-10-30 16:16 ` Benjamin Coddington
2014-10-30 16:08 ` Benjamin Coddington
2014-10-30 16:18 ` Chuck Lever
2014-10-30 16:52 ` Benjamin Coddington
2014-10-30 17:19 ` Chuck Lever
2014-11-02 16:44 ` Steve Dickson [this message]
2014-11-03 14:44 ` Benjamin Coddington
2014-11-03 14:55 ` Chuck Lever
2014-10-30 15:42 ` Steve Dickson
2014-10-30 15:34 ` Steve Dickson
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=54565F6C.60204@RedHat.com \
--to=steved@redhat.com \
--cc=bcodding@redhat.com \
--cc=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.