Hi, There are currently 3 kerberos implementations in portage tree. - Kerberos 5 (and 4) implementation from MIT: krb5 & mit-krb5 (bug 16449) - Kerberos 5 implementation from KTH: heimdal - Kerberos 4 implementation from KTH: kth-krb The USE variable "kerberos" is currently used to build support for all implementations. This causes confusion since most software only support one implementation. All kerberos implementations provide tools like kinit, kdestroy and kadmin. They can't be installed within the same system. The kerberos ebuilds should PROVIDE="virtual/kerberos", that would block other implementations from overwriting each others. I can provide the required patches for every latest stable and unstable ebuild that has IUSE="kerberos" in it, there are only few of them. Currently kerberos support of Gentoo is broken. Reproducible: Always Steps to Reproduce: Example 1: USE="kerberos" and heimdal 1. Emerge heimdal 2. With USE="kerberos" try to emerge openssh, samba (latest alpha) or openldap Example 2: USE="-krb4 kerberos" with mit-krb5 1. Emerge mit-krb5 2. Emerge xscreensaver Actual Results: Example 1: Openssh overwrites heimdal files with it's dependency, app-crypt/krb5 Example 2: Xscreensaver doesn't build, it wants krb4 Expected Results: Example 1: I would have had USE="heimdal" set and those merges wouldn't have overwritten anything. Example 2: Xscreensaver wouldn't have tried to do anything because of my USE="-krb4"
Created attachment 8966 [details] New mit-krb5 ebuild Version bump, initd script split and PROVIDE="virtual/kerberos"
Created attachment 8967 [details] mit-krb5-1.2.7.ebuild & co I forgot to add the DEPEND="!virtual/kerberos" I talked so much about.
Any opinions before I start making more progress?
Been there, done that, doesn't work. Unless things have changed drastically (I just checked, they haven't), heimdal uses the libraries and headers kth-krb installs in /usr/athena in order to provide Kerberos 4 support. You need to be able to install both at the same time. I ran into people using exactly this setup when I created ebuilds to handle all this last year. I assume those folks are still out there. In order to meet everyone's needs, you've got to support the following configurations: Kerberos 4 support = either kth-krb or krb5 Kerberos 5 support = either heimdal or krb5 Kerberos 4 and 5 support: either (kth-krb AND heimdal) or krb5 I originally handled this with two virtuals (virtual/kerberos4 and virtual/kerberos5 -- MIT's krb5 provided both) and two USE flags (kerberos4 and kerberos5). Somewhere along the way, someone folded the virtuals into virtual/krb5 and the flags into krb5. The kerberos4 flag has re-appeared in the newest mit-krb5 and heimdal packages as krb4. Two other misc. items I ran into along the way that may or may not still be relevant: First, there were certain ebuilds (cyrus-sasl comes to mind) that apparently couldn't have both Kerberos 4 and 5 enabled at the same time (or at least, I was told they couldn't both be enabled when I went through this exercise last April). So if a user had specified USE="krb4 krb5", only one could be used. I don't know of anyway to handle this short of a 'preferkrb4' flag. I punted and just chose krb5 in these situations. Second, there were packages that couldn't automatically find the kerberos headers and libraries, requiring the locations be passed to configure. As of now, krb5 installs headers and libraries under /usr, kth-krb installs them under /usr/athena, and heimdal installs them under /usr/heimdal. As a result, there's no generic way to set configure's kerberos paths without knowing precisely which package is installed. I handled this by having the kerberos ebuilds create the appropriate symbolic links -- /usr/kerberos4 and/or /usr/kerberos5 -- and having the other ebuilds reference those links. Like virtual/kerberos4, those links have since disappeared. This may no longer be a problem now that the krb5 and mit-krb5 stuff has migrated from /usr/krb5 to /usr, but I've not checked.
This probably should be thinked.. lets fix bug 16449 first. Ryan, please take that bug too..
Per comment #4: If somebody wouldn't relocate kth-krb and heimdal binaries into /usr prefix, everything would would work. Just keep kth-krb4 installed in /usr/athena and heimdal under /usr/heimdal and you can breath better. Those two _CAN_ coexist and _have to_ coexist if you want to build heimdal with krb4 backwards compatibility. I tell you why everybody on kerberos and afs email list complains that software packages always screw-up packages: because they relocate binaries, libs, headers into non-standard places and then configure doesn't find them. Yes, it could be made to look into directories specified by the user, but someone has to write the code. In the meantime, it just sucks. Look at kerberos support of POP3, IMAP daemons, mozilla etc. Where do they look for heimdal? In '/usr/heimdal'.
I don't think it is a good idea to force people use only one implementation of krb5 either by virtual/krb5. Imagine people using applications where some of them support (read can get compiled) against mit-krb5 and some detect better heimdal. I think having something like "prefer heimdal over mit-krb5" USE flag would be all we need. Per comment #4: When we are furtunate, more applications will use /usr/heimdal/bin/krb5-config to fetch the include and link options to link flawlessly against heimdal. Also /usr/athena/bin/krb4-config got introduced in recent versions of kth-krb4. I don't use mit-krb5 but I think I've heard on one of the email lists they were going to introduce something similar. Until every configure knows about those config binaries, the configure looks into typical locations: /usr/athena and /usr/heimdal. Installing while relocating heimdal and kth-krb into /usr prefix has in the past resulted in many header file a library conflicts. It is just not recommended, not supported, is nonsensical. Gentoo should definitely allow people to have all three packages kerberos installed at once. I'm not joking. Just make available the flag to set user preference. I don't see /usr/portage/profiles/use.desc being up-to-date, but will write here what I do propose: Provide flags: heimdal_pref_over_mit-krb5 - Prefer compiling apps against heimdal rather then mit-krb5 mit-krb5_pref_over_heimdal - vice versa Keep: heimdal - try to compile against heimdal kth-krb - try to compile against kth-krb4, insecure, switch either to heimdal or mit-krb5 mit-krb5 - try to compile against mit-krb5 Kill: kerberos - Adds kerberos support krb4 - Adds optional kerberos 4 compatibility support krb5 BTW: If it is not obvious, the USE flags setting the preference should also affect how PATH is set for the user. It is a common habit, actually was always required that user set /usr/athena/bin or /usr/heimdal/bin or /usr/krb5/bin in fron of /usr/local/bin and /usr/bin, so that the "correct" telnet, ftp, kinit and other command gets executed. Also LD_LIBRARY_PATH was always required to be set in similar way, (although I used to do this on OSF1, Irix and Solaris, maybe it's not necessary with linux and ldconfig - honestly said am not sure if this is still necessary). Hth.
net-fs/nfs-utils supports only mit-krb5. Right now, having kerberos use flag forces me to install mit-krb5, which I cannot because I have heimdal installed (they block each other). See bug #134064. Will someone re-introduce the heimdal/mit-krb5/kth-krb4 USE flags as I have proposed in comment #7? Packages app-crypt/kth-krb4 and app-crypt/mit-krb5 when compiled with krb4 support should still provide virtual/krb4 flag. Packages heimdal and mit-krb5 should continue providing virtual/kerberos for backawards compatibility, but in future this flag should be removed, as it is useless.
(In reply to comment #8) > net-fs/nfs-utils supports only mit-krb5. Right now, having kerberos use flag > forces me to install mit-krb5, which I cannot because I have heimdal installed > (they block each other). See bug #134064. > > Will someone re-introduce the heimdal/mit-krb5/kth-krb4 USE flags as I have > proposed in comment #7? > > Packages app-crypt/kth-krb4 and app-crypt/mit-krb5 when compiled with krb4 > support should still provide virtual/krb4 flag. > > Packages heimdal and mit-krb5 should continue providing virtual/kerberos for > backawards compatibility, but in future this flag should be removed, as it is > useless. > I disagree - you state that most applications only support mit-krb5 or Heimdal rather than both, but I don't think this is the case. I've actually compiled nfs-utils-1.1.0 against Heimdal. It seems to work. And the trend is definitely to support either implementation - few new packages come out which are specific to one or the other as both mirror eachothers' features. kth-krb should probably go away altogether, as Heimdal has full Kerberos 4 support (and nobody new should be using krb4 anyhow, except possibly with a kaserver). I think the proper solution is to patch non-krb5config-aware programs and submit those patches upstream.
Bryan, yeas, after a year things are better nowadays, there is bug #134064 helping in this regard but nobody committed the patches to the tree ... BTW, openafs does not require kaserver running, the heimdal's or MITs KDC can be used as well. And because kth-krb has been dropped from portage there is no krb4 support anymore in Gentoo. So as long as kerberos is maintained (very few people has the will to do that and really fix things), and it does not clash with e.g. java kinit(1), etc., I am all fine with such changes. I got tired of convincing people to keep the different software in different paths, and don't care about clashes anymore, sorry. I think there used to be bug I have filed in the past with such name clashes listed, develeopers said they will all rather fix the issues, but who had to report them first? Still I believe some do exist. Yes, krb4 is finally getting dead.
Please see bug 185899 - we are on it to get back the freedom to choose between heimdal and mit-krb5 to the users. Therefor I will close this bug ... (all deps already are)
