I have made an effort to make nfs-utils work with Heimdal. Love has made an effort to support functions we need in order to get "legal" access to context information.
I have tested nfs-utils with recent release candidates of 0.8 which provides the functions mentioned above to give us "legal" access to context information which we need to pass down to the kernel. In theory, any multi-mechanism libgssapi should work. I haven't actually tried to use Heimdal's version directly. The MIT version currently does not support the use of mechanisms not built within their source tree. (Dynamically loading external mechanisms is not supported.) We need this support to use our SPKM3 mechanism. Our libgssapi can use the heimdal libgssapi as one of the mechanisms that we load. (In hindsight, perhaps we should have named our libgssapi differently.) When Heimdal 0.8 is released, nfs-utils should work with it. If not, I'll put more effort into making it work. K.C. On 2/27/07, Martin von Gagern <[EMAIL PROTECTED]> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello! I'm trying to explore how to get nfs-utils working on Gentoo with heimdal. I encountered several issues along the way. 1. setup supported? Should this in principle be possible? Do heimdal and nfs-utils in theory support each other? Or is the heimdal code in nfs-utils just for ongoing development and not (yet) expected to work? 2. libgssapi.so? nfs-utils (both 1.0.10 and 1.0.12) requires librpcsecgss [1], which in turn depends on a libgssapi. But there are two implementations of this. One libgssapi.so is installed bei heimdal [2], the other comes from the libgssapi-0.10 package from CITI [3]. Having them both installed at the same time seems to be at least not straightforward. But what's the solution? Is there some tweak to have them installed at the same time? Will libgssapi be a wrapper around the heimdal library? Or is the heimdal library instead a replacement for libgssapi? In that case it would require a pkgconfig description to allow the librpcsecgss script to find it. 3. gss_ctx_id_t? Both packages, heimdal and the CITI libgssapi, provide a gssapi.h that defines gss_ctx_id_t as a pointer. In heimdal it is a pointer to an incomplete type, in libgssapi it is a void pointer. However, the context_heimdal.c from nfs-utils dereferences pointers of this kind several times. There is a comment that says to use the gssapi.h from heimdal. And the heimdal ChangeLog says that gss_ctx_id_t_desc_struct, of which gss_ctx_id_t is a pointer, should not be exported [4]. I could find very little information on this whole subject on the net. Maybe I'm doing something completely wrong, or maybe Gentoo does something weird in a location where I haven't noticed it, but for all I know this issue should be reproducible when compiling everything from sources and simply letting configure do its stuff. I'm more toying with this package, and have no immediate need to get this working. Still I'd like to see this resolved, so I'll appreciate any help as to how this could be done. Notice that I'm writing to both heimdal and nfs lists, as I'm not sure where the problem actually lies. You might wish to have a look at the archive of the other list as well to look for replies there. Greetings, Martin von Gagern [1] http://www.citi.umich.edu/projects/nfsv4/linux/librpcsecgss/ [2] ftp://ftp.pdc.kth.se/pub/heimdal/src/ [3] http://www.citi.umich.edu/projects/nfsv4/linux/libgssapi/ [4] http://bugs.gentoo.org/show_bug.cgi?id=134064#c7 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF5L1LRhp6o4m9dFsRAi6PAJ0Y59csO/ToDyNi+Wq43lmakTTMbwCglsuG LT8/Lo9YNTGJL8FowcTgqbU= =1Idy -----END PGP SIGNATURE----- _______________________________________________ NFSv4 mailing list [EMAIL PROTECTED] http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4
