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
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.
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
Example 1: Openssh overwrites heimdal files with it's dependency, app-crypt/krb5
Example 2: Xscreensaver doesn't build, it wants krb4
Example 1: I would have had USE="heimdal" set and those merges wouldn't have
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
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
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
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
I don't see /usr/portage/profiles/use.desc being up-to-date, but will write here
what I do propose:
heimdal_pref_over_mit-krb5 - Prefer compiling apps against heimdal rather then
mit-krb5_pref_over_heimdal - vice versa
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
kerberos - Adds kerberos support
krb4 - Adds optional kerberos 4 compatibility support
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).
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
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)