[Samba] Is the samba-dc package on Centos 7 gimped?
steve at steve-ss.com
Mon Oct 20 13:48:01 MDT 2014
On 20/10/14 21:17, Rowland Penny wrote:
> 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
>>>>> 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
>>>>> 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.
>>>> 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
>> 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
>> 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.
> 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
SLES use the same argument for their lack of samba DC. However, it is no
problem to build one using the their mit libraries. Is it not even
possible to build on red hut at all?
More information about the samba