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 attachment 125369 [details] 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 attachment 125370 [details] 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 attachment 125797 [details] heimdal-1.0.ebuild New Heimdal ebuild - harder better faster stronger.
Created attachment 125799 [details, diff] 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 attachment 125865 [details] 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 attachment 126059 [details, diff] 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 attachment 126114 [details, diff] 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 attachment 126115 [details] 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 attachment 126185 [details, diff] 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 attachment 128519 [details] app-crypt/heimdal/heimdal-1.0.1.ebuild Symlinks fixup.
Created attachment 128521 [details, diff] app-crypt/heimdal/files/1.0.1/001_all_heimdal-no_libedit.patch
Created attachment 128523 [details, diff] app-crypt/heimdal/files/1.0.1/002_all_heimal-fPIC.patch
Created attachment 128524 [details, diff] app-crypt/heimdal/files/1.0.1/003_all_heimdal-rxapps.patch
Created attachment 128526 [details, diff] app-crypt/heimdal/files/1.0.1/005_all_heimdal-suid_fix.patch
Created attachment 128528 [details, diff] app-crypt/heimdal/files/1.0.1/010_all_heimdal-system-libss.patch
Created attachment 128529 [details, diff] app-crypt/heimdal/files/1.0.1/012_all_heimdal-berkdb.patch
Created attachment 128531 [details, diff] app-crypt/heimdal/files/1.0.1/013_all_heimdal-pthread-lib.patch
Created attachment 128533 [details, diff] app-crypt/heimdal/files/1.0.1/014_all_heimdal-path.patch
Created attachment 128534 [details, diff] app-crypt/heimdal/files/1.0.1/015_all_heimdal-fixit.patch
Created attachment 128536 [details, diff] app-crypt/heimdal/files/1.0.1/100_all_force_inclusion_by_path.patch
Created attachment 128537 [details] app-crypt/heimdal/files/configs/heimdal-kadmind
Created attachment 128539 [details] app-crypt/heimdal/files/configs/heimdal-kcm
Created attachment 128540 [details] app-crypt/heimdal/files/configs/heimdal-kdc
Created attachment 128541 [details] app-crypt/heimdal/files/configs/heimdal-kpasswdd
Created attachment 128543 [details] app-crypt/heimdal/files/configs/krb5.conf
Created attachment 128544 [details] 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 attachment 131346 [details] 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 departure. Email me off-bug.
Created attachment 135345 [details, diff] patch for -Wl,--as-needed To add my two cent: one more patch is needed to build it with -Wl,--as-needed. I tried to build it without inclusion-by-path patch. Everything that I had what depended on libgssapi seemed to rebuild OK, however I may simply lack does packages that would brake. I have following packages installed: net-libs/libgsasl-0.2.10 dev-libs/cyrus-sasl-2.1.22-r2 dev-util/cvs-1.12.12-r4 net-misc/openssh-4.7_p1-r1 dev-lang/php-5.2.4_p20070914-r2 gnome-base/gnome-vfs-2.20.0 dev-perl/GSSAPI-0.24 net-analyzer/net-snmp-5.4 net-mail/dovecot-1.0.7 net-mail/fetchmail-6.3.8-r1 net-fs/samba-3.0.26a samba is yet to be rebuilt but the rest seemed fine. fetchmail builds with heimdal after applying a little patch I dropped into bugzilla awhile ago.
Created attachment 138341 [details, diff] Patch for cyrus-sasl to compile against heimdal tested against heimdal-1.0.1
Created attachment 138343 [details, diff] php4_4-sapi.eclass patch to compile against heimdal-1.0.1 php ebuild is correct you have to patch some eclass, namely php4_4-sapi.eclass php5_0-sapi.eclass php5_1-sapi.eclass php5_2-sapi.eclass patch will follow.
Created attachment 138344 [details] php5_0-sapi.eclass patch to compile against heimdal-1.0.1
Created attachment 138345 [details, diff] php5_1-sapi.eclass patch to compile against heimdal-1.0.1
Created attachment 138347 [details, diff] php5_2-sapi.eclass patch to compile against heimdal-1.0.1
Created attachment 138349 [details, diff] patch for postgresql library to compile against heimdal 1.0.1
Created attachment 138350 [details, diff] patch for postgresql to compile against heimdal 1.0.1
Created attachment 138352 [details] patch for dovecot to compile against heimdal 1.0.1 should work with dovecot-1.0.5 not tested
Created attachment 138354 [details, diff] patch for openldap to compile against heimdal 1.0.1 should be also ok for openldap-2.3.38.ebuild not tested
Created attachment 138355 [details] New ebuild for pam_krb5 which work with heimdal 1.0.1 don't know if this implementation work with MIT-Kerberos
Created attachment 138356 [details] New ebuild for Apache Module mod_auth_kerb which work with heimdal 1.0.1 don't know if this works with MIT-Kerberos implementation
(In reply to comment #56) > New ebuild for pam_krb5 which work with heimdal 1.0.1 As the revbump request from bug 163840 seems to be in portage now, we have a pam_krb5-3.9 in portage which is more recent than this version 3.5 you propose here. Some of the things in your ebuild seem a bit more elaborate than what the 3.9 ebuild currently in portage does. If you have special reasons for some of this, you might want to comment on bug 163840, but I see no need to have this ebuild discussed here, as it is not immediately related to heimdal 1.
Comment on attachment 138355 [details] New ebuild for pam_krb5 which work with heimdal 1.0.1 see comment 58 and use the described Version there
Created attachment 142119 [details] heimdal-1.1-gentoo-patches-0.1.tar.bz2 The patchset as used by Bryan Jacobs, slightly adapted to the version 1.1
Created attachment 142121 [details] app-crypt/heimdal-1.1.ebuild Ebuild for heimdal 1.1. Once again back to Bryan Jacobs's work. I've taken back all my former tweaks as messy, including my attempt on pkg-config files for heimdal -- the current heimdal uses pkg-config on itself, at least for heimdal-gssapi. Compared to the original heimdal-1.0.ebuild by Bryan Jacobs, several commented out lines are deleted and the web address of heimdal is updated to the current www.h5l.org. I've also reduced the keywords to just "~x86 ~amd64" since I compile just on these two architectures and know nothing of any other.
Created attachment 142122 [details, diff] heimdal-1.0-1.1.ebuild.diff Diff from app-crypt/heimdal-1.0.ebuild to app-crypt/heimdal-1.1.ebuild
Created attachment 142123 [details, diff] gentoo-patches-heimdal-1.0-1.1.diff Diff from uncompressed heimdal-1.0-gentoo-patches-0.1.tar.bz2 to uncompressed heimdal-1.1-gentoo-patches-0.1.tar.bz2
I have troubles without symlinks in the includes directory. Some packages (openldap, cyrus-sasl, ...) won't compile without it.
(In reply to comment #64) > I have troubles without symlinks in the includes directory. Some packages > (openldap, cyrus-sasl, ...) won't compile without it. Mea culpa. Removing all the useless changes I've made to the ebuild by Bryan Jacobs, I've accidentally returned in place the request to install the headers into /usr/include/heimdal. Bryan Jacobs incorporated that configuration option to accommodate heimdal alongside app-crypt/libgssapi for net-fs/nfsutils (refer to the discussion above). Not only he afterwards succeeded in patching net-fs/nfsutils to compile against heimdal without libgssapi, but by now even app-crypt/libgssapi has ceased from the portage tree. Thus no exotic place for heimdal headers is needed anymore. With headers under /usr/include/heimdal, either symlinks or patches for configuration of various packages would be needed. I'm not sure why I haven't realized the problem before myself. Corrected ebuild follows.
Created attachment 147692 [details] heimdal-1.1.ebuild Corrected version of heimdal-1.1.ebuild, not installing headers into any place exotic.
Created attachment 147693 [details, diff] heimdal-1.0-1.1.ebuild.diff Diff version of the above.
(In reply to comment #66) > Created an attachment (id=147692) [edit] > heimdal-1.1.ebuild I've just tried to compile heimdal-1.1.ebuild with USE="ldap kerberos" in /etc/make.conf. Because of the DEPEND of heimdal on openldap and openldap on kerberos we do have a circular dependency. Both dependencies do have an eligibility. I am using mit-krb5 (which can also use ldap as backend) which does not have a ldap USE nor dependency. IMHO it's neither advisable nor common to use ldap as backend for kerberos, so my suggestion would be to disable the ldap support in heimdal, as I am not a heimdal specialist I do not know what the exact impact of this action would be. Discussion start ....
(In reply to comment #68) > (In reply to comment #66) > > Created an attachment (id=147692) [edit] > > heimdal-1.1.ebuild > > I've just tried to compile heimdal-1.1.ebuild with USE="ldap kerberos" in > /etc/make.conf. Because of the DEPEND of heimdal on openldap and openldap on > kerberos we do have a circular dependency. Both dependencies do have an > eligibility. I am using mit-krb5 (which can also use ldap as backend) which > does not have a ldap USE nor dependency. IMHO it's neither advisable nor common > to use ldap as backend for kerberos, so my suggestion would be to disable the > ldap support in heimdal, as I am not a heimdal specialist I do not know what > the exact impact of this action would be. Discussion start .... > As an example of using LDAP as a Kerberos backend, look to every single Windows 2003 domain in existence. Or, alternately, Samba 4. This support is necessary. Don't disable it. If you want to break the dependency cycle, just compile either LDAP w/o Kerberos support, or Kerberos w/o LDAP support, build the second package, and then rebuild the first with the USE flags you like. How does MIT kerberos has support for using LDAP as a database without depending on LDAP libraries? Does it have internal copies?
(In reply to comment #69) > This support is necessary. Don't disable it. If you want to break the > dependency cycle, just compile either LDAP w/o Kerberos support, or Kerberos > w/o LDAP support, build the second package, and then rebuild the first with the > USE flags you like. ACK - resolving the problem is not the problem. But a global USE situation as described above is not unusual and it would be nice to have a situation where no special user interaction is required. Of course ... here the answer is not easy to find. > How does MIT kerberos has support for using LDAP as a database without > depending on LDAP libraries? Does it have internal copies? It simply doesn't have support for it in gentoo ... of course it's not possible to compile kerberos without ldap headers and run it without the libraries. I know the examples of using LDAP as backend - the question is if you would build a linux configuration like that? AFAIK ldap in kerberos means really to store the principals in a ldap database. That does not mean that you aren't able to use ldap for libnss and all the other tasks. Remark: cite from the heimdal HP: "Note that before attempting to configure such an installation, you should be aware of the implications of storing private information (such as users' keys) in a directory service primarily designed for public information." g, mueli
(In reply to comment #70) > But a global USE situation as > described above is not unusual and it would be nice to have a situation where > no special user interaction is required. Then you should probably file a portage enhancement bug to solve circular dependencies automatically. No more USE="-doc -X -java" and other manual adjustments when installing on a new machine would be nice, but rather that then having unconditionally disabled features that are supported upstream. After all, isn't Gentoo about choice in the first place? For ease of installation, there is (at least) Ubuntu, for choices made by others, there is Windows. (Well, please, excuse if I'm being rude. I'm just upgrading, and solving problems with packages being mutually exclusive or hardmasked. Some choices to make, some problems to solve manually, and, unfortunately, likely some choices made by others to undo too.) BTW, there just was some discussion of LDAP support in heimdal going at heimdal-discuss@sics.se -- see http://list.sics.se/sympa/arc/heimdal-discuss/2008-04/msg00002.html and related mails.
(In reply to comment #71) > Then you should probably file a portage enhancement bug to solve circular > dependencies automatically. How should that work? You can't simply resolve circular dependencies as it is the character of a circle not having an end or a beginning - so where do you want to break the circle? You have to decide it manually. > After all, isn't Gentoo about choice in the first place? For ease of > installation, there is (at least) Ubuntu, for choices made by others, there is > Windows. ACK - But despite free choice we also want to deliver a usable (meta)distribution which can be used in a (more or less) "automatic" way without to much user interaction. Therefore I would support a feature restriction to provide a more homogeneous system at all. At least we should find an acceptable solution before adding heimdal-1.1 to the tree - IMHO it's not acceptable to add an ebuild with known circular dependencies. g, mueli
as a suggestion: why not preparing everything in the heimdal ebuild for ldap deps, then comment it out and elog in pkg_setup that the user has to copy that ebuild to a local overlay and re-enable it if he really wants it?
(In reply to comment #71) > > Then you should probably file a portage enhancement bug to solve circular > > dependencies automatically. > > How should that work? ... You have to decide it manually. Well, I don't think what I do manually is much creative or based on inttuitive in-depth knowledge. I am quite sure it could be formalised into an algorithm and programmed -- if it were worth the effort. But this discussion is heading quite off-topic. > ... Therefore I would support a feature > restriction to provide a more homogeneous system at all. Not only I am of different opinion, I even think Gentoo already has a better solution. In package.use under /usr/portage/profiles default use flags for individual packages on various architectures can be and are specified. (I personally like also the fact that after reading about them in portage.5 manpage I had to use find to actually see an example -- the default package.use files exist for a handful of architectures only and are quite short, the feature being used sporadically and with caution.) > At least we should > find an acceptable solution before adding heimdal-1.1 to the tree - IMHO it's > not acceptable to add an ebuild with known circular dependencies. Like media-libs/libsdl and media-libs/DirectFB? In fact what heimdal-1.x needs to get into the portage tree is an ebuild maintainer. I personally don't feel being the right person for the lack of time, skill, competence etc. -- see comments #63 through #65 for just one example of my faults. So I maintain the package in my local portage overlay using the work of others as much as possible, struggle with such annoyances as Bug #215558, have subscribed several heimdal mailing lists, and hope someone more competent takes over this package before I feel necessary to do it myself anyway.
(In reply to comment #74) > Well, I don't think what I do manually is much creative [...] ... creative enough ;) If you implement such an algorithm to "automatically" brake circular dependencies it really has to work on _all_ situations ... not only on the ones you know ;) > [...] In package.use under /usr/portage/profiles default use flags for > individual packages on various architectures can be and are specified. It would be possible to define a portage.use.mask entry for heimdal. Haven't thought about that. Don't know how easy it is to do so ... @jokey: Does the council decide about such a mask file? If we do so, it has to be in the root profile or at least in the default-linux profile - that's a rather huge thing I would say. On the other hand it would (as far as I can see) only affect heimdal and no other projects. > In fact what heimdal-1.x needs to get into the portage tree is an ebuild > maintainer. Of course - as far as I can say we are already working on that ;) > [...] struggle with such annoyances as > Bug #215558, have subscribed several heimdal mailing lists, and hope someone > more competent takes over this package before I feel necessary to do it myself > anyway. We are going to solve the issue - be more confident. Of course that's a problem we have to solve too before adding heimdal to portage. Except committing you are already helping to maintain the ebuild by committing your experience and helping to stabilize it. There is always work in progress ... software is never finished.
ebuild maintainers decide on use.mask'ing something though might be actually an option here
heimdal-1.1 ebuild does not compile here on x86_64
(In reply to comment #77) > heimdal-1.1 ebuild does not compile here on x86_64 I have it compiled on my amd64 box, so the architecture itself will not be the cause. Which part of compilation fails? Is there any helpful information in the error messages? And, of course, what is your configuration? BTW: One wild guess of the ``Have you plugged it in?'' type -- have you downloaded heimdal-1.1-gentoo-patches-0.1.tar.bz2 and put it into your /usr/portage/distfiles/ directory?
(In reply to comment #78) > BTW: One wild guess of the ``Have you plugged it in?'' type -- have you > downloaded heimdal-1.1-gentoo-patches-0.1.tar.bz2 and put it into your > /usr/portage/distfiles/ directory? Yes. With gcc-4.3.0 =================================================== removing executable bit: usr/lib64/windc.la ^G ^[[33;01m*^[[0m QA Notice: Package has poor programming practices which may compile ^[[33;01m*^[[0m fine but exhibit random runtime failures. ^[[33;01m*^[[0m hdb-ldap.c:313: warning: implicit declaration of function ‘ldap_get_values’ hdb-ldap.c:325: warning: implicit declaration of function ‘ldap_value_free’ hdb-ldap.c:403: warning: implicit declaration of function ‘ldap_count_values’ hdb-ldap.c:740: warning: implicit declaration of function ‘ldap_search_s’ hdb-ldap.c:1358: warning: implicit declaration of function ‘ldap_abandon’ hdb-ldap.c:1405: warning: implicit declaration of function ‘ldap_search’ hdb-ldap.c:1580: warning: implicit declaration of function ‘ldap_add_s’ hdb-ldap.c:1584: warning: implicit declaration of function ‘ldap_modify_s’ hdb-ldap.c:1644: warning: implicit declaration of function ‘ldap_delete_s’ ^G ^G ^[[33;01m*^[[0m QA Notice: Package has poor programming practices which may compile ^[[33;01m*^[[0m but will almost certainly crash on 64bit architectures. ^[[33;01m*^[[0m Function `ldap_get_values' implicitly converted to pointer at hdb-ldap.c:313 ^G ^[[31;01m*^[[0m ^[[31;01m*^[[0m ERROR: app-crypt/heimdal-1.1 failed. ^[[31;01m*^[[0m Call stack: ^[[31;01m*^[[0m misc-functions.sh, line 621: Called install_qa_check ^[[31;01m*^[[0m misc-functions.sh, line 317: Called die ^[[31;01m*^[[0m The specific snippet of code: ^[[31;01m*^[[0m alpha*|ia64*|powerpc64*|mips64*|sparc64*|x86_64*) die "this code is not 64bit clean";; ^[[31;01m*^[[0m The die message: ^[[31;01m*^[[0m this code is not 64bit clean =================================================== With gcc-4.2.3 =================================================== creating libroken.la (cd .libs && rm -f libroken.la && ln -s ../libroken.la libroken.la) /bin/sh ../../libtool --mode=link x86_64-pc-linux-gnu-gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wbad-function-cast -Wmissing-declarations -Wnested-externs -march=native -O2 -fomit-frame-pointer -pipe -Wl,--as-needed -o snprintf-test snprintf_test-snprintf-test.o libtest.la libroken.la -lcrypt -lresolv -lpthread /bin/sh ../../libtool --mode=link x86_64-pc-linux-gnu-gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wbad-function-cast -Wmissing-declarations -Wnested-externs -march=native -O2 -fomit-frame-pointer -pipe -Wl,--as-needed -o resolve-test resolve-test.o libroken.la -lcrypt -lresolv -lpthread x86_64-pc-linux-gnu-gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wbad-function-cast -Wmissing-declarations -Wnested-externs -march=native -O2 -fomit-frame-pointer -pipe -Wl,--as-needed -o .libs/resolve-test resolve-test.o ./.libs/libroken.so -lcrypt -lresolv -lpthread ./.libs/libroken.so: undefined reference to `crypt' ===================================================
(In reply to comment #79) I've recompiled my heimdal-1.1 with gcc-4.2.3 (and sys-libs/glibc-2.7-r2 and sys-apps/portage-2.1.4.4), having USE="X berkdb ipv6 ldap ssl",successfully. Your gcc-4.2.3 case looks queer -- perhaps unmerging the installed version of heimdal (if you have one) to prevent accidental linking to some installed old library instead of a freshly compiled code might help. Or re-emerging of glibc (which libcrypt belongs to) with the same gcc version. Nevertheless it might not help you in the end. I haven't yet upgraded to gcc-4.3 -- and perhaps to other versions of various other packages that are similarly fresh. Probably portage is the important one. Your error report looks to me like you have actually compiled heimdal-1.1 successfully, but your emerge, unlike mine, not only reported ``poor programming practices'' which may ``almost certainly crash on 64bit systems'', but so certain it was of that crash that to prevent you from crashing your system it committed seppuku. Probably a patch to the reported poor programming practices (and a message upstream) will solve this best. If you cannot wait for the patch neither write it yourself, you may try compiling with USE='-ldap'. If it does not help or if you want heimdal with ldap support, and if you think that your emerge is too clever and overprotective, you might downgrade portage (and file a bug for portage). As soon as I feel having enough time I'll try patching.
(In reply to comment #80) > (In reply to comment #79) > I've recompiled my heimdal-1.1 with gcc-4.2.3 (and sys-libs/glibc-2.7-r2 and <snip> > As soon as I feel having enough time I'll try patching. No rush. I just wanted to experiment with kerberos and it seems the heimdal package is quite highly regarded. I did get installed on my x86 box but it was turning into a bit of a pain due to the other ebuilds depending upon mit instead of a virtual/kerberos, so for now looking at the mit version. Would be nice to see this package in portage and maintained with a supporting virtuals package. Thanks again.
Never put off till tomorrow what has been done by others since the day before yesterday :-) The QA issues, especially the 64-bit critical one, have been discovered and dealt with in Debian, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463410 The heimdal svn trunk deals with the problems http://loka.it.su.se/fisheye/browse/heimdal/trunk/heimdal/lib/hdb/hdb-ldap.c?r1=22586&r2=22588 I've applied a corresponding patch to heimdal-1.1 -- a few of the QA warning last, but at least the critical one is gone: * QA Notice: Package has poor programming practices which may compile * fine but exhibit random runtime failures. * hdb-ldap.c:749: warning: implicit declaration of function ‘ldap_search_s’ hdb-ldap.c:1369: warning: implicit declaration of function ‘ldap_abandon’ hdb-ldap.c:1416: warning: implicit declaration of function ‘ldap_search’ hdb-ldap.c:1591: warning: implicit declaration of function ‘ldap_add_s’ hdb-ldap.c:1595: warning: implicit declaration of function ‘ldap_modify_s’ hdb-ldap.c:1655: warning: implicit declaration of function ‘ldap_delete_s’ According to http://en.opensuse.org/OpenLDAP_2.3_libldap_upgrade_howto there is then still some work for tomorrow, but for now that hopefully can be put off. The ebuild and patch follow.
Created attachment 149248 [details] heimdal-1.1-r1.ebuild The ebuild for heimdal-1.1 applying the new patch.
Created attachment 149249 [details, diff] heimdal-1.1-ldapQA.patch The patch for the QA issues with hdb-ldap (due to new libldap API).
Created attachment 149519 [details] heimdal-1.1-r2.ebuild New heimdal-1.1 ebuild with all the LDAP related QA warnings removed. Now if only there were somebody able to test if the LDAP support actually works.
Created attachment 149521 [details, diff] heimdal-1.1-ldapQAplus.patch The heimdal-1.1 QA warnings patch, episode 2. Kept apart from the episode 1 to distinguish what is just upgraded to the current SVN trunk version, and what has been tweaked by me.
Created attachment 150352 [details] heimdal-1.2_rc1-gentoo-patches-0.1.tar.bz2 Patches collection for heimdal-1.2_rc1. The patch to update obsolete openldap API calls is included.
Created attachment 150353 [details] heimdal-1.2_rc1.ebuild Ebuild for testing the 1.2 release candidate 1. Depends on >=sys-devel/autoconf-2.62 and >=sys-devel/libtool-2.2 -- autoconf-2.61, pulled in by "WANT_AUTOCONF=latest", is not enough, and =sys-devel/libtool-2.2* must be package-unmasked (see bug #212763). If you wish to compile with <=sys-devel/libtool-1.5.26, try commenting out the dependency and uncommenting the sed-ECHO-libtool hack: Old sys-devel/libtool seems to create a libtool script that defines ECHO and uses $echo, downcasing the definition apparently makes the package compile well. There are new QA Notices, I haven't tried to solve them yet: * QA Notice: Package has poor programming practices which may compile * fine but exhibit random runtime failures. * stringprep.c:102: warning: implicit declaration of function ‘memcpy’ sel-lex.l:90: warning: implicit declaration of function ‘vasprintf’ * QA Notice: Package has poor programming practices which may compile * fine but exhibit random runtime failures. * stringprep.c:102: warning: incompatible implicit declaration of built-in function ‘memcpy’
Created attachment 151392 [details] heimdal-1.2_rc2.ebuild Next step upstream towards 1.2 release. heimdal-1.2_rc1-gentoo-patches-0.1.tar.bz2 is to be renamed or copied to heimdal-1.2_rc2-gentoo-patches-0.1.tar.bz2. Compiles on x86 and amd64 for me, only ``sel-lex.l:94: warning: implicit declaration of function ‘vasprintf’'' reported now. The ebuild uses sed -e's/ECHO/echo/' hack to build with <libtool-2.2 and avoid problems of other packages with >=libtool-2.2. Everything seems to compile against heimdal-1.2 release candidates except nfs-utils where the headers of gssglue get in the way of the ones of heimdal (/usr/include/gssglue/gssapi/gssapi.h takes precedence over /usr/include/gssapi/gssapi.h).
Looking at the ever growing list of attachments here, I would assume it would make sense to start a public overlay for them, so that heimdal-1* can get some more testing from users enabling this overlay via layman, without first reading all the comments here to know which files are needed and where each one should go. This public overlay should of course not be a substitute for heimdal-1 entering the main portage tree as soon as it's stable enough. I don't know who would be responsible for setting up and maintaining such an overlay. http://www.gentoo.org/proj/en/metastructure/herds/herds.xml#doc_chap59 looks like the kerberos herd, to which this bug here is assigned, is empty. Are there any Gentoo devs working on kerberos without being part of that herd? Or any willing to provide infrastructure so that contributors like the ones originating above attachments can help out?
ACK - an overlay for testing would be a great idea. So we can centralize the great work of you all and provide a way for better testing. There is an ongoing effort to establish a working dev herd again. We've made some kind of fire brigade for the MIT implementation (thx jokey). The reason therefore is the explicit dependency of some code on MIT kerberos. A few issues are solved or can be solved in a simple way but there is still a long way to go to have a virtual/kerberos where you're really able to switch between heimdal and MIT and IMHO that _must_ be the aim! g, mueli
I'm willing to do the dev-side part for you such as (re)forming that herd, creating the herd overlay and keeping an eye on what's going on with these bugs here, ping back if you feel like contributing more and making this worth it :) Though good work so far already :)
Thx for the offer jokey! Of course it's worth making an overlay and reactivating the kerberos herd. As already discussed, there is no active maintaining of kerberos in gentoo apart from the work you (and a bit me) did in the past weeks. I would be glad to inherit a great part of your dev work in this herd in near future ... ;) g, mueli
Created attachment 151695 [details, diff] librpcsecgss-0.18-config_in.patch Some more material for the overlay. Might go better to the bug #134064 weren't that one shut down as NEEDINFO until heimdal-1.x gets into the portage tree. This patch makes librpcsecgss test for heimdal-gssapi as an alternative to libgssglue and compile against heimdal instead of net-libs/libgssglue. Needed for net-fs/nfs-utils. The diff to modify the librpcsecgss ebuild follows.
Created attachment 151696 [details, diff] librpcsecgss-0.18.ebuild-heimdal.diff Diff for net-libs/librpcsecgss-0.18.ebuild to apply the patch for accepting heimdal-gssapi as an alternative to libgssglue.
Created attachment 151698 [details, diff] nfs-utils-1.1.2-pkgconfig_ac.patch A patch for net-fs/nfsutils-1.1.2 to use pkg-config properly and accept heimdal-gssapi as an alternative to libgssglue. One more patch and the diff for the ebuild follow.
Created attachment 151699 [details, diff] nfs-utils-1.1.2-no_libgssapi.patch Bryan Jacobs's patch for net-fs/nfs-utils returns. Compared to the original I've just removed the part modifying configure.ac; that file I've dealt with in the patch above. This patch allows net-fs/nfs-utils-1.1.2 to compile against heimdal-1.x and not to use net-libs/libgssglue.
Created attachment 151701 [details, diff] nfs-utils-1.1.2.ebuild-heimdal.diff A diff for the net-fs/nfs-utils-1.1.2.ebuild to use the two patches above and compile against app-crypt/heimdal-1.x without net-libs/libgssglue (which does not play well with heimdal).
Created attachment 154219 [details] heimdal-1.2.ebuild Heimdal 1.2 is out. Wants libtool at least 2.2 that is still masked in portage, so the ebuild, rather than demanding that, tests libtool version and employs a quick and dirty hack if libtool is elder.
Created attachment 154221 [details] heimdal-1.2-gentoo-patches-0.1.tar.bz2 The patchset updated for the 1.2 release. Thanks to the development upstream, adding a patch for LDAP API no longer needed, and 010_all_heimdal-system-libss.patch could be removed as well.
Created attachment 154223 [details, diff] nfs-utils-1.1.2-r1.ebuild-heimdal.diff In portage, there is net-fs/nfs-utils-1.1.2-r1 now, adding one more patch to net-fs/nfs-utils-1.1.2. This diff adapts the new ebuild to heimdal again.
Thx for your great work Honza! I've created a git overlay for all the stuff related to kerberos. I've already commited heimdal-1.2 and it should be usable but it has still a few issues before we can push it into the tree. As this bug is getting really long and the topic is no longer related to the content I'd suggest to close this bug and to open a new one for all the issues which may come up due to the overlay. If you're familiar with git we can make the workflow with the help of patches you create and post in the bug reports. @nfs-utils: I'd say it doesn't make much sense to host the patch here in this bug. If you're really interested in getting this patch into the nfs-utils you'll have to open a new bug which should be assigned to the net-fs herd. Here is the repository url: url = git://git.overlays.gentoo.org/proj/kerberos.git You can access the repo through gitweb also on http://git.overlays.gentoo.org/gitweb/. Do you accept this proceeding? If so, would you please close the bug? If you file a new one please assign it to kerberos@gentoo.org. So far and thx for all the fish, mueli
(In reply to comment #102) Please, consider all those questions and proposals forwarded to Bryan Jacobs by this remark. He is the reporter of this bug, as well as the creator of the ebuilds and patches that I maintain for my personal needs as the upstream versions progress. I definitely welcome the overlay. Unfortunately I am not familiar with git, but it isn't so much of a problem. Not only there are others, especially Bryan Jacobs, who will be more important and useful to the overlay, but even I can learn what's needed for the use of git too. I doubt closing the bug, because closed bugs are invisible in the quick search. While that cannot stop experienced users of the bugzilla, newcomers who have problems with heimdal or contributions to its use in Gentoo might get confused and discouraged. Perhaps closing this bug may be accompanied by creating a new one that will direct to the overlay. The invisibility of closed bugs concerns nfs-utils -- they have their own bug #134064 where Bryan Jacobs has reported his patch, but the bug is closed as needinfo until heimdal-1.x gets into the portage tree. Creating a new bug for the same issue would look to me like waging war on those who closed the one; luckily I think that the overlay (as opposed to this bug) is the right place for all the patches to heimdal dependant packages.
(In reply to comment #103) I agree that closing bugs which are the only sources of "how to make things work" information is a bad idea. I'm still following this, Honza has just been beating me to the punch posting ebuilds :-). My systems, at least, don't get broken when I continue to use the Heimdal-1.x series krb5 implementation. I have not yet tried that overlay, but I surely will in the near future.
The big advantage of an overlay is the possibility to combine experience. It's a good thing if your ebuild is working for you - it would be even better if a lot of others can use it ;) By the way - I've to thank you both Bryan and Honza for the work you've done. I am pretty sure that we have soon stable heimdal ebuilds in an actual usable state ;) So long, g mueli @bug closing: it's ok for me to follow up this bug - it was more some kind of suggestion. It would be really easy to search for bugs assigned to kerberos@gentoo.org in bugzilla. But once more I'd like to ask you if you find bugs related to a special ebuild to file a new bug ...
(In reply to comment #102) > Here is the repository url: > > url = git://git.overlays.gentoo.org/proj/kerberos.git > > You can access the repo through gitweb also on > http://git.overlays.gentoo.org/gitweb/. The layout of this repository, with the portage overlay in a "repo" subdirectory, seems to make things difficult for layman. I'm no wizard with either git or layman, but it would help testing if people could use layman for overlay management. So either restructure the git tree or request an enhancement of layman, so that one can have subdirectories added to layman's make.conf.
I am not using layman, therefor I didn't have your problems. But I fixed it and moved the overlay root from ./repo into the ./ of the repository. Now it should be ok to use the overlay with layman. Feel free to comment here if not ... The next step (before pushing heimdal-1.1 into tree) is to test the reverse dependencies. I've listed my testing state below. [ ] ... not tested [ m ] ... depends direct on mit-krb5 [ n ] ... does not compile [-c-] ... compiles (that's nearly ok for me - if the API is compatible than it should work IMHO) [---] ... compiles and functionality tested $ equery d virtual/krb5 [ Searching for packages depending on virtual/krb5... ] [ n ] app-crypt/kstart-3.12 (virtual/krb5) [---] app-editors/emacs-22.2-r2 (kerberos? virtual/krb5) [ n ] dev-libs/openssl-0.9.8g (kerberos? app-crypt/mit-krb5) [-c-] dev-util/cvs-1.12.12-r4 (kerberos? virtual/krb5) [ ] gnome-base/gnome-vfs-2.20.1-r1 (kerberos? virtual/krb5) [ ] kde-base/kdelibs-3.5.9-r4 (kerberos? virtual/krb5) [ ] net-fs/nfs-utils-1.1.0-r1 (kerberos? app-crypt/mit-krb5) [ ] net-fs/openafs-1.4.7 (kerberos? virtual/krb5) [ n ] net-misc/curl-7.17.1 (kerberos? virtual/krb5) [-c-] net-misc/neon-0.26.4 (kerberos? virtual/krb5) [-c-] net-misc/openssh-4.7_p1-r6 (kerberos? virtual/krb5) [-c-] net-nds/openldap-2.3.41 (!minimal & kerberos? virtual/krb5) [ ] net-print/cups-1.3.7-r1 (kerberos? virtual/krb5) [-c-] sys-auth/nss_ldap-258 (kerberos? virtual/krb5) [ ] sys-auth/pam-afs-session-1.6 (virtual/krb5) [---] sys-auth/pam_krb5-3.10 (virtual/krb5) As you can see there is a lot of work to do ;) Any help on testing would be appreciated. g, mueli
(In reply to comment #107) OpenAFS 1.4.7 tested+works on amd64 with Heimdal 1.2.
(In reply to comment #107) Again on amd64 semi-stable with Heimdal 1.2: - kdelibs compiles - openldap works (GSSAPI via cyrus-sasl, which should be on the list, AND smbkrb5passwd overlay) BUT will not build unless the kpasswd module is turned off - nfs-utils compiles WITH the patch on this list - cups compiles - ipsec-tools, not on the list, compiles (I've never gotten GSSAPI-based IPSec to work ever, even with MIT krb5) - app-crypt/kstart compiles when you change its version to 3.13 (released yesterday)
add new state to list: [-p-] ... need patch to compile actual list - thx to Bryan! (btw - revision bump for kstart is done) [-c-] app-crypt/kstart-3.12 (virtual/krb5) [---] app-editors/emacs-22.2-r2 (kerberos? virtual/krb5) [ n ] dev-libs/openssl-0.9.8g (kerberos? app-crypt/mit-krb5) [-c-] dev-util/cvs-1.12.12-r4 (kerberos? virtual/krb5) [ ] gnome-base/gnome-vfs-2.20.1-r1 (kerberos? virtual/krb5) [-c-] kde-base/kdelibs-3.5.9-r4 (kerberos? virtual/krb5) [-p-] net-fs/nfs-utils-1.1.0-r1 (kerberos? app-crypt/mit-krb5) [ ] net-fs/openafs-1.4.7 (kerberos? virtual/krb5) [ n ] net-misc/curl-7.17.1 (kerberos? virtual/krb5) [-c-] net-misc/neon-0.26.4 (kerberos? virtual/krb5) [-c-] net-misc/openssh-4.7_p1-r6 (kerberos? virtual/krb5) [-c-] net-nds/openldap-2.3.41 (!minimal & kerberos? virtual/krb5) [-c-] net-print/cups-1.3.7-r1 (kerberos? virtual/krb5) [-c-] sys-auth/nss_ldap-258 (kerberos? virtual/krb5) [ ] sys-auth/pam-afs-session-1.6 (virtual/krb5) [---] sys-auth/pam_krb5-3.10 (virtual/krb5) [-c-] net-firewall/ipsec-tool I am going to push the nfs-utils into overlay with the patch included ... as soon as I've time for it ;) ATM I can't say anything to the openldap problem you described ... I am going to test it. @heimdal-1.2 : I don't know what you're doing right - On my machines it fails to compile with: ./.libs/libkrb5.so: undefined reference to `pthread_create' ./.libs/libkrb5.so: undefined reference to `pthread_mutexattr_destroy' ./.libs/libkrb5.so: undefined reference to `pthread_mutexattr_settype' ./.libs/libkrb5.so: undefined reference to `pthread_mutexattr_init' ./.libs/libkrb5.so: undefined reference to `pthread_mutex_trylock' ./.libs/libkrb5.so: undefined reference to `pthread_join' because -pthread is missing in the linker call. Have you fixed that issue or does the problem not occur for you? g, mueli
(In reply to comment #110) I can add to the list following packages that I have installed: [-c-] dev-lang/php-5.2.6-r1 [-c-] dev-libs/cyrus-sasl-2.1.22-r2 [-c-] dev-perl/GSSAPI-0.24 [-c-] gnome-base/gnome-vfs-2.22.0 [-c-] gnome-extra/evolution-data-server-2.22.1.1 [-c-] mail-client/evolution-2.22.1.1 [-p-] net-libs/librpcsecgss-0.18 [-c-] net-analyzer/wireshark-1.0.0 [-p-] net-mail/fetchmail-6.3.8-r1 The patch for net-mail/fetchmail I use is actually a patch to the ebuild only, see the bug #185652 -- changing the dependency from app-crypt/mit-krb5 to virtual/krb5 is actually all that is needed (so the unpatched ebuild is [ m ]). > @heimdal-1.2 : I don't know what you're doing right - On my machines it fails > to compile with: > > ./.libs/libkrb5.so: undefined reference to `pthread_create' > ./.libs/libkrb5.so: undefined reference to `pthread_mutexattr_destroy' > ./.libs/libkrb5.so: undefined reference to `pthread_mutexattr_settype' > ./.libs/libkrb5.so: undefined reference to `pthread_mutexattr_init' > ./.libs/libkrb5.so: undefined reference to `pthread_mutex_trylock' > ./.libs/libkrb5.so: undefined reference to `pthread_join' > > because -pthread is missing in the linker call. Have you fixed that issue or > does the problem not occur for you? Do you have USE="threads"? I've thought that when .configure has among its options --enable-pthread-support, the use of threads can be turned on or off at he will of the user, but I've tested only the USE="threads" case. With USE="-threads" I can reproduce your error -- but I haven't even actually tried to deal with it. Can it be caused by usage of some library compiled with threads support? Another possible pitfall of such nature may be USE="pkinit": I've added that flag having noticed the .configure option --enable-pk-init, but with USE="-pkinit" I get: lib/krb5/.libs/libkrb5.so: undefined reference to `wind_ucs2utf8' lib/krb5/.libs/libkrb5.so: undefined reference to `wind_ucs2read' lib/krb5/.libs/libkrb5.so: undefined reference to `wind_ucs2utf8_length' I think I've noticed some changes of header includes in wind.h at the heimdal mailing lists, so with a bit of luck in 1.2.1 this problem might cease. The simplest ``solution'' of course is to set pkinit and threads always on and not make them USE flags. I unfortunately lack the insight needed to decide if it is actually correct or how to make the package compile without pkinit and/or threads support.
It looks like my patch from comment 46 is still required for heimdal 1.2. BTW, which packages need force_inclusion_by_path.patch, cause I built heimdal without it, but despite having a rather minimal overlay, when it concerns kerberos dependent packages, all of them built fine.
(In reply to comment #112) > It looks like my patch from comment 46 is still required for heimdal 1.2. > BTW, which packages need force_inclusion_by_path.patch, cause > I built heimdal without it, but despite having a rather minimal overlay, > when it concerns kerberos dependent packages, all of them built fine. force_inclusion_by_path.patch is no longer necessary. It was only for early Heimdal-1.0 RCs to make them be able to find their own headers :-). @Honza: the ebuild I'm using is yours from this thread. Do you have USE="threads" enabled?
Created attachment 155083 [details] heimdal-1.2.1_rc1.ebuild An ebuild to test heimdal-1.2.1_rc1. force_inclusion_by_path.patch dropped. heimdal-1.0-as-needed.patch by Rafa? Mu?y?o added to the patchset (sorted under almost ranom number 022). I can compile the package well with pkinit and threads on, but not without. USE="-pkinit" (--disable-pk-init option to the configure script) somehow hides some unicode support functions defined under libs/wind; so far I don't understand it at all. The problems with USE="-threads" (--disable-pthread-support option) arise from the internal copy of sqlite -- that appears to always compile threadsafe, thus requiring -lpthread whenever linked with anything. So far I haven't tried enough to make its configuration respect the global threads settings, not to speak of making heimdal use the system sqlite. Since I like having as much choice as possible, I still keep the pkinit and threads USE flags, but not being actually able to support real choice here I've added error messages if the flags are turned off.
Created attachment 155085 [details] heimdal-1.2.1_rc1-gentoo-patches-0.1.tar.bz2 The patchset for heimdal-1.2.1_rc1.
Created attachment 155319 [details] heimdal-1.2.1_rc1-r1.ebuild Two current heimdal source changes (r23238 and r23235) solve the problem of wind_ucs2 functions when pkinit support is off. One additional small patch is needed for USE="-pkinit" to link hx509 library into kdc anyway, since it's apparently still needed. Still compiles with threads support on only.
Created attachment 155321 [details, diff] heimdal-r23235-kb5-libwind_la.patch
Created attachment 155323 [details, diff] heimdal-r23238-kb5_locl_h-wind_h.patch
Created attachment 155325 [details, diff] heimdal-kdc-sans_pkinit.patch
Created attachment 155335 [details] Layman config for kerberos overlay (In reply to comment #107) > I am not using layman, therefor I didn't have your problems. But I fixed it > and moved the overlay root from ./repo into the ./ of the repository. > Now it should be ok to use the overlay with layman. It does work. If others want to try out the overlay with layman: layman -f -o <URL of this attachment> -a kerberos One day this overlay should get included in the official list of overlays: http://www.gentoo.org/proj/en/overlays/layman-global.txt
Created attachment 155973 [details] heimdal-1.2.1_rc1-r2.ebuild One more patch introduced to use dev-db/sqlite instead of the internal copy. I've tried to design the patch to use pkg-config, and set the ebuild to depend on >=dev-db/sqlite-3.5.7, because that is the version of sqlite inside the heimdal sources. Should compile without pkinit as well as without threads support now.
Created attachment 155975 [details, diff] heimdal-system_sqlite.patch Patch to use system sqlite. Allows heimdal to compile without threads support.
Thx a lot for your work Honza, I really appreciate it! The patches work quite well in my environments. I've just pushed the 1.2.1_rc1 into the overlay. I am going to test the ebuild on two more environments tomorrow than I am going to commit it into the tree with ~x86 ~amd64 but without ldap support. It would be nice to discuss the ldap issue once again. ATM I am building heimdal without ldap support. Apart from the fact that I can't advice to use LDAP as backend for kerberos I am willing to add the use if we find an acceptable way to brake the circular dependency if global USE="ldap kerberos" is set. discussion is open and welcome ... JFYI: I've changed to naming rule of the patchset to ${PN}-gentoo-patches-${PATCHVER} than it's not necessary to rename the patchset with each release bump.
There is a big problem left which makes heimdal almost blocking for stable. You can't compile openssl with kerberos USE if heimdal is installed. :( I am atm testing with "dev-libs/openssl -kerberos".
Latest state on testing: [ n ] dev-libs/openssl-0.9.8g (kerberos? app-crypt/mit-krb5) [-p-] net-fs/nfs-utils-1.1.0-r1 (kerberos? app-crypt/mit-krb5) [-p-] net-libs/librpcsecgss-0.18 [-p-] net-mail/fetchmail-6.3.8-r1 [-c-] app-crypt/kstart-3.12 (virtual/krb5) [---] app-editors/emacs-22.2-r2 (kerberos? virtual/krb5) [-c-] dev-util/cvs-1.12.12-r4 (kerberos? virtual/krb5) [ ] gnome-base/gnome-vfs-2.20.1-r1 (kerberos? virtual/krb5) [-c-] kde-base/kdelibs-3.5.9-r4 (kerberos? virtual/krb5) [-c-] net-fs/openafs-1.4.7 (kerberos? virtual/krb5) [-c-] net-misc/curl-7.18.2 (kerberos? virtual/krb5) [-c-] net-misc/neon-0.26.4 (kerberos? virtual/krb5) [-c-] net-misc/openssh-4.7_p1-r6 (kerberos? virtual/krb5) [-c-] net-nds/openldap-2.3.41 (!minimal & kerberos? virtual/krb5) [-c-] net-print/cups-1.3.7-r1 (kerberos? virtual/krb5) [-c-] sys-auth/nss_ldap-258 (kerberos? virtual/krb5) [ ] sys-auth/pam-afs-session-1.6 (virtual/krb5) [---] sys-auth/pam_krb5-3.10 (virtual/krb5) [-c-] net-firewall/ipsec-tool [-c-] dev-lang/php-5.2.6-r1 [-c-] dev-libs/cyrus-sasl-2.1.22-r2 [-c-] dev-perl/GSSAPI-0.24 [-c-] gnome-base/gnome-vfs-2.22.0 [-c-] gnome-extra/evolution-data-server-2.22.1.1 [-c-] mail-client/evolution-2.22.1.1 [-c-] net-analyzer/wireshark-1.0.0 Looks quite good so far ...
heimdal-1.2.1_rc1 commited into tree.
heimdal should be split up in at least four packages: - common libs (should provide virtual/krb5) - client apps (kinit, kdestroy, kpasswd, ...) - server apps (kdc, kpasswdd) - heimdal meta build for people who don't want to think a lot :-) support for the kerberized applications should be removed at all or put in different ebuilds. today people should use openssh with kerberos support and not rsh. ftpd with kerberos can be replaced by proftpd with it's kerberos support. su and login should be replaced with the shadow's implementations and pam_krb5. and so on. maybe you should think about that. maybe heimdal at all should think about that. all alternative application support kerberos but have a whole bunch of other feature that the heimdal ones don't have. one advantage is, that split ebuilds would eliminate the circular dependency with ldap, as ldap would only require heimdal common libs and heimdal-server would depend on ldap. you could use the internal sqlite without thread support if you added use threads || append-flags -DSQLITE_THREADSAFE=0 before econf. and i guess there an as-needed bug (at least there is one for my ebuilds): libroken needs to be linked to -lcrypt but isn't by the upstream makefiles. as soon as gentoo has changed the ssl to the openssl use flag, this should be used here. people may be confused with an ssl use flag, although heimdal does never use ssl. it uses libcrypto from the openssl package.
(In reply to comment #127) > heimdal should be split up in at least four packages: > - common libs (should provide virtual/krb5) > - client apps (kinit, kdestroy, kpasswd, ...) > - server apps (kdc, kpasswdd) > - heimdal meta build for people who don't want to think a lot :-) > > support for the kerberized applications should be removed at all or put... Doesn't this part reach somewhat too far? Not only is it more suitable for upstream, perhaps http://list.sics.se/sympa/arc/heimdal-discuss -- it even addresses features common to heimdal and mit-krb5. Definitely splitting up heimdal and leaving mit-krb5 alone makes no sense. In my opinion, the split-up should be suggested directly upstream, to both developer teams. Unless such an improvement is really necessary and the upstream developers really stubborn, I'm against keeping such changes at Gentoo level.
(In reply to comment #127) > heimdal should be split up in at least four packages: > - common libs (should provide virtual/krb5) > - client apps (kinit, kdestroy, kpasswd, ...) > - server apps (kdc, kpasswdd) > - heimdal meta build for people who don't want to think a lot :-) Makes me think of the way binary distributions like Debian use single source packages to build multiple binary packages from them. While I agree that from a user point of view it would be nice to have all these things in different packages and only install what you need, from the perspecitve of the sources and build process I guess it would be rather difficult to split them. If it can be done easily, though, without too much repeated work, and does even solve the ldpa cyclic dependency problem, then I as a Gentoo user would like to see it split.
in the case of heimdal, it is very easy to split those parts. eautoreconf and configure need to run each time, a split packages is built. one big advantage of gentoo is, that it is possible to only install what you really want and need. and i don't want kdc on my clients. additionally it should be easier to install updates, because in that case only parts of heimdal need to be re-built. the libs do not need to be re-compiled on client system only because of a bug in the kdc code, that does not even run on that systems.
As long as we have no USE depend it might be dangerous to split it. Just think of the case that you set per package USE in the client apps and install the server parts afterwards. Then you'd have to set the USE manually or client and server may be incompatible. (a problem which won't occur on binary distributions) Nevertheless I've already looked at the way debian is handling this issue and the feature request isn't dropped - it's just moved a bit downwards on the priority list. The highest priority for me is to fix all the reverse dependencies (like nfs-utils) and to save enable the ldap support (although I don't like it ;) ). Now it's time to test and to hang out the ebuild ... As this bug thread clarifies the gentoo community has lost a bit on experience because of the long time heimdal not being updated.
Created attachment 156553 [details, diff] new version for patch librpcsecgss-0.18-config_in.patch i slightly changed the patch librpcsecgss-0.18-config_in.patch. i hope you like it.
Created attachment 156555 [details, diff] patch for nfs-utils's way to detect the kerberos libs. maybe this patch can be send upstream.
Thx mastamind! The librpcsecgss-0.18-heimdal.patch is included in the kerberos overlay atm. I am going to file a bug and hopefully the maintainer of librpcsecgss will include it in the tree.
the cracklib dependency is currently useless because the ebuild does not compile the cracklib plugin for kpasswdd. either compile the plugin or remove the cracklib dependency. the best solution would be to add a cracklib use flag. another idea would be to add an otp use flag. people who don't use otp may be able to disable is that way.
hi. i managed to mount an export via nfs4 but i get the following error message on server and client: ERROR: GSS-API: error in gss_krb5_export_lucid_sec_context(): Miscellaneous failure (see text) - unknown mech-code 0 for mech 1 2 840 113554 1 2 2 i search on google, but didn't find any useful information. i guess, we are just one step before heimdal + nfs4.
You are fully right in both. I've removed the cracklib dependency because of "Code for a password quality checking function that uses the cracklib library can be found in lib/kadm5/sample_password_check.c in the source code distribution. It requires that the cracklib library be built with the patch available at ftp://ftp.pdc.kth.se/pub/krb/src/cracklib.patch." and I don't want to patch cracklib atm. I'll see it as feature request for the future. The otp USE makes sense indeed. I've added it and I'll push it into tree as -r1. g, mueli
If I am honest - I haven't managed to compile the nfs-utils against heimdal yet because I've only tried it once with your patches. I've to investigate the problem as soon I find the time for it ;) But it sounds really promising!
If anybody is interested: it seems that dovecot can be built with heimdal, if that version check is removed from configure.in (it's probably invalid for heimdal).
Should have specified: Iwas talking about app-crypt/heimdal-1.2 and net-mail/dovecot-1.1.1
thx for that information. i am using dovecot as well as cyrus-imapd/cyrus-sasl with heimdal 1.2.1_rc1. works perfectly. do you have other applications (servers or clients) using heimdal? it would also be a good idea to meet on irc as soon as possible to discuss the next steps. probably at least on of the maintainers of the nfs packages should attend that meeting too. if we have dicussed our steps, we may probably send some or all of our patches upstream so that other distributions can use them as well and we do not have to maintain a lot gentoo-specific patches. maybe as some kind of compromise we can create a "server" use flag that will disable the built and installation of the server applications. that way we do not need to split the ebuilds. it sould not be a big problem to patch configure to provide a --disable-server option.
heimdal-1.2.1_rc2 pushed into overlay. Please test it ;)
Once again an update on the actual support state of heimdal in the kerberos overlay: [ n ] dev-libs/openssl-0.9.8g (kerberos? app-crypt/mit-krb5) [-c-] app-crypt/kstart-3.12 (virtual/krb5) [---] app-editors/emacs-22.2-r2 (kerberos? virtual/krb5) [-c-] dev-util/cvs-1.12.12-r4 (kerberos? virtual/krb5) [ ] gnome-base/gnome-vfs-2.20.1-r1 (kerberos? virtual/krb5) [-c-] kde-base/kdelibs-3.5.9-r4 (kerberos? virtual/krb5) [-c-] net-fs/openafs-1.4.7 (kerberos? virtual/krb5) [-c-] net-misc/curl-7.18.2 (kerberos? virtual/krb5) [-c-] net-misc/neon-0.26.4 (kerberos? virtual/krb5) [-c-] net-misc/openssh-4.7_p1-r6 (kerberos? virtual/krb5) [-c-] net-nds/openldap-2.3.41 (!minimal & kerberos? virtual/krb5) [-c-] net-print/cups-1.3.7-r1 (kerberos? virtual/krb5) [-c-] sys-auth/nss_ldap-258 (kerberos? virtual/krb5) [ ] sys-auth/pam-afs-session-1.6 (virtual/krb5) [---] sys-auth/pam_krb5-3.10 (virtual/krb5) [-c-] net-firewall/ipsec-tool [-c-] dev-lang/php-5.2.6-r1 [-c-] dev-libs/cyrus-sasl-2.1.22-r2 [-c-] dev-perl/GSSAPI-0.24 [-c-] gnome-base/gnome-vfs-2.22.0 [-c-] gnome-extra/evolution-data-server-2.22.1.1 [-c-] mail-client/evolution-2.22.1.1 [-c-] net-analyzer/wireshark-1.0.0 [-c-] net-fs/nfs-utils-1.1.0-r1 (kerberos? app-crypt/mit-krb5) [-c-] net-libs/librpcsecgss-0.18 [-c-] net-mail/fetchmail-6.3.8-r1 time to push it into tree?? ;) g, mueli
little mistakes in last post - gnome-vfs and pam-afs-session now also tested to compile ;) [ n ] dev-libs/openssl-0.9.8g (kerberos? app-crypt/mit-krb5) [-c-] app-crypt/kstart-3.12 (virtual/krb5) [---] app-editors/emacs-22.2-r2 (kerberos? virtual/krb5) [-c-] dev-util/cvs-1.12.12-r4 (kerberos? virtual/krb5) [-c-] gnome-base/gnome-vfs-2.20.1-r1 (kerberos? virtual/krb5) [-c-] kde-base/kdelibs-3.5.9-r4 (kerberos? virtual/krb5) [-c-] net-fs/openafs-1.4.7 (kerberos? virtual/krb5) [-c-] net-misc/curl-7.18.2 (kerberos? virtual/krb5) [-c-] net-misc/neon-0.26.4 (kerberos? virtual/krb5) [-c-] net-misc/openssh-4.7_p1-r6 (kerberos? virtual/krb5) [-c-] net-nds/openldap-2.3.41 (!minimal & kerberos? virtual/krb5) [-c-] net-print/cups-1.3.7-r1 (kerberos? virtual/krb5) [-c-] sys-auth/nss_ldap-258 (kerberos? virtual/krb5) [-c-] sys-auth/pam-afs-session-1.6 (virtual/krb5) [---] sys-auth/pam_krb5-3.10 (virtual/krb5) [-c-] net-firewall/ipsec-tool [-c-] dev-lang/php-5.2.6-r1 [-c-] dev-libs/cyrus-sasl-2.1.22-r2 [-c-] dev-perl/GSSAPI-0.24 [-c-] gnome-base/gnome-vfs-2.22.0 [-c-] gnome-extra/evolution-data-server-2.22.1.1 [-c-] mail-client/evolution-2.22.1.1 [-c-] net-analyzer/wireshark-1.0.0 [-c-] net-fs/nfs-utils-1.1.2-r2 [-c-] net-libs/librpcsecgss-0.18 [-c-] net-mail/fetchmail-6.3.8-r3 ... I can see the light at the end of the tunnel ...
A small question first: about fetchmail: maybe it's just me, cause I've got '-Wl,--as-needed' or maybe it's just me, cause I've got only heimdal installed, but bug 185652 is still valid for me. Fetchmail still fails to build with heimdal, due to reasons stated there and builds with the patch I've attached there, though by now only needed part of the patch is the block, that changes ' AC_CHECK_LIB(ssl, MD5_Init, [],' to 'AC_CHECK_LIB(crypto, MD5_Init, [],'.
And wouldn't it be a good idea to drop krb4 for fetchmail, upstream has officially stated that krb4 can be no longer treated as any security.
Created attachment 160062 [details, diff] patch for fetchmail configure.ac to remove the check for MD5_Init. the patch works with "kerberos ssl", "kerberos -ssl" and of course "-kerberos ssl".
Created attachment 160064 [details, diff] updated ebuild patch for fetchmail
It's really hard for me to keep overview if all packages are inside this bug. I'd really appreciate if you could visit the corresponding bugs for each package: - nfs-utils : #231396 - fetchmail : #231400 - librpcsecgss : #231395 It'd would make my job easier ;) Once again a great thanks to all of you! g, mueli
just open one bug per package and have those block this bug makes tracking stuff a lot easier
Ack. Have added all the blockers and deps. Now it should be really clear to all of us ... even me ;)
While trying to figure out why my kftpd does not work, I ran it in the foreground: # /usr/sbin/kftpd -i -a plain kftpd: socket af = 10: Address family not supported by protocol It seems like it tries to run IPV6 on my system with USE lacking "ipv6". Still would believe IPV4-only is the default. >>> Emerging (1 of 1) app-crypt/heimdal-1.2.1_rc1-r1 to / * heimdal-gentoo-patches-0.2.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * heimdal-1.2.1rc1.tar.gz RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking heimdal-1.2.1rc1.tar.gz ;-) ... [ ok ] * checking heimdal-gentoo-patches-0.2.tar.bz2 ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking heimdal-1.2.1rc1.tar.gz to /var/tmp/portage/app-crypt/heimdal-1.2.1_rc1-r1/work >>> Unpacking heimdal-gentoo-patches-0.2.tar.bz2 to /var/tmp/portage/app-crypt/heimdal-1.2.1_rc1-r1/work * Applying various patches (bugfixes/updates) ... * 001_all_heimdal-no_libedit.patch ... [ ok ] * 002_all_heimal-fPIC.patch ... [ ok ] * 003_all_heimdal-rxapps.patch ... [ ok ] * 005_all_heimdal-suid_fix.patch ... [ ok ] * 012_all_heimdal-berkdb.patch ... [ ok ] * 013_all_heimdal-pthread-lib.patch ... [ ok ] * 014_all_heimdal-path.patch ... [ ok ] * 022_all_heimdal-as-needed.patch ... [ ok ] * Done with patching * Applying heimdal-r23238-kb5_locl_h-wind_h.patch ... [ ok ] * Applying heimdal-r23235-kb5-libwind_la.patch ... [ ok ] * Applying heimdal-kdc-sans_pkinit.patch ... [ ok ] * Applying heimdal-system_sqlite.patch ... [ ok ] * Running eautoreconf in '/var/tmp/portage/app-crypt/heimdal-1.2.1_rc1-r1/work/heimdal-1.2.1rc1' ... * Running aclocal -I cf -I cf ... [ ok ] * Running libtoolize --copy --force --install --automake ... [ ok ] * Running aclocal -I cf -I cf ... [ ok ] * Running autoconf ... [ ok ] * Running autoheader ... [ ok ] * Running automake --add-missing --copy --foreign ... [ ok ] * Running elibtoolize in: heimdal-1.2.1rc1 * Applying sed-1.5.6.patch ... >>> Source unpacked. >>> Compiling source in /var/tmp/portage/app-crypt/heimdal-1.2.1_rc1-r1/work/heimdal-1.2.1rc1 ... * econf: updating heimdal-1.2.1rc1/config.guess with /usr/share/gnuconfig/config.guess * econf: updating heimdal-1.2.1rc1/config.sub with /usr/share/gnuconfig/config.sub ./configure --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --without-ipv6 --enable-berkeley-db --disable-pk-init --with-openssl --with-x --enable-pthread-support --disable-otp --enable-kcm --enable-shared --enable-netinfo --prefix=/usr --libexecdir=/usr/sbin --build=i686-pc-linux-gnu ... checking for IPv6 stack type... checking for IPv6... checking for in6addr_loopback... ... ^z # grep IPV /var/tmp/portage/app-crypt/heimdal-1.2.1_rc1-r1/work/heimdal-1.2.1rc1/config.status D["HAVE_IPV6"]=" 1" config.log says: configure:19299: checking for IPv6 stack type conftest.c:89:45: error: /usr/local/v6/include/sys/types.h: No such file or directory configure:19441: result: configure:19444: checking for IPv6 configure:19494: i686-pc-linux-gnu-gcc -o conftest -O2 -march=pentium4 -mmmx -msse -msse2 -fomit-frame-pointer -pipe -D_LARGE_FILES= -D_FILE_OFFSET_BITS=64 conftest.c -lpthread >&5 configure:19501: $? = 0 configure:19521: result: configure:19535: checking for in6addr_loopback configure:19577: i686-pc-linux-gnu-gcc -o conftest -O2 -march=pentium4 -mmmx -msse -msse2 -fomit-frame-pointer -pipe -D_LARGE_FILES= -D_FILE_OFFSET_BITS=64 conftest.c -lpthread >&5 configure:19584: $? = 0 configure:19604: result:
Created attachment 160721 [details, diff] disable ipv6 autodetection (proposed fix for #152) I hope this patch will solve your problem. We will add this patch and the sysmlinked manpages patch (#168591) as soon as possible to the ebuild.
(In reply to comment #153) > Created an attachment (id=160721) [edit] > disable ipv6 autodetection (proposed fix for #152) > > I hope this patch will solve your problem. We will add this patch and the > sysmlinked manpages patch (#168591) as soon as possible to the ebuild. > creating include/version.h /var/tmp/portage/app-crypt/heimdal-1.2.1_rc1-r1/temp/environment: line 2850: [: too many arguments /var/tmp/portage/app-crypt/heimdal-1.2.1_rc1-r1/temp/environment: line 2850: [: too many arguments Making all in include It does not help either. I do not see the variable defined anymore in config.status. How about rather forcing it set to 0 (aka unset it)? Otherwise someone should walk the sources and figure out why omitting it from defines does not help.
Created attachment 160772 [details, diff] updated version The problem is a call to getaddrinfo in mini_inetd() in file lib/roken/mini_inetd.c. It returns AF_INET6 although the kernel does not support it. I think this is a glibc bug. getattrinfo should not return unsupported network layer protocols.
(In reply to comment #154) > It does not help either. I do not see the variable defined anymore in > config.status. How about rather forcing it set to 0 (aka unset it)? Otherwise > someone should walk the sources and figure out why omitting it from defines > does not help. I've just reviewed and commited the patch of mastamind into overlay. Could you please test it? Thx for your help, mueli
(In reply to comment #155) > Created an attachment (id=160772) [edit] > updated version The patch makes it work. Thanks.
(In reply to comment #144) pam-krb5 works correctly on x86 and amd64.
mastamind has reported the patch to upstream (thx for your big help) which Love has included in his way. I've now backported the changes and created and commited the new (but very similar) patch into overlay - feel free to test ;) g, mueli
(In reply to comment #102) > Do you accept this proceeding? If so, would you please close the bug? If you > file a new one please assign it to kerberos@gentoo.org. > > So far and thx for all the fish, mueli > I was holding off on closing this bug until I had tested all of the software I use with the new Heimdal version. Once a bug is closed it becomes very difficult to find, and I wanted people searching for "Heimdal" to have this come up as one of the results. I'm now satisfied that this bug has been fixed. I even have NFSv4 working with krb5 security thanks to #231395 and #231396 . Thank you all for your great work on this. The only outstanding problem that bugs me is that I have to patch the overlay to re-enable LDAP support since my principals are stored in LDAP. I don't mind building Heimdal twice (once with USE="-ldap") on my KDCs. But that's a matter for another bug. (by the way, I think the solution is to use a new USE flag for Heimdal, maybe called "hdb-ldap", so that people won't be able to produce the circular dependency unless they explicitly opt for a special feature)
Now I am a bit annoying and reopen the bug ;) - just because of the dependency tree and I am ATM using this bug as tracker for 1.2.x heimdal in gentoo. BTW: I really like your suggestion with the new ldap USE called "hdb-ldap". Does this solution anyone else bother? (I pushing it that way into overlay) g, mueli
With the today's invention of sys-libs/e2fsprogs-libs, ebuild of heimdal needs to be updated.
BTW, something may be wrong with configuration of gentoo gitweb for heimdal. When I click on the ebuild of heimdal and then choose "raw", I'm getting following address: http://git.overlays.gentoo.org/gitweb/?p=proj/kerberos.git;a=blob_plain;f=app-crypt/heimdal/heimdal-1.2.1.ebuild;h=HEAD;hb=HEAD but to see the file in the browser, it needs to be: http://git.overlays.gentoo.org/gitweb/?p=proj/kerberos.git;a=blob_plain;f=app-crypt/heimdal/heimdal-1.2.1.ebuild;hb=HEAD .
Created attachment 163190 [details, diff] Allow for e2fsprogs-libs (In reply to comment #162) > With the today's invention of sys-libs/e2fsprogs-libs, > ebuild of heimdal needs to be updated. This patch to the git overlay should fix that issue, by allowing e2fsprogs-libs instead of com_err or ss. As an alternative to applying this patch, you can also execute these commands in the heimdal directory of the overlay: sed -i \ 's:sys-libs/\(com_err\|ss\):|| ( sys-libs/\1 sys-libs/e2fsprogs-libs ):' \ *.ebuild for i in *.ebuild; do ebuild $i digest; done
Comment on attachment 155335 [details] Layman config for kerberos overlay As the kerberos overlay is now included in the master list of layman overlays, a separate config file is no longer needed. Simply type "layman -a kerberos" to add the overlay.
I'd say it's time to close this bug. heimdal-1.2 is in tree. Stabilization shouldn't be part of this bug here. g, mueli
