Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
View Bug Activity | Format For Printing | XML | Clone This Bug
Heimdal version 1.0 is out. 0.7.2 is the latest in the tree. This update is important because it adds support for NTLM, SPNEGO stuff, and PKINIT (great for smartcard users). KCM is also a nice feature. Reproducible: Always
Created an attachment (id=125369) [edit] heimdal-1.0.ebuild Ebuild, tested on x86 - note that this DOESN'T address any of the heimdal-prefix-changing stuff going on in other bugs. I agree that symlinks in /usr/include need to be altered or heimdal should be moved to a new prefix, but this ebuild works for me (although cyrus-sasl won't build against it unless you're clever with those symlinks - hint: try ln -s heimdal/gssapi gssapi and ln -s gssapi/gssapi.h gssapi.h, then link the things it complains about).
*** Bug 152460 has been marked as a duplicate of this bug. ***
Created an attachment (id=125370) [edit] heimdal-1.0-gentoo-patches-0.1.tar.bz2 Some patches were included/fixed upstream, and this adds a heimdal-kcm init script. By the way, the ebuild gets rid of the sample password checker as it's broken.
Thanks! I had some trouble switching from mit-krb5 to heimdal-1.0 using this ebuild. It seems that app-crypt/libgssapi conflict with heimdal. What I had to do was emerge -C mit-krb5 and libgssapi, emerge heimdal, then revdep-rebuild (which recompiled samba, openssh, gnome-vfs and other things). please add a !app-crypt/libgssapi to the DEPEND to specify that it conflicts. I haven't actually USED it yet :) but it compiled and seems to work except for nfs-utils which I had to set USE=-kerberos for to make even compile... Now that's not a big problem for me since I don't use nfs here but I guess it's a showstopper for many..
(In reply to comment #4) > Thanks! > > I had some trouble switching from mit-krb5 to heimdal-1.0 using this ebuild. > It seems that app-crypt/libgssapi conflict with heimdal. What I had to do was > emerge -C mit-krb5 and libgssapi, emerge heimdal, then revdep-rebuild (which > recompiled samba, openssh, gnome-vfs and other things). > > please add a !app-crypt/libgssapi to the DEPEND to specify that it conflicts. > > I haven't actually USED it yet :) but it compiled and seems to work except for > nfs-utils which I had to set USE=-kerberos for to make even compile... Now > that's not a big problem for me since I don't use nfs here but I guess it's a > showstopper for many.. > On my portage tree, nfs-utils is marked as explicitly depending on mit-krb5 and libgssapi when USE=kerberos. So unless you explicitly edited the ebuild, you shouldn't have been able to get a compile-time failure. I'll take a look at compiling nfs-utils against Heimdal 1.0; I never used kerberized NFS because I use OpenAFS instead. Thanks for the heads-up on libgssapi conflicts - Heimdal doesn't need that library as it has all its functionality and more integrated already (NTLM support, etc).
(In reply to comment #5) > On my portage tree, nfs-utils is marked as explicitly depending on mit-krb5 > and libgssapi when USE=kerberos. So unless you explicitly edited the ebuild, > you shouldn't have been able to get a compile-time failure. nfs-utils depends on mit-krb5, but libgssapi doesn't, so you can still break your system by simply emerging libgssapi for any reason like e.g. trying to compile nsf-utils manually, using other gssapi mechanisms, because of switched kerberos implementation, or whatever. > I'll take a look at compiling nfs-utils against Heimdal 1.0; I never used > kerberized NFS because I use OpenAFS instead. Cross reference: bug 134064 comment 15 and following > Thanks for the heads-up on libgssapi conflicts - Heimdal doesn't need that > library as it has all its functionality and more integrated already (NTLM > support, etc). The libgssapi conflict is not new, I reported bug 168509 for it. It has implications on nss_ldap using gssapi as well, so it's not only nfs affected. If Heimdal doesn't need this library, what does this mean for programs that currently link against the libgssapi from heimdal? Should they link against some other library from the heimdal installation, or should depend on and link against the libgssapi used for nfs?
(In reply to comment #6) I was wrong - nfs-utils does require libgssapi's libgssapi.so.2. I'm pretty sure that the functionality it uses is present in Heimdal too, but the code isn't written to make use of it. I've just thrown together a Heimdal 1.0 build that installs libs to /usr/heimdal/lib and includes to /usr/heimdal/include (as well as setting prefix to /usr so krb5-config --prefix works). I was able to build cyrus-sasl and openssh against the newly located Heimdal without trouble after adding /etc/env.d/heimdal with an extra line for /etc/ld.so.conf. It seems that nfs-utils' check for Kerberos versions is actually broken - something's wrong with aclocal/kerberos5.m4 which I couldn't figure out. But I've got a patch that hacks around it. But that doesn't solve the problem of needing to use /usr/lib/libgssapi.so.2 for nfs-utils and /usr/heimdal/lib/libgssapi.so.2 for everything else, while still letting nfs-utils make use of Heimdal's other libraries. Maybe we should compile nfs statically? Is that too extreme?
(In reply to comment #7) Oh, so the heimdal libgssapi.so changed version number from 4 to 2. That's even worse than before, where a simple change of a symlink was enough to fix many issues. http://www.mail-archive.com/heimdal-discuss@sics.se/msg00392.html seems important. It states that 1. libgssapi.so should support multiple GSSAPI mechanisms, not only Kerberos 2. app-crypt/libgssapi does so, and can link against libgssapi.so from heimdal If the libgssapi.so from heimdal-1.0 supports other methods as well, it should be possible to use that as a replacement for app-crypt/libgssapi and also link nfs-utils against it. As you say this was not possible, I assume the heimdal libgssapi.so does not provide support for other mechanisms. I would assume the best solution should be to have all applications linked against app-crypt/libgssapi and to have that use the heimdal implementation if the kerberos method of gssapi is requested. I guess in that case we'd have to make the new heimdal ebuild depend on app-crypt/libgssapi in some way, probably PDEPEND. That way there will always be a libgssapi.so available for other programs to link against. Or we could add that dependency to all ebuilds currently depending on heimdal. Of course some checks would be needed to find out whether all kerberized programs accept this version of the library, or whether some require heimdal-specific stuff.
(In reply to comment #8) > (In reply to comment #7) > > Oh, so the heimdal libgssapi.so changed version number from 4 to 2. That's even > worse than before, where a simple change of a symlink was enough to fix many > issues. > > http://www.mail-archive.com/heimdal-discuss@sics.se/msg00392.html seems > important. It states that > 1. libgssapi.so should support multiple GSSAPI mechanisms, not only Kerberos > 2. app-crypt/libgssapi does so, and can link against libgssapi.so from heimdal > > If the libgssapi.so from heimdal-1.0 supports other methods as well, it should > be possible to use that as a replacement for app-crypt/libgssapi and also link > nfs-utils against it. As you say this was not possible, I assume the heimdal > libgssapi.so does not provide support for other mechanisms. > > I would assume the best solution should be to have all applications linked > against app-crypt/libgssapi and to have that use the heimdal implementation if > the kerberos method of gssapi is requested. > > I guess in that case we'd have to make the new heimdal ebuild depend on > app-crypt/libgssapi in some way, probably PDEPEND. That way there will always > be a libgssapi.so available for other programs to link against. Or we could add > that dependency to all ebuilds currently depending on heimdal. Of course some > checks would be needed to find out whether all kerberized programs accept this > version of the library, or whether some require heimdal-specific stuff. > No, Heimdal DOES implement three mechanisms: spnego, krb5, and ntlm. libgssapi itself does nothing except call the appropriate sub-library. But nfs-utils uses symbols which are present in libgssapi and not in heimdal, precluding linking it directly against heimdal. The issue is that, having two libgssapi.so.2 libraries installer, I don't know a way to have programs linked against libssapi in /usr/lib and the rest of heimdal in /usr/heimdal/lib. /usr/lib is one of the "trusted" directories in LDPATH and so always comes after the things in ld.so.conf. Also, I'm not sure apps currently linked against Heimdal will work if libgssapi comes first in their library search path. I think the solution may be to pull libgssapi into the nfs-utils ebuild and statically link the one NFS binary that depends on it. That was nfs-utils can contain its custom gssapi stuff and there will be only one libgssapi.so.2.
Created an attachment (id=125797) [edit] heimdal-1.0.ebuild New Heimdal ebuild - harder better faster stronger.
Created an attachment (id=125799) [edit] force_inclusion_by_path.patch Makes a minor change to gssapi.h to prevent weirdness when building nfs-utils against CITI libgssapi and heimdal.
Created an attachment (id=125865) [edit] Alternative heimdal-1.0.ebuild Before finding this bug, I've successfully installed heimdal-1.0.ebuild adapted from those of Harald Barth http://www.pdc.kth.se/~haba/gentoo-stuff/portage/app-crypt/heimdal/ (see Bug #134064). It does not require so many patches -- any suggestion of tests to check my installation if it actually works?
(In reply to comment #12) Harald Barth's practice is to install heimdal into a directory separate from the main system tree. Information needed to compile all the dependend packages is provided by krb5-config script, a standard part of the heimdal distribution. If packages using kerberos do not use that script in their configure scripts, their ebuilds have to be adapted to use it. I've added the patch for the net-mail/fetchmail-6.3.8 ebuild to Bug #185652
(In reply to comment #12) Patch for gnome-extra/evolution-data-server-1.10.2 ebuild filed as Bug #186509
(In reply to comment #10) I've noticed two issues for this build, because ebuilds don't use krb5-config and thus don't find the needed kerberos headers. dev-db/postgresql-8.2.4-r1: configure: error: header file <krb5.h> is required for Kerberos 5 sys-auth/nss_ldap-254: (looks like bug 165638 but it is a different cause here) ldap-nss.c:1891: error: ‘GSS_S_COMPLETE’ undeclared (first use in this function) There are probably more ebuilds. Is there some systematic check going on or planned, or should I continue to report issues as I experience them?
(In reply to comment #15) > (In reply to comment #10) > I've noticed two issues for this build, because ebuilds don't use krb5-config > and thus don't find the needed kerberos headers. > > dev-db/postgresql-8.2.4-r1: > configure: error: header file <krb5.h> is required for Kerberos 5 > > sys-auth/nss_ldap-254: (looks like bug 165638 but it is a different cause here) > ldap-nss.c:1891: error: ‘GSS_S_COMPLETE’ undeclared (first use in this > function) > > There are probably more ebuilds. Is there some systematic check going on or > planned, or should I continue to report issues as I experience them? > vapier feels strongly that pkg-config is superior to krb5-config (and I agree with him). Heimdal is moving to pkg-config. I fixed nss_ldap on my end by adding --with-gssapi-dir=foo.
Created an attachment (id=126059) [edit] heimdal-1.0-1.0.1_rc1.ebuild.diff Basically the heimdal-1.0.ebuild by Bryan Jacobs (needs renaming the tar.bz2 patchset from 1.0 version to 1.0.1_rc1). Several commented out lines removed. Hacky simlinks for SASL checks commented out in favor of changing of problematic ebuilds to use krb5-config. Install dirs manipulated to avoid, hopefully, clashes with other packages like app-crypt/libgssapi (in case having the GSSAPI wrapper library around proves to be useful). Creation of .pc files for pkg-config attempted, but all the packages using hardcoded kerberos path will have to be modified anyway.
(In reply to comment #16) I've started modifying all the ebuilds I install to use krb5-config and reporting appropriate bugs for such changes. Of course it's far from a systematic check of the whole portage tree. I just try installing what I want, and if it fails complaining about some kerberos header or library not found, I try to introduce krb5-config into its configuration. At the Bug #185509 I've been scolded heavily for using krb5-config, which is inferior to pkg-config. That's why I've tried to modify the heimdal ebuild to create .pc files for pkg-config; but now I'm not sure not only of their correctness, but even less of the proper way to introduce pkg-config usage into the dependent ebuilds.
(In reply to comment #18) > At the Bug #185509 Not Bug #185509, but Bug #186509 -- excuse, please, my typo.
Created an attachment (id=126114) [edit] heimdal-1.0-0.8.1-r1.ebuild.diff Bryan Jacobs' 1.0 ebuild changed to install into /usr/heimdal. bin and sbin directories contents symlinked into the system /usr/bin and /usr/sbin; name changes (telnet->ktelnet etc.) done only to the symlinks (in case some package looks for the binaries inside the heimdal subtree under the original names). Creation of .pc files for pkg-config attempted. The patchset slightly modified for 0.8.1: 010_all_heimdal-system-libss.patch adapted to the elder lib/sl/Makefile.am and inside 012_all_heimdal-berkdb.patch changed the location of ndbm_wrap.c to the elder path lib/otp/ndbm_wrap.c. Otherwise the ebuild applies to newer heimdal versions as well; release candidates require HOMEPAGE="http://www.pdc.kth.se/heimdal/" -SRC_URI="ftp://ftp.pdc.kth.se/pub/heimdal/src/${P/_rc/rc}.tar.gz +SRC_URI="ftp://ftp.pdc.kth.se/pub/heimdal/src/snapshots/${P/_rc/rc}.tar.gz http://dev.gentoo.org/~seemant/distfiles/${PATCH_P}.tar.bz2 The _rc to rc change in the release version is an artefact I've been too lazy to edit out. From 0.9 series of release candidates, Bryan Jacobs' patchset seems to be applicable without modification. With 0.8.1 release in a separate installation directory I have easily installed app-crypt/libgssapi, net-libs/librpcsecgss and net-fs/nfs-utils, having just changed the net-fs/nfs-utils dependency from app-crypt/mit-krb5 to virtual/krb5. With newer versions of heimdal I've run into problems installing net-fs/nfs-utils. For now I've tried several heimdal versions and found one that works with nfs-utils without further work. As soon as I feel like playing with that again I'm going to submit a detailed report of my compilation problems as well as anything I eventually find; since the nfs-utils developers seem to support heimdal, chances are that my problems either are results of my wrong setup or will go off in the next nfs-utils version.
Created an attachment (id=126115) [edit] heimdal-0.8.1-gentoo-patches-0.1.tar.bz2
(In reply to comment #20) > > With 0.8.1 release in a separate installation directory I have easily installed > app-crypt/libgssapi, net-libs/librpcsecgss and net-fs/nfs-utils, having just > changed the net-fs/nfs-utils dependency from app-crypt/mit-krb5 to > virtual/krb5. With newer versions of heimdal I've run into problems installing > net-fs/nfs-utils. For now I've tried several heimdal versions and found one > that works with nfs-utils without further work. As soon as I feel like playing > with that again I'm going to submit a detailed report of my compilation > problems as well as anything I eventually find; since the nfs-utils developers > seem to support heimdal, chances are that my problems either are results of my > wrong setup or will go off in the next nfs-utils version. > Even if you manage to compile nfs-utils with Heimdal 1.0 installed, you will not be able to run rpc.gssd nor rpc.svcgssd. libgssapi and Heimdal 1.0 by default install "libgssapi.so.2". You must change the library version of one or the other in order for the dynamic linker to function properly with both in the LDPATH (as they both must be for nfs-utils).
(In reply to comment #22) > Even if you manage to compile nfs-utils with Heimdal 1.0 installed, you will > not be able to run rpc.gssd nor rpc.svcgssd. Verified :-( Switched to the newest Heimdal (1.0.1_rc1) again, removed app-crypt/libgssapi. Instead of modifying net-libs/librpcsecgss acording to Bug #186392 libgssapi.pc created by heimdal ebuild: changing the dependencies of librpcsecgss ebuild was enough then. net-fs/nfs-utils ebuild modified to use your patch from the Bug #134064 (more discussion there). Everything compiled well, but rpc.svcgssd still does not start (and does not say why). May be I would need some specific kernel configuration, or even kernel patch? (Not that I actually need kerberised NFS running.)
Created an attachment (id=126185) [edit] heimdal-1.0-1.0.1_rc1.ebuild.diff Patch to Bryan Jacobs' 1.0 ebuild to install the current release candidate, use a separate installation directory and create .pc files for pkg-config (mainly libgssapi.pc used by net-libs/librpcsecgss). Uses Bryan Jacobs' patchset, just renamed to reflect the version.
(In reply to comment #23) > net-fs/nfs-utils ebuild modified to use your patch from the Bug #134064 (more > discussion there). Everything compiled well, but rpc.svcgssd still does not > start (and does not say why). May be I would need some specific kernel > configuration, or even kernel patch? (Not that I actually need kerberised NFS > running.) > In order to use Kerberized NFS, you must have rpcsec_gss support in the kernel (modprobe appropriate stuff if necessary). This means you need to enable NFSv4 server support and the krb5 mechanism in your kernel config. Try to run rpc.gssd or rpc.svcgssd with the -f -vvv options. Check syslogs too. They'll complain about missing stuff in /proc or /var if you don't have appropriate modules loaded or the nfs filesystem mounted.
Created an attachment (id=128519) [edit] app-crypt/heimdal/heimdal-1.0.1.ebuild Symlinks fixup.
Created an attachment (id=128521) [edit] app-crypt/heimdal/files/1.0.1/001_all_heimdal-no_libedit.patch
Created an attachment (id=128523) [edit] app-crypt/heimdal/files/1.0.1/002_all_heimal-fPIC.patch
Created an attachment (id=128524) [edit] app-crypt/heimdal/files/1.0.1/003_all_heimdal-rxapps.patch
Created an attachment (id=128526) [edit] app-crypt/heimdal/files/1.0.1/005_all_heimdal-suid_fix.patch
Created an attachment (id=128528) [edit] app-crypt/heimdal/files/1.0.1/010_all_heimdal-system-libss.patch
Created an attachment (id=128529) [edit] app-crypt/heimdal/files/1.0.1/012_all_heimdal-berkdb.patch
Created an attachment (id=128531) [edit] app-crypt/heimdal/files/1.0.1/013_all_heimdal-pthread-lib.patch
Created an attachment (id=128533) [edit] app-crypt/heimdal/files/1.0.1/014_all_heimdal-path.patch
Created an attachment (id=128534) [edit] app-crypt/heimdal/files/1.0.1/015_all_heimdal-fixit.patch
Created an attachment (id=128536) [edit] app-crypt/heimdal/files/1.0.1/100_all_force_inclusion_by_path.patch
Created an attachment (id=128537) [edit] app-crypt/heimdal/files/configs/heimdal-kadmind
Created an attachment (id=128539) [edit] app-crypt/heimdal/files/configs/heimdal-kcm
Created an attachment (id=128540) [edit] app-crypt/heimdal/files/configs/heimdal-kdc
Created an attachment (id=128541) [edit] app-crypt/heimdal/files/configs/heimdal-kpasswdd
Created an attachment (id=128543) [edit] app-crypt/heimdal/files/configs/krb5.conf
Created an attachment (id=128544) [edit] app-crypt/heimdal/files/configs/krb5-kdc.schema
Thanks a lot, your ebuild worked for me. Where did the heimdal maintainer go? The last ebuild in the tree is extremely old...
Created an attachment (id=131346) [edit] heimdal-1.0.1-r1.ebuild Dmitry S. Kulyabov's 1.0.1 ebuild had built well for me, but then I ran into problems with dependent packages. Unfortunately I didn't report the problem immediately neither made notes, and by now I've forgotten which ebuild crashed then during compilation and what was the error report. In case nobody else obtains such information I'll have to find time for further experiments and reproduce the error once again. For now, I use this ebuild, heavily based on Bryan Jacobs's work (my few additions, derived mostly from Harald Barth's work, actually converging further to Bryan Jacobs's 1.0 ebuild). It uses Bryan Jacobs's 1.0 patchset, just renamed to heimdal-1.0.1-gentoo-patches-0.1.tar.bz2 Until now it seems to work for me -- that is everything I've tried to upgrade or recompile has built well. (I guess that unmodified Bryan Jacobs's 1.0 ebuild, just renamed to 1.0.1, would work as well.) Unfortunately I don't understand programming much and kerberos at all, so I'm unable to actually compare Bryan Jacobs's and Dmitry S. Kulyabov's works, not to speak of combining the best of both worlds into something ready to push into the portage tree (which needs upgrade desperately).
Yeah look, we need heimdal maintainers. There are none. I used to maintain this, but I have no boxes with it on anymore, nor do I have the knowledge. And, I'm retiring soon, anyway. So, if someone would like to step up, I'll happily mentor that person before my depar