Details

    • Technical task
    • Resolution: Fixed
    • Blocker
    • Lustre 2.5.0
    • Lustre 2.4.1
    • All
    • 8774

    Attachments

      Issue Links

        Activity

          [LU-3490] GSSAPI support not tested by Gerritt
          mdiep Minh Diep added a comment -

          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

          mdiep Minh Diep added a comment - 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

          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...

          paf Patrick Farrell (Inactive) added a comment - - edited 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...
          mdiep Minh Diep added a comment -

          Patrick, Ken

          Do you think 'checking for krb5int_derive_key in -lgssapi_krb5... no' must be yes to be able to build krb?

          mdiep Minh Diep added a comment - Patrick, Ken Do you think 'checking for krb5int_derive_key in -lgssapi_krb5... no' must be yes to be able to build krb?

          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.

          adilger Andreas Dilger added a comment - 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.

          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:
          http://www.mail-archive.com/linux-nfs@vger.kernel.org/msg01668.html

          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.

          paf Patrick Farrell (Inactive) added a comment - - edited 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: http://www.mail-archive.com/linux-nfs@vger.kernel.org/msg01668.html 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.

          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.

          kenh Ken Hornstein added a comment - 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.

          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.

          paf Patrick Farrell (Inactive) added a comment - 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.
          mdiep Minh Diep added a comment -

          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?

          mdiep Minh Diep added a comment - 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?

          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.

          paf Patrick Farrell (Inactive) added a comment - 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.
          mdiep Minh Diep added a comment -

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

          mdiep Minh Diep added a comment - I updated the patch and now it only failed on sles http://build.whamcloud.com/job/lustre-reviews/18238/
          mdiep Minh Diep added a comment -

          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?

          mdiep Minh Diep added a comment - 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?

          People

            mdiep Minh Diep
            ajk Andrew Korty (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            13 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: