Bugzilla Bug 134064

nfs-utils currently requires me to have mit-krb5 package installed when
kerberos use flag is set. This prevents me to have kerberos flag site-wide, as
need nfs-utils and I do use heimdal and that clashes with mit-krb5.

Depending on virtual/krb5 instead of mit-krb5 would help, but the sourcecode
supports only mit-krb5 (README talks only about MIT krb5). So, I think the
ebuild should be fixed not to request mit-krb5 at all. When mit-krb5 is
installed, then it should enable the --enable-gss configure flag, otherwise you
always have to use --disable-gss (or configure is fooled by headers and detects
Heimdal, but breaks on compile).

(In reply to comment #1)
> So, I think the
> ebuild should be fixed not to request mit-krb5 at all. When mit-krb5 is
> installed, then it should enable the --enable-gss configure flag, otherwise you
> always have to use --disable-gss (or configure is fooled by headers and detects
> Heimdal, but breaks on compile).

s/fixed/broken/ ? :) Automagic dependencies are a big evil... If nfs-utils
doesn't support heimdal, then there's no point in switching the dependency to
virtual/krb5. 

We can't remove the dependency, feel free to use /etc/portage/package.use to
disable kerberos use flag for this ebuild. Reopen if you have a patch, CANTFIX
meanwhile.

I did fix that issue for myself temporarily by editing the ebuild and masking
<net-fs/nfs-utils-1.0.7-r3, but most people do NOT have the experience with
kerberos stuff so they wil raise the issues again. 

See my comment #2 in bug #103366 as well. The quick fix which would make the
package compilable even when kerberos USE flag is set and only heimdal is
installed should be the following:


# krb5-config --cflags
-I/usr/include/heimdal 
#

When kerberos use flag is set and when "heimdal" does NOT occur in the command
output as shown above, --enable-gss should be passed to configure. In all other
cases, --disable-gss should be forced to prevent configure to pick-up any
headers resembling kerberos stuff. Imagine application silently linking over
kerberos libs outside the control of portage. And, nfs-utils is one o the real
examples.

For your fun see also:
bug #16824
bug #100868
bug #118508
bug #132189

(In reply to comment #3)
> The quick fix which would make the
> package compilable even when kerberos USE flag is set and only heimdal is
> installed should be the following:
> 
> 
> # krb5-config --cflags
> -I/usr/include/heimdal 

If that works, I don't see anything wrong w/ that. All I was saying is that
dropping the dependency and leaving this up to some automagic detection isn't
really an option...

BTW, the check for "heidmal" in krb5-config output I proposed also because of
the reason that when people keep /usr/heimdal/ installed as well and have that
in the PATH, this magic detection would still force --disable-gss and thus make
nfs-utils not to break on compile.

simply changing the DEPEND doesnt fix anything ... verify the code builds
correctly with all virtual/krb5 providers and i'll change it ... otherwise, no
dice

from an older ebuild:
DEPEND="${RDEPEND}
        >=sys-apps/portage-2.0.51
        !nonfsv4? (
                >=dev-libs/libevent-1.0b
                >=net-libs/nfsidmap-0.9
        )
        kerberos? ( app-crypt/mit-krb5 )"
        # kth-krb doesn't provide the right include
        # files, and nfs-utils doesn't build against heimdal either, 
        # so don't depend on virtual/krb.
        # (04 Feb 2005 agriffis)

Grepping for heimdal in the nfs-utils-1.0.10 sources shows that some effort
must have gone into trying to support heimdal. Looking at the ChangeLog I find
this:

2005-08-26 Kevin Coffman <kwc@citi.umich.edu>
        Changes to allow gssd/svcgssd to build when using Hiemdal Kerberos
        libraries.  Note that there are still run-time issues preventing
        this from working when shared libraries for libgssapi and librpcsecgss
        are used.

A bit difficult to find due to the misspelling. I don't know what issues those
are, but this seems a long time ago, so they might be solved by now.

However, the thing won't even compile. I get
  context_heimdal.c:81: error: dereferencing pointer to incomplete type
which is because in /usr/include/heimdal/gssapi.h you find these two lines:
  struct gss_ctx_id_t_desc_struct;
  typedef struct gss_ctx_id_t_desc_struct *gss_ctx_id_t;
but the definition of gss_ctx_id_t_desc_struct is in no installed header.
nfs-utils is accessing ctx->auth_context, ctx->more_flags and ctx->lifetime.
Looking at the heimdal ChangeLog I found this record:

2003-05-21  Love Hörnquist Åstrand  <lha@it.su.se>
        - don't export gss_ctx_id_t_desc_struct and gss_cred_id_t_desc_struct

To me this seems like the NFS people were using in 2005 a feature that had
already been deprecated in 2003, using some obscure internal definitions.

http://nfs.cvs.sourceforge.net/nfs/nfs-utils/utils/gssd/context_heimdal.c lists
only two revisions of this file, one in 2004 and one in 2005. I don't know if
this CVS is in active use, though, as it lacks tags for the latest releases.

Heimdal support seems to be a frequent issue on the nfs mailing lists. I have't
looked through http://www.google.com/search?q=site%3Alinux-nfs.org+heimdal yet.

Summary: not supporting heimdal with nfs-utils-1.0.10 still seems the right
choice, and now I have a better idea why that's the case.

But then force -kerberos if no mit-krb is installed. I am not asking you to fix
Heimdal support, I am proposing to mask heimdal support until it is functional.

(In reply to comment #8)

The use flag is for kerberos, not for heimdal. So when you set USE=kerberos,
portage assumes that you want kerberos support in any package providing it
unless you tell it otherwise. And nfs-utils does provide kerberos, and tells
you that to provide this functionality it needs to have mit kerberos, not
heimdal.
Now you as a system administrator have two options:
1. decide you need kerberos, and replace heimdal with mit kerberos or
2. decide you don't need kerberos in nfs-utils, and
   echo "net-fs/nfs-utils -kerberos" > /etc/portage/package.use

Neither of these options is clearly the "correct" one, so portage complaining
and leaving the choice to the administrator is the correct thing to do.

Of course we could introduce a mitkrb use flag or something like this, to
enable kerberos when it depends on mit, but I see no point in this, because
there are not many ebuilds affected, and for a single ebuild the above
configuration (ehich was already pointed out in comment #2, btw) is less work.

Yes, I do have -kerberos in my package.use line for nfs-utils. But I do believe
when a package is not not to compile with heimdal (which provides the kerberos
virtual), it should be fixed in the ebuild.

Yes, several times I have proposed to have more fine-grained USE flags than
just "kerberos". Kerberos herd people know that and the bugreport is still
opened I think. ;) Anyway, do whatever yoy want, I can live with package.use
file contents.

> Of course we could introduce a mitkrb use flag or something like this, to
> enable kerberos when it depends on mit, but I see no point in this, because
> there are not many ebuilds affected, and for a single ebuild the above
> configuration (ehich was already pointed out in comment #2, btw) is less work.

And, a number of packages supports only MIT-KRB while not heimdal.

comment #6 still stands ...

while comment #7 looks promising, i dont use kerberos myself so i have no way
of verifying it

(In reply to comment #9)
>    echo "net-fs/nfs-utils -kerberos" > /etc/portage/package.use

Before others read this while tired and thus break their whole system:
of course you should append to the file, not overwrite it:

echo "net-fs/nfs-utils -kerberos" >> /etc/portage/package.use

(In reply to comment #10)
> Yes, several times I have proposed to have more fine-grained USE flags than
> just "kerberos".
(And also in reply to comment #11)
> And, a number of packages supports only MIT-KRB while not heimdal.

This sounds like an enhancement request to have a USE flag called "mitkrb".
Doesn't well fit the summary of this report here. Disabling gssapi altogether
for a USE=heimdal would be counterintuitive, as this wont "use heimdal".
Maybe you should open a new request for this.

Still, I don't think that's a good idea. When I decide to use kerberos, I look
at the list of use flags, find kerberos, enable it, and then stop. I would not
notice mitkrb, even if I were using MIT-KRB. And automatic useflags for
installed packages were removed quite a while ago, for good reasons I think.

See bug #16824, #103366, #114759 (maybe offtopic here), #135238, #113052, ...
and look into some closed bugs related to kerberos and see that mostlym the
issue is that "kerberos" kicks in while often only mit-krb is supported (and
not heimdal).

Getting heimdal support probably depends on bug #168509 being resolved in such
a way that alows us to have heimdal and libgssapi installed at the same time.

I wrote an email to heimdal and nfs mailing lists, trying to clarify situation.
You may follow the corresponding mail threads here:
http://linux-nfs.org/pipermail/nfsv4/2007-February/005768.html
http://www.mail-archive.com/heimdal-discuss@sics.se/msg00391.html

So far (while I've been waiting for the heimdal archive to give me the link to
my mail) there has been one reply from an NFS dev. Looks like we should wait
for Heimdal 0.8 to be released.

Created an attachment (id=118725) [details]
heimdal-0.8.1_rc3.ebuild

(In reply to comment #15)
> I wrote an email to heimdal and nfs mailing lists...

Thank you for that thread. It allowed me to adapt Harald Barth's ebuild and get
finally what looks like a working installation of heimdal 0.8.1_rc3.

The ebuild plus several modifications of kerberos dependent packages needed
follow.

Created an attachment (id=118727) [details]
heimdal-0.7.2-0.8.1_rc3.patch

My 0.8.1_rc3 ebuild as a patch against Harald Barth's 0.7.2. Installs into
/usr/heimdal prefix, does not create its own separate slot. krb5-config is
symlinked in /usr/bin and /usr/heimdal/lib scanned by ldconfig after the
installation -- may be not all of this is necessary, but it has seemed to solve
difficulties with kerberos using packages during my strugle with the modified
system.

Created an attachment (id=118728) [details]
nfs-utils-1.0.12-r3.ebuild.patch

Looks like for nfs-utils just changing the kerberos dependence from
app-crypt/mit-krb5 to virtual/krb5 suffices.

Created an attachment (id=118729) [details]
openldap-2.3.35-r1.ebuild.patch

net-nds/openldap is slightly trickier, must be adapted to use krb5-config
instead of hardcoded include and library directories.

Created an attachment (id=118731) [details]
php5-sapi.eclass.patch

dev-lang/php is very tricky, the kerberos path being hardcoded into several
eclasses.

Created an attachment (id=118733) [details]
php5_0-sapi.eclass.patch

Created an attachment (id=118734) [details]
php5_1-sapi.eclass.patch

Created an attachment (id=118735) [details]
php5_2-sapi.eclass.patch

Created an attachment (id=118736) [details]
evolution-data-server-1.8.3-r4.ebuild.patch

gnome-extra/evolution-data-server needs to get includes and libs directories
from krb5-config separately; getting the general prefix does not suffice, and
with the includes and libs configuration might be redundant, but I haven't
tried to remove that one setting. This version works for me, so I'm happy with
it, send it forward, and rest.

this bug is just about nfs-utils ... if you have changes for any other package,
file a new bug report (1 per package)

*** Bug 186389 has been marked as a duplicate of this bug. ***

Will someone commit these patches, please, without asking the user to open
several bugreports? Is it really that necessary? Thanks.

(In reply to comment #28)
> Will someone commit these patches, please, without asking the user to open
> several bugreports? Is it really that necessary? Thanks.
> 

Well, opening separate bugs may be the easiest way to do it after all.
Different packages have different maintainers, and properly sorted bugs in
bugzilla may be the best way to reach them.

I'm going to do that as soon as I try upgrading my heimdal to 1.0. The heimdal
developement is really fast these days -- while in portage we still have 0.7.2
only. So heimdal upgrade first, a bug for it next, and all the related bugs
afterwards.

Let's leave to this bug just changing the dependence of net-fs/nfs-utils from
app-crypt/mit-krb5 to virtual/krb5.

(In reply to comment #29)

Bug #185899 for heimdal upgrade already exists. Should it be added here as one
this depends on?

My ebuild derived from that of Harald Barth has installed successfully on my
laptop meanwhile; it does not depend on so many patches as the ebuild by Bryan
Jacobs, that one apparently continuing the line of the official tree heimdal
ebuilds. Let's move the discussion to the Bug #185899.

(In reply to comment #30)
> (In reply to comment #29)
> 
> Bug #185899 for heimdal upgrade already exists. Should it be added here as one
> this depends on?
> 
> My ebuild derived from that of Harald Barth has installed successfully on my
> laptop meanwhile; it does not depend on so many patches as the ebuild by Bryan
> Jacobs, that one apparently continuing the line of the official tree heimdal
> ebuilds. Let's move the discussion to the Bug #185899.
> 

Most of the Gentoo patches are not strictly necessary, however I did review
them and each had a reason :-).  For example, one of them is required to link
correctly against Gentoo's libdb independently of whether libdb3 or libdb4 is
installed.  One of them externalizes the readline so we don't have a special
Heimdal copy.

They may not be necessary for your situation, but the patches I left in (about
half of the ones that 0.7.2 had) were all things that looked to be positive and
  the versions I posted apply cleanly.  "fewer patches" is not "better".

And, while I did get Heimdal to handle prefixing gracefully, there ARE a number
of other ebuilds in the tree that'd have to be fixed.  I've opened a few bugs
about it.

(In reply to comment #31)
Thanks for your explanation (by the way, why here and not at the heimdal update
bug). I'm going to try adapting your ebuild for 1.0.1_rc1 (not to install one
version twice when there is at least new release candidate available) and
upgrading my system as soon as it accommodates to the 1.0 (Harald Barth's
style) just installed. I think I'll want to stick to the separate installation
directory, since it may solve Bug #168509 -- I'm changing on the fly the
ebuilds that complain about that to use krb5-config, and I'm going to file
appropriate bugs for them.

Should I direct my (sporadic and limited) efforts some specific way to better
help with heimdal on Gentoo? Should I try some tests or experiments? (I'm
currently reinstalling system on my 32-bit Sempron 2600+/Via K8N800 laptop
after the original harddisk has died. I haven't installed app-crypt/libgssapi
yet, nothing I've installed so far apparently required it, so should I, for
example, try, what might installing it do to my system, or rather explore, how
far I can get without it?)

(In reply to comment #32)
> (In reply to comment #31)
> Thanks for your explanation (by the way, why here and not at the heimdal update
> bug). I'm going to try adapting your ebuild for 1.0.1_rc1 (not to install one
> version twice when there is at least new release candidate available) and
> upgrading my system as soon as it accommodates to the 1.0 (Harald Barth's
> style) just installed. I think I'll want to stick to the separate installation
> directory, since it may solve Bug #168509 -- I'm changing on the fly the
> ebuilds that complain about that to use krb5-config, and I'm going to file
> appropriate bugs for them.
> 
> Should I direct my (sporadic and limited) efforts some specific way to better
> help with heimdal on Gentoo? Should I try some tests or experiments? (I'm
> currently reinstalling system on my 32-bit Sempron 2600+/Via K8N800 laptop
> after the original harddisk has died. I haven't installed app-crypt/libgssapi
> yet, nothing I've installed so far apparently required it, so should I, for
> example, try, what might installing it do to my system, or rather explore, how
> far I can get without it?)
> 

Sorry, didn't see you on the CCs for the other bug.

Look at http://www.mail-archive.com/heimdal-discuss@sics.se/msg00392.html - I
was unable to build nfs-utils against Heimdal without the use of libgssapi.  I
think it's just a problem with their configure scripts, but I don't know for
sure.  In an ideal world, we'd only need to install libgssapi with mit-krb5 -
deps for nfs-utils would be:
|| (  
( >=app-crypt/heimdal-1.0 )
( >=app-crypt/libgssapi-0.11 app-crypt/mit-krb5 )
)

Producing a patch to make nfs-utils build with gss support (we don't care about
spkm3, do we?) without libgssapi would be useful.  In fact, it would make the
whole library-collision issue go away as we could just make heimdal and
libgssapi conflict.

yes, we're going to make you file several bugs ... this one is just about
nfs-utils

and once again, the state of this bug is reflected in comment #6

Created an attachment (id=125912) [details]
no_libgssapi.patch

With this patch, nfs-utils builds against Heimdal 1.0 (and NOT against
libgssapi).

So, there are two installation options:
mit-krb5 -> libgssapi <-> librpcsecgss -> nfs-utils <- libgssapi
heimdal <-> nfs-utils <- librpcsecgss <- heimdal
Arrows indicate dynamic linking.  As in, "libgssapi is linked against Heimdal"

Created an attachment (id=126187) [details]
nfs-utils-1.1.0-no_libgssapi.ebuild.diff

Ebuild modification to use Bryan Jacobs' patch. Slight patch of the configure
script added to work well with the pkg-config aware app-crypt/heimdal ebuild
(Bug #185899) and net-libs/librpcsecgss using that (Bug #186392).

Created an attachment (id=126190) [details]
config-details.patch

Patch for the configure script to read correctly the kerberos version for
heimdal as well as for mit-krb5 and to consistently used the librpcsecgss
libraries settings got from pkg-config through testing for prerequisites.

(In reply to comment #37)
> Created an attachment (id=126190) [edit] [details]
> config-details.patch
> 
> Patch for the configure script to read correctly the kerberos version for
> heimdal as well as for mit-krb5 and to consistently used the librpcsecgss
> libraries settings got from pkg-config through testing for prerequisites.
> 

You do realize that this only solves one of two problems, right?  Even if the
link-time works, the packages won't work at run time because of the dynamic
linker's inability to distinguish two different libgssapi.so.2 files in the
LDPATH.  librpcsecgss links libgssapi, nfs-utils links Heimdal, and nfs-utils
links librpcsecgss.  This means that nfs-utils needs to load BOTH libgssapis to
run - which, as far as I know, cannot be done if they can't be distinguished. 
I  could be wrong (I don't know everything about linking), but I'm pretty sure
the only way to resolve this is either to statically link something or to
eliminate the name clash.  The solution I implemented in Bug #168509 is a good
temporary fix, in my opinion.

(In reply to comment #38)

Sorry for unclear commentary.

That patch is only a part of my above mentioned ebuild that uses your patch to
avoid app-crypt/libgssapi.

Thanks to your work, putting of heimdal into separate directory may be in fact
unnecessary and dealing with dumb ebuilds or configuration scripts that make
assumptions on the installation directories may not be needed. I think that
converting them to use more general configuration methods is a good thing
anyway; nfs-utils actually do use those mechanisms, pkg-config for
net-libs/librpcsecgss and krb5-config for kerberos, there are just two
inconsistencies in its configure script.

So I recommend my config patch (or its better analogy if I've got something
wrong), but it's just a small part, your patch for heimdal use is much more
important.

(In reply to comment #38)
> Even if the
> link-time works, the packages won't work at run time because of the dynamic
> linker's inability to distinguish two different libgssapi.so.2 files in the
> LDPATH.  librpcsecgss links libgssapi, nfs-utils links Heimdal, and nfs-utils
> links librpcsecgss.  This means that nfs-utils needs to load BOTH libgssapis
> to run - which, as far as I know, cannot be done if they can't be
> distinguished.

Ensuring different names for the different libraries ensures they both can be
loaded at the same time. But how about the symbols in them? We do have many
symbols common to both implementations, and usually the symbols would be linked
against the first loaded library that does provide them. Only the -Bdirect
linker switch proposed in bug 114008 would specify the library file from which
the symbol should be used. Are we sure that we can rely on a fixed order in
which the libraries will be loaded? Can the library which is loaded later cope
with the fact that some symbols it provides will always be used from the
library loaded first instead? I feel there might be trouble ahead yet.

Is there a chance we get both nfs-utils and librpcsecgss linked against the
same libgssapi?

(In reply to comment #40)
> Is there a chance we get both nfs-utils and librpcsecgss linked against the
> same libgssapi?
> 

Yes, I've already linked both against Heimdal.