Whamcloud Community JIRA

Whamcloud Community JIRA https://jira.whamcloud.com This file is an XML representation of an issue en-us

9.4.14

940014

05-12-2023

[LU-3490] GSSAPI support not tested by Gerritt https://jira.whamcloud.com/browse/LU-3490 Lustre All LU-3490

GSSAPI support not tested by Gerritt

Technical task LU-3289 Blocker Resolved Fixed Minh Diep Andrew Korty SSK patch Thu, 20 Jun 2013 23:55:32 +0000 Wed, 1 Jun 2016 22:40:27 +0000 Tue, 24 Sep 2013 05:24:18 +0000 Lustre 2.4.1 Lustre 2.5.0 0 13 --enable-gss is not passed to configure on Gerritt test nodes, so GSSAPI code never gets built or tested. Also, commits to other parts of Lustre that break GSSAPI support but test fine without --enable-gss never get noticed. <a href="http://review.whamcloud.com/#/c/6740/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/c/6740/</a> If something like this lands everyone who builds will have to update their build servers for an optional part of the code. Not that it is a major issue but it is far reaching. I wonder if there is a --build-everything setting that would help catch all these sorts of issues for than just GSSAAPI. Is there a GSSAPI Lustre test? I think just enabling gss by default is not all that great of an ideea. Instead, Chris, can you please enable the option on our review builds, buto nly after we install necessary dependencies so that it actually builds. I've changed this patch. Now, the default behavior is to enable GSS only if its prerequisite libraries are installed. Hence, --enable-gss enables GSSAPI or bust; --disable-gss disables it always; and the lack of either option conditionally enables GSSAPI, depending on whether the GSSAPI and Kerberos libraries are installed. Patch landed to Master. Please let me know if any additional work is needed and I will reopen this ticket. This patch introduces a minor regression related to libkeyutils: As Andrew says, the default is to enable GSS only if its prerequisite libraries are installed, but this has a flaw as it relates to libkeyutils and LC_CONFIG_GSS_KEYRING. Without GSS explicitly disabled, our builds (CentOS and SLES) are failing with this message: [ 118s] configure: error: libkeyutils is not found, which is required by gss keyring backend That message is coming from '# LC_CONFIG_GSS_KEYRING (default enabled, if gss is enabled)' in the lustre-core autoconf file. In <a href="https://jira.whamcloud.com/browse/LU-3490" title="GSSAPI support not tested by Gerritt" class="issue-link" data-issue-key="LU-3490"><del>LU-3490</del></a> LC_CONFIG_GSS_KEYRING is called whenever enable_gss is not explicitly set to no, but LC_CONFIG_GSS_KEYRING doesn't check for the 'not explicitly enabled' case and suppress errors like is done in LC_CONFIG_GSS. <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">AC_DEFUN([LC_CONFIG_GSS], [AC_MSG_CHECKING([whether to enable gss/krb5 support]) AC_ARG_ENABLE([gss], [AC_HELP_STRING([--enable-gss], [enable gss/krb5 support])], [],[enable_gss='auto']) AC_MSG_RESULT([$enable_gss]) if test x$enable_gss != xno; then LC_CONFIG_GSS_KEYRING sunrpc_required=$enable_gss LC_CONFIG_SUNRPC sunrpc_required=no [......] 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; then AC_MSG_ERROR([libgssapi or libgssglue is not found, which is required by GSS.]) fi])],) AC_SUBST(GSSAPI_LIBS) fi fi </pre> </div></div> I'm not sure what the best solution here is, there's a bit of an interdependence and I'm not really familiar with autoconf files. We could check for the 'GSS not explicitly enabled' case in LC_CONFIG_GSS_KEYRING, but then we'd have to disable GSS when LC_CONFIG_GSS_KEYRING failed. For the moment, we're working around this by removing <a href="https://jira.whamcloud.com/browse/LU-3490" title="GSSAPI support not tested by Gerritt" class="issue-link" data-issue-key="LU-3490"><del>LU-3490</del></a> and/or explicitly disabling GSS. Thanks for the report, Patrick. I think it makes sense to disable GSS non-fatally if the GSS keyring library is not available. Thoughts? Andrew, I'd agree with that - I would've put a suggested patch together if I were a bit more familiar with autoconf. Reopening this bug until configure is changed to not require libkeyring. There was also agreement from the OpenSFS PAC that this should be a non-fatal error if GSS support was not explicitly requested. We need to get a patch ASAP, since this is likely breaking the build for most external users of Lustre. We didn't notice it internally since we installed these libraries explicitly on all of our build nodes to verify this patch was working. I spent a few minutes trying to generate a patch for this one, but I'm a bit puzzled here. Two things. One: Is it possible/desirable to build with GSS but not with GSS_KEYRING? So, in the default case (enable_gss='auto', if the keyutils library is not found or GSS_KEYRING is explicitly disabledin the config (so HAVE_GSS_KEYRING isn't set), should we leave GSS enabled or disable it? (IE, still set HAVE_GSS) Two, a problem: In the current code, in the default case doesn't HAVE_GSS get set and stay set whether or not the GSS libraries are found? I don't see it getting unset if the required libraries are not found, so if the libgss libraries were actually not available on a build system (I'm not easily able to test, as I've got dependencies on them on my usual build system), wouldn't this fail to build? As for HAVE_GSS, I would move it to after checking the libraries of LC_CONFIG_GSS correct me if I am wrong, could this be solved with a simple enable_gss='no' instead of 'auto'? Minh: Agreed, it can be made conditional on successfully finding the libraries. I think that's the solution. What's preventing me from offering a patch is the first question about the necessity of GSS_KEYRING for GSS. About 'no' instead of 'auto': Yes, that would avoid this problem, but that's basically just reverting this patch completely. The point of the original patch was to turn on GSS by default so it would be tested. I am working on a patch for this now. Do we need kernel sunrpc support for using GSS? Currently it's not if enable_gss is set to auto patch for master <a href="http://review.whamcloud.com/#/c/7622/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/c/7622/</a> I was hoping to offer a new version of Minh's patch, but I can't because I still don't know if GSS_KEYRING is strictly required for GSS. So is it possible/recommended to allow GSS to be enabled when GSS keyring is not? Andrew or Ken, could you please comment on this? So, I could be wrong ... but it looks like the following things are true: The GSS_KEYRING autoconf macro ends up doing two things: defining the HAVE_GSS_KEYRING preprocessor symbol, and setting the GSS_KEYRING Automake conditional. No code uses the HAVE_GSS_KEYRING preprocessor symbol. GSS_KEYRING controls whether or not gss_keyring.c is compiled. Given all that ... I would say, in answer to Patrick's question, it IS possible to allow GSS to be enabled when GSS keyring is not enabled. Recommended, maybe not, but I'd vote for not requiring the dependency on keyring to make things easier for everyone. Patrick, to avoid duplicate works, please go ahead and update the patch. Thank you very much. I will review and make sure it gets tested 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. 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. 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.) <blockquote> 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])],)</blockquote> 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: <a href="https://wiki.hpdd.intel.com/pages/viewpage.action?pageId=8126821" class="external-link" target="_blank" rel="nofollow noopener">https://wiki.hpdd.intel.com/pages/viewpage.action?pageId=8126821</a>) 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. Patch up at <a href="http://review.whamcloud.com/#/c/7622/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/c/7622/</a> 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 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? I updated the patch and now it only failed on sles <a href="http://build.whamcloud.com/job/lustre-reviews/18238/" class="external-link" target="_blank" rel="nofollow noopener">http://build.whamcloud.com/job/lustre-reviews/18238/</a> 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. 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? Minh, Not in general. This is the output for el6 inkernel from the same build (<a href="http://build.whamcloud.com/job/lustre-reviews/18238/arch=x86_64,build_type=server,distro=el6,ib_stack=inkernel/consoleFull):" class="external-link" target="_blank" rel="nofollow noopener">http://build.whamcloud.com/job/lustre-reviews/18238/arch=x86_64,build_type=server,distro=el6,ib_stack=inkernel/consoleFull):</a> 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. Some versions of the GSS library don't provide gss_export_lucid_sec_context(), depending on the vintage. I'm actually in that situation, for a long, complicated, and stupid reason. I suspect that -lgssapi (typically provided by a Kerberos implementation) shipped with SLES11SP1 is one of those vintages. Here's the specific failure for SLES11SP1: cc1: warnings being treated as errors context_lucid.c: In function 'derive_key_lucid': context_lucid.c:354: error: call to function 'krb5_derive_key' without a real prototype context.h:46: note: 'krb5_derive_key' was declared here A bit of looking at the source for SLES11SP2 and CentOS vs SLES11SP1 shows that function is defined in SLES11SP2 and CentOS, but it's not found in SLES11SP1. It looks like the patch here which put functionality for deriving kerberos keys in to the kernel isn't in SLES11SP1. That patch is here: <a href="http://www.mail-archive.com/linux-nfs@vger.kernel.org/msg01668.html" class="external-link" target="_blank" rel="nofollow noopener">http://www.mail-archive.com/linux-nfs@vger.kernel.org/msg01668.html</a> So I don't think there's an easy solution here if we actually want this to work on SLES11SP1, especially not if it's supposed to work on patchless clients. — Ken, It looks like you're right. Still, that function is found in lgssglue in SLES11SP1 and CentOS, so we're OK there. I don't think we are supporting SLES11 SP1 going forward on master, so this may be a non-issue. We need to change out builders to take this into account. Patrick, Ken Do you think 'checking for krb5int_derive_key in -lgssapi_krb5... no' must be yes to be able to build krb? Minh, I see if we have krb5int_derive_key, it will build correctly, because it's used instead of krb5_derive_key. But some platforms have krb5_derive_key, and in that case, they don't need krb5int_derive_key in the libraries. Is it possible that krb5int_derive_key is in one of the two possible GSS libraries and not the other? Maybe we need to require that library if you don't have krb5_derive_key in your kernel? (The SLES11SP1 case.) Andreas, It seems to me the problem with ignoring SLES11 because it's not supported going forward is that GSS_KEYRING won't build with at least b2_4 and possibly earlier versions as well. If it's supported there but can't actually be built... I'd say if we can't fine both krb5int_derive_key and krb5_derive_key, we will issue a warning and set HAVE_KRB5 to 0 The function name krb5_derive_key was renamed in MIT-Kerberos >= 1.8.X. Before it was (<= 1.7.X): <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-none">thomas@lxdv65:~/tmp/krb/krb5-1.7.2>grep -r "krb5int_derive_key" thomas@lxdv65:~/tmp/krb/krb5-1.7.2>grep -r "krb5_derive_key" src/lib/crypto/vectors.c: r = krb5_derive_key (enc, in, out, usage); src/lib/crypto/combine_keys.c: * DK is defined as the key derivation function (krb5_derive_key()) src/lib/crypto/combine_keys.c: if ((ret = krb5_derive_key(enc, &tkey, outkey, &input))) { src/lib/crypto/aes/aes_s2k.c: err = krb5_derive_key (enc, key, key, &usage); src/lib/crypto/libk5crypto.exports:krb5_derive_key src/lib/crypto/dk/dk_encrypt.c: if ((ret = krb5_derive_key(enc, key, &ke, &d1))) ... </pre> </div></div> With version >= 1.8.X it changed to: <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-none">thomas@lxdv65:~/tmp/krb/krb5-1.8.6>grep -r "krb5_derive_key" doc/CHANGES:Rename some lingering krb5_derive_key references. thomas@lxdv65:~/tmp/krb/krb5-1.8.6>grep -r "krb5int_derive_key" README:6629 krb5int_derive_key results in cache with uninitialized values doc/CHANGES: subject: krb5int_derive_key results in cache with uninitialized values doc/CHANGES: krb5int_derive_key creates a temporary keyblock to add to the derived cache. src/lib/crypto/crypto_tests/vectors.c: r = krb5int_derive_key (enc, in, out, usage); src/lib/crypto/krb/combine_keys.c: * DK is defined as the key derivation function (krb5int_derive_key()) src/lib/crypto/krb/combine_keys.c: ret = krb5int_derive_keyblock(enc, tkey, outkey, &input); ... </pre> </div></div> The newer distributions usually ship MIT-Kerberos => 1.8.X, however I haven't looked into Heimdal. There it is probably different. Hello, I just discovered a problem with the commit 67b73336d5b3d631e6d9eb3809914b8b80825a24: <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-none">diff --git a/lustre/utils/gss/svcgssd.c b/lustre/utils/gss/svcgssd.c index cebd852..bd6a4de 100644 --- a/lustre/utils/gss/svcgssd.c +++ b/lustre/utils/gss/svcgssd.c @@ -148,10 +148,10 @@ mydaemon(int nochdir, int noclose) static void release_parent() { - int status; + int status, rc; if (pipefds[1] > 0) { - write(pipefds[1], &status, 1); + rc = write(pipefds[1], &status, 1); close(pipefds[1]); pipefds[1] = -1; } </pre> </div></div> Since the code is compiled with gcc -Werror ... it results in: <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-none">svcgssd.c: In function ‘release_parent’: svcgssd.c:151:14: error: variable ‘rc’ set but not used [-Werror=unused-but-set-variable] cc1: all warnings being treated as errors make[1]: *** [lsvcgssd-svcgssd.o] Error 1 </pre> </div></div> Thomas, Definitely, that patch would give that error. If you look in Gerrit, that commit is patch set 4, and we're on to patch set 6. It actually appears that function is no longer being used, because we removed rc entirely and patch set 6 built successfully on all platforms. ('rc' was put there in patch set 4 to avoid a warning about ignoring a return value on write, but then hits the error you noted.) Making this a blocker for 2.5.0 until the configure/build problem is fixed for systems that do not have the gss libraries installed. Landed for 2.5.0 Blocker Related LU-3288 Development Rank 1|hzvtqf: Rank (Obsolete) 8774