On Dec 5, 2013, at 8:23, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > [adding back Anibal, and adding Steinar as tirpc maintainer for Debian] > > On Wed, Dec 04, 2013 at 01:14:47PM -0500, Chuck Lever wrote: >> But I'm looking at tirpc/rpc/auth_gss.h. Both libraries provide roughly >> the same API. And I'm able to build a working GSS-enabled version of >> rpc.fedfsd and clients. "git log" tells me src/auth_gss.c and >> tirpc/rpc/auth_gss.h have been in libtirpc since at least 0.1.7. >> >> libtirpc applications currently have to link explicitly with >> libgssapi_krb5 (provided by MIT Kerberos), AFAICT, to get GSS support. > > >> MIT Kerberos provides libgssapi_krb5. >> >> libtirpc provides the RPCSEC APIs based on the Kerberos v5 mechanism provided in libgssapi_krb5. >> >> librpcsecgss provides RPCSEC APIs based on the GSSAPI Kerberos v5 mechanism provided in libgssglue, which is deprecated. > > So what's actually still using librpcsecgss and libgssglue? > > There is no rdepends for librpcsecgss on my Debian -stable system, > and I couldn't find any obvious user for unstable either. For > libgssglue1 -stable has a few consumers: > > nfs-common > libtirpc1 > librpcsecgss3 > libgssglue-dev > libgssapi-krb5-2 > > libgssapi-krb5-2 seems to have dropped the libgssglue dependency in > unstable, but the others still seem to be be around. I thought that Debian installs the Heimdal kerberos libraries by default. Does it have the gssapi hooks? > How does the situation look for Fedora and SuSE? Fedora’s nfs-utils RPM lists a dependency on ‘libgssapi_krb5.so.2()(64bit)' and 'libgssapi_krb5.so.2(gssapi_krb5_2_MIT)(64bit)', so it uses the gssapi from the MIT kerberos libraries. Not sure about SuSE, but I believe they use MIT kerberos too. Neil Brown would know. Cheers Trond-- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
