[Samba] Is the samba-dc package on Centos 7 gimped?

Rowland Penny rowlandpenny at googlemail.com
Mon Oct 20 13:17:37 MDT 2014

On 20/10/14 20:04, Simo wrote:
> On Sun, 2014-10-19 at 16:19 +0100, Rowland Penny wrote:
>> On 19/10/14 16:08, Nico Kadel-Garcia wrote:
>>> On Sun, Oct 19, 2014 at 3:51 AM, Rowland Penny
>>> <rowlandpenny at googlemail.com> wrote:
>>>> On 19/10/14 00:06, Nico Kadel-Garcia wrote:
>>>>> I can expect RHEL to do that for me in new OS releases, it's part of
>>>>> what I pay money for, and sharing the expertise in a bundled set for
>>>>> others is part of what I appreciate from the open source and freeware
>>>>> worlds.
>>>> So you are going to rely on red hat coming up with a working samba DC
>>>> package, good luck with that and I hope you are prepared to be patient.
>>>> Samba 4 was released nearly 2 years ago and red hat still hasn't got a
>>>> working package, why ? because they insist it must work with mit instead of
>>>> heimdal, it probably would have been quicker for red hat to drop mit.
>>>> Rowland
>>> MIT Kerberos was, and remains, the reference Kerberos stack, so the
>>> reluctance to migrate from it is understandable.
>> So what, this, where I come from from, is known as 'cutting your nose
>> off to spite your face' or in other words, they could have had a samba
>> DC nearly two years ago and still have worked on getting mit kerberos to
>> work.
> No Rowland, we could not have done it, or we would have done it.
> It was largely my decision at the time, if you want to blame someone.
> And I am a Samba Team member, it was not an easy decision.
> But it was fully based on technical grounds and was the only rational
> decision for RHEL/Fedora.
> The reason is that samba come with client libraries too and you can't
> create a properly working OS where the same binaries include 2 different
> versions of the same library. Besides potential symbol clashing (that
> was later hidden with compiler and dynamic loader tricks) there are
> other issues with features available in one and not available on the
> other. Ie there are features MIT provides and RHEL/Fedora uses that are
> not supported in Heimdal code and would cause issues if some client code
> does not support features other code relies on.
>>> And yes, I see some
>>> development reports on Red Hat and Fedora getting this striaghtened
>>> out in the foreseeable future.
>> I think they said this nearly two years ago ;-)
> Yes, and it takes time to unravel samba code that has been built w/o any
> regard for compatibility to the MIT implementation. For some reason when
> Heimdal was introduced in the AD part of the code, MIT compatibility was
> *actively* removed. It took time to back trace and fix a ton of
> dependency as well as compatibility functions and reinstate or rework
> them.
> We started with making the client side work first. Which is why there is
> any 4.x code at all in RHEL. Then we started working on the server side
> which was a bigger task.
> We'll eventually get there, but things do not just happen fast because
> we'd like them to, we want code that works with either MIT or Heimdal
> and that is maintainable long term, not some quick'n'dirty hack.
> HTH,
> Simo.
Thank you very much for explaining that Simo, the information available 
(well what I could find with a quick search) just basically says 'you 
cannot have a samba4 DC on RHEL', even the text message in the 'DC' rpm 
isn't that informative, it really needs a combination of that message 
and what is written above.

OH and OK, it is all your fault :-D


More information about the samba mailing list