[LU-3490] GSSAPI support not tested by Gerritt

• Type: Technical task
• Resolution: Fixed
• Priority: Blocker
• Fix Version/s: Lustre 2.5.0
• Affects Version/s: Lustre 2.4.1
• Labels: SSK patch
• Environment: All
• Assignee: Minh Diep
• Reporter: Andrew Korty (Inactive)

Issue Links

• is related to: LU-3288 Enabling GSSAPI support requires Kerberos libraries to be installed

Comments

[Patrick Farrell (Inactive)]

Minh,

Not in general. This is the output for el6 inkernel from the same build (http://build.whamcloud.com/job/lustre-reviews/18238/arch=x86_64,build_type=server,distro=el6,ib_stack=inkernel/consoleFull):
checking for gss_export_lucid_sec_context in -lgssapi... no
checking for gss_export_lucid_sec_context in -lgssglue... yes

So that same situation works for el6.
One of lgssapi or lgssglue seems to be sufficient.

Maybe that's not true for sles11sp1.

[Minh Diep]

The reason it failed in sles11sp1 but not sles11sp2 is

sles11sp1:
checking for gss_export_lucid_sec_context in -lgssapi... no
checking for gss_export_lucid_sec_context in -lgssglue... yes <<<<

sles11sp2:
checking for gss_export_lucid_sec_context in -lgssapi... no
checking for gss_export_lucid_sec_context in -lgssglue... no

I believe the logic in the patch

AC_CHECK_LIB([gssapi], [gss_export_lucid_sec_context],
[GSSAPI_LIBS="$GSSAPI_LDFLAGS -lgssapi";
gss_conf_test='success'],
[AC_CHECK_LIB([gssglue], [gss_export_lucid_sec_context],
[GSSAPI_LIBS="$GSSAPI_LDFLAGS -lgssglue";
gss_conf_test='success'],
[if test x$enable_gss == xyes; then
AC_MSG_ERROR([libgssapi or libgssglue is not found, which is required by GSS.])
else
AC_MSG_WARN([libgssapi or libgssglue is not found, which is required by GSS.])
fi])],)

do we need both libgssapi and libgssglue to be yes or both to be no?

[Patrick Farrell (Inactive)]

Nice catch, Minh, that does fix most of the build failures. The remaining ones are unusual issues unique to SLES11 and Ubuntu 10.04. I'll leave those to you.

[Minh Diep]

I updated the patch and now it only failed on sles http://build.whamcloud.com/job/lustre-reviews/18238/

[Minh Diep]

just a notice

checking whether to enable gss/krb5 support... auto
checking whether to enable gss keyring backend... auto
checking if Linux was built with CONFIG_KEYS in or as module... yes
checking for keyctl_search in -lkeyutils... yes
checking if Linux was built with CONFIG_SUNRPC in or as module... yes
checking if Linux was built with CONFIG_CRYPTO_MD5 in or as module... yes
checking if Linux was built with CONFIG_CRYPTO_SHA1 in or as module... yes
checking if Linux was built with CONFIG_CRYPTO_SHA256 in or as module... yes
checking if Linux was built with CONFIG_CRYPTO_SHA512 in or as module... yes
checking for Kerberos v5...
The current KRBDIR is

If we leave gss and gss keyring on auto and have keyutils..., but not Kerberos, should we issue a warning?

[Patrick Farrell (Inactive)]

As expected, with that patch, the tests for GSS keyring are passing and it is failing to build:
/var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c: In function 'request_key_unlink':
/var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:652: error: 'struct task_struct' has no member named 'jit_keyring'
/var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:655: error: 'struct task_struct' has no member named 'thread_keyring'
/var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:659: error: 'struct signal_struct' has no member named 'process_keyring'
/var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:664: error: 'struct signal_struct' has no member named 'session_keyring'
cc1: warnings being treated as errors
/var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:664: error: type defaults to 'int' in declaration of '_________p1'
/var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:664: error: 'struct signal_struct' has no member named 'session_keyring'
/var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:664: error: 'struct signal_struct' has no member named 'session_keyring'
/var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:664: error: type defaults to 'int' in declaration of 'type name'
/var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:665: error: passing argument 1 of 'key_get' makes pointer from integer without a cast
/var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/reused/usr/src/kernels/2.6.32-358.18.1.el6_lustre.gd8b4950.i686/include/linux/key.h:217: note: expected 'struct key *' but argument is of type 'int'
/var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:670: error: 'struct task_struct' has no member named 'user'
/var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:673: error: 'struct task_struct' has no member named 'user'
/var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c: In function 'gss_kt_instantiate':
/var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:1255: error: 'struct signal_struct' has no member named 'session_keyring'
/var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:1258: error: 'struct signal_struct' has no member named 'session_keyring'
/var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:1261: error: 'struct signal_struct' has no member named 'session_keyring'
make[7]: *** [/var/lib/jenkins/workspace/lustre-reviews/arch/i686/build_type/server/distro/el6/ib_stack/inkernel/BUILD/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.o] Error 1

[Patrick Farrell (Inactive)]

Patch up at http://review.whamcloud.com/#/c/7622/

[Patrick Farrell (Inactive)]

OK, a bit of further information. I've been unable to build GSS with GSS_KEYRING enabled. I originally thought that was because of a problem with my kernel source, but I've now re-downloaded and rebuilt that twice now. The tests for building GSS_KEYRING are passing, but the code itself is not building; I'm getting errors indicating that some of the definitions it depends on aren't available. In particular, these appear to be those things which are defined if CONFIG_KEYS is set in the kernel.

I've looked at the .config file being used to build the kernel, and I've confirmed CONFIG_KEYS is definitely set (It's the Lustre provided .config file.). (I'm following the WC build instructions from here: https://wiki.hpdd.intel.com/pages/viewpage.action?pageId=8126821)

Since the 'auto' setting wasn't actually causing GSS to be built, I suspect that GSS_KEYRING actually hasn't been built lately and is linked incorrectly. I suspect if you tried to build it (--enable-gss is sufficient with current master) you'd find these same failures:
—
make[5]: Entering directory `/home/build/kernel/rpmbuild/BUILD/kernel-2.6.32.358.18.1.el6_lustre'
/home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c: In function 'request_key_unlink':
/home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:652: error: 'struct task_struct' has no member named 'jit_keyring'
/home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:655: error: 'struct task_struct' has no member named 'thread_keyring'
/home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:659: error: 'struct signal_struct' has no member named 'process_keyring'
/home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:664: error: 'struct signal_struct' has no member named 'session_keyring'
cc1: warnings being treated as errors
/home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:664: error: type defaults to 'int' in declaration of '_________p1'
/home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:664: error: 'struct signal_struct' has no member named 'session_keyring'
/home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:664: error: 'struct signal_struct' has no member named 'session_keyring'
/home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:664: error: type defaults to 'int' in declaration of 'type name'
/home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:664: error: passing argument 1 of 'key_get' makes pointer from integer without a cast
/home/build/kernel/rpmbuild/BUILD/kernel-2.6.32.358.18.1.el6_lustre/include/linux/key.h:217: note: expected 'struct key *' but argument is of type 'int'
/home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:670: error: 'struct task_struct' has no member named 'user'
/home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:673: error: 'struct task_struct' has no member named 'user'
/home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c: In function 'gss_kt_instantiate':
/home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:1255: error: 'struct signal_struct' has no member named 'session_keyring'
/home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:1258: error: 'struct signal_struct' has no member named 'session_keyring'
/home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.c:1261: error: 'struct signal_struct' has no member named 'session_keyring'
make[9]: *** [/home/build/kernel/rpmbuild/BUILD/lustre-2.4.92/lustre/ptlrpc/gss/gss_keyring.o] Error 1
—

I will put up a patch to fix the autoconf behavior, but I don't currently see how to fix the problem with building GSS_KEYRING. That means build systems without libkeyutils installed will gracefully choose not to build GSS_KEYRING, but those with libkeyutils installed will pass the autoconf tests and then fail to compile.

[Patrick Farrell (Inactive)]

Sorry about the delay on this, I ran in to some unexpected issues on my build system.

It turns out the 'auto' from the original patch is causing the GSS dependencies to be checked, but it's not actually causing GSS to be built. I figured that out because my build system couldn't actually build GSS [A separate issue with my kernel source], and I couldn't understand why make rpms succeeded with gss not enabled or disabled (So, using 'auto'), but failed with gss enabled.

This is because enable_gss is used like this in the 'configure' file that autoconf generates:
if test x$enable_gss = xyes; then
GSS_TRUE=
GSS_FALSE='#'
else
GSS_TRUE='#'
GSS_FALSE=
fi
^-- So when it's set to auto, GSS_TRUE is not set as expected. This (GSS_TRUE) is the macro actually used by the make files.

The simple solution is to start with enable_gss to auto as we do now, then if the various tests pass, set it to 'yes' before leaving the function. I've tested doing this and it causes gss to be built by default.

Once I've sorted out my other build issues and can completely build GSS without errors, I'll be able to test to my satisfaction and put up a patch for this and the earlier problem.
—

Andrew:
About spuriously setting HAVE_GSS. HAVE_GSS is defined before the code block below. Consider the 'auto' case where the libraries are not found - HAVE_GSS will remain defined, but it's not correct.

In any case, you're right that it shouldn't cause a problem - HAVE_GSS isn't actually used anywhere else, as far as I can tell. (Though I'm hardly an autoconf expert.)

if test x$KRBDIR != x; then
AC_CHECK_LIB([gssapi], [gss_export_lucid_sec_context],
[GSSAPI_LIBS="$GSSAPI_LDFLAGS -lgssapi"],
[AC_CHECK_LIB([gssglue], [gss_export_lucid_sec_context],
[GSSAPI_LIBS="$GSSAPI_LDFLAGS -lgssglue"],
[if test x$enable_gss == xyes;
AC_MSG_ERROR([libgssapi or libgssglue is not found, which is required by GSS.])
fi])],)

[Andrew Korty (Inactive)]

I agree with Ken: GSS_KEYRING need not be a prerequisite to GSS. I also think Patrick has something about HAVE_GSS getting set spuriously although I'm sure I tested for that case. At any rate, it would make more sense for HAVE_GSS to reflect the situation accurately.

[Patrick Farrell (Inactive)]

Ken,

Thanks, that matches my understanding and fits with the autoconf file as written (Specifically the fact that it's possible to enable/disable gss_keyring separately from gss).

Minh,

Thanks - I'll have it up for review in a little bit.