[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] kerberos, virtuals, rattling cages
From:       Michael Mol <mikemol () gmail ! com>
Date:       2013-02-25 23:59:03
Message-ID: 512BFAC7.6070202 () gmail ! com
[Download RAW message or body]


On 02/25/2013 12:48 PM, Michael Mol wrote:
> On Mon, Feb 25, 2013 at 2:21 AM, Matthew Thode
> <prometheanfire@gentoo.org> wrote:
>> On 02/24/13 20:25, Michael Mol 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).
>>>
>>> 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 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 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.
>>>
>> so, read the thread so far, and I think you are over-complicating things
>> with slotting.  I use kerberos at home (more or less just to learn it,
>> worksforme, etc).  I chose MIT.  From what I understand MIT and heimdal
>> are mutually exclusive (can not operate with eachother) and that heimdal
>> is what windows uses.
> 
> I think they're effectively the same on the wire, but I'm not sure.
> I'm studying the issue.

For the record: On my system, the only two changes I had to make to
enable kerberos (largely) system-wide were:

1) mask net-fs/nfs-utils (it was only being brought in by the kerberos
flag, anyway)
2) mask dev-libs/openssl[kerberos]. See
https://bugs.gentoo.org/show_bug.cgi?id=459220

Both of those had explicit dependencies on app-crypt/mit-krb5. After
that, everything built fine for app-crypt/heimdal. (No idea how well it
works; I've still got a ways to go to prove/disprove any of that.)

My purpose in originating this thread isn't (and hasn't been) all about
getting AD operating correctly and pervasively. My purpose is in getting
the package dependencies for kerberos sanified and cleaned up. If that
means there are upstream issues, I can prod them, too, I suppose.

(I do still wonder what all breaks if assumption is "allow mit-krb5 to
be installed, rather than heimdal".)


["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]