On 02/24/2013 10:46 PM, Alec Warner wrote: > On Sun, Feb 24, 2013 at 7:17 PM, Michael Mol <mike...@gmail.com> wrote: >> On 02/24/2013 09:48 PM, Alec Warner wrote: >>> On Sun, Feb 24, 2013 at 6:25 PM, Michael Mol <mike...@gmail.com> wrote: >>>> (I really don't have time to actively participate on this list right >>>> now, but I believe that if I bring it up on b.g.o, I'll be directed >>>> here, so...) >>>> >>>> So I'm playing with net-fs/samba-4.0.3, AD and kerberos, and tried to >>>> enable kerberos system-wide on my server. >>>> >>>> No joy, as net-fs/nfs-utils has an explicit dependency on >>>> app-crypt/mit-krb5 (bug 231936) and net-fs/samba-4.0.3 depends on >>>> app-crypt/heimdal (for reasons noted in bug 195703, comment 25). >>> >>> I'm not familiar with anyone using Kerberos on Gentoo. I use it on >>> Ubuntu; but we do not use it with Samba (or at least, if we do, I am >>> not aware of it.) >> >> It's one of the core components of Active Directory, so anyone who puts >> a Gentoo machine on an AD domain will likely be using it. I'm playing >> around with Samba 4, which is supposed to have full support as a >> standalone AD controller. An AD controller is effectively a central box >> that manages and directs domain members to DNS (the host directory), >> LDAP (the user and authorization directory) and Kerberos (the >> authentication mechanism). > > Don't misunderstand, I know what all these things are ;) > >> >>> >>>> >>>> Questions: >>>> >>>> 1) If upstream isn't going to support mit-krb5, then use of samba-4.0.3 >>>> and kerberos demands that things with explicit dependencies on mit-krb5 >>>> either be fixed or not used at all. >>> >>> I'm fairly sure samba supports either kerberos implementation; is >>> there something that makes you think differently? >> >> The explicit dependency on app-crypt/heimdal in the ebuild, and comment >> 25 attached to b.g.o bug 195703. I've taken those at face value; I >> haven't followed up on them myself. >> >>> >>>> >>>> I'm the first activity on bug 231936 in two years...could someone please >>>> look into that one? >>>> >>>> 2) Is it possible to slot mit-krb5 and heimdal instead of pulling them >>>> through a virtual? My suspicion is "no", but I don't know enough about >>>> kerberos to say whether or not it would work, even as a hack. >>>> >>> >>> I'm not following you here. 'slot' means a very specific thing. You >>> are not actually suggesting we use SLOT, you simply want both versions >>> of the library to be installed in one ROOT? >>> >>> I would not advocate this approach. You should strive to have only one >>> kerberos implementation on a given machine. >> >> I'm really not certain, to be honest. It was my impression that slots >> allow for two different versions of a thing to be present on the same >> system, and that their different sonames on the system would lead to >> correct symbol resolution. (Although it would require that the soname >> being sought be adjusted in a dependent program to target the version >> required.) > > mit-krb5 and heimdal are separate packages. They both provide krb > headers and kerb libraries. You could easily patch them to be on the > same system. The problem with doing so is that packages are expecting > only one set of kerberos headers and kerberos shared libraries. > > We have the 'eselect' framework for switching between 'providers' > which we could use in this case (similar to say, the opengl libraries > your system might use.) It is not clear to me if switching providers > is at all safe in the kerberos instance, or if software built against > mit-krb5 would crash if you pointed the loader at some heimdal shared > objects.
Don't misunderstand, I know about eselect. ;) And, yeah, I don't know if thunking/shimming/redirecting is safe in the kerberos context. If it was, there should never have been any question of compatibility. > >> >> Even if it works, I acknowledge it's a nauseating hack for the circumstance. >> >>> >>>> I'm sure explicit dependencies on mit-krb5 and heimdal will continue to >>>> crop up, so (and forgive the nausea this might cause) it might help to >>>> slot mit and heimdal, and have virtual/krb5 depend on the presence of at >>>> least one. >>>> >>> >>> It is likely that explicit dependencies are wrong, and are just bugs. >> >> This is what I found in the ebuild for net-fs/nfs-utils: >> >> # 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) >> >> Which I noted in a comment I attached to bug 231936 (relating to >> net-fs/nfs-util). >> >> In bug 195703 (relating to the samba-4 version bump), there's this: >> >> "Since samba 4 doesn't support mit-krb5, I think we shouldn't depend on >> virtual/krb5 but instead directly on heimdal after the com_err.h problem >> is fixed." in comment 25, dated 2009-11-24 23:07:18 UTC. >> >> Directly responded to later by this: >> >> "Agreed." in comment 26, dated 2009-11-25 10:01:48 UTC >> >> >> > > So nothing recent then ;p Which is exactly why I bring it up; the net-fs/nfs-utils bug is stale, and the reference in the samba package is ancient. (Things directly partaining to samba-4 get bounced into that bug, which really means a stale comment is roughly the same as a stale bug...) > > I think just 'eras' is the only person in the kerberos herd at this > point. I only have a passing interest in it myself (and I'm not > looking to maintain it in Gentoo ;)) Yeah, I know, "if you want it fixed in Gentoo, fix it yourself." I would if I had time. I may have time some day, but I wouldn't bet in that direction. But it'd have been foolish not to at least try to shake the dust off the issue. Apologies if I triggered any allergies... :)
signature.asc
Description: OpenPGP digital signature
