Looking to once again re-bundle LDB

[Kees van Vloten]

On 14-02-2024 20:39, Alexander Bokovoy via samba-technical wrote:
> On Срд, 14 лют 2024, Rowland Penny via samba-technical wrote:
>> On Wed, 14 Feb 2024 20:48:32 +0200
>> Alexander Bokovoy via samba-technical<samba-technical at lists.samba.org>
>> wrote:
>>
>>> On Срд, 14 лют 2024, Michael Tokarev via samba-technical wrote:
>>>> 14.02.2024 20:21, Alexander Bokovoy via samba-technical:
>>>>> On Срд, 14 лют 2024, Michael Tokarev wrote:
>>>>>> 14.02.2024 17:46, Alexander Bokovoy wrote:
>>>>>> ..
>>>>>>> We do rebuilds of the whole stack in Fedora if bots detect
>>>>>>> samba ABI had changed. So for us it is not a problem.
>>>>>> It's easy to do with "current" Fedora release.  It's entirely
>>>>>> different question when you want to provide current samba to a
>>>>>> previous Fedora release.  And that's where the problem is, -
>>>>>> providing "backports" of current samba to previous releases of
>>>>>> distributions.
>>>>> If you are building packages on top of RHEL by replacing existing
>>>>> packages there, you are responsible in fixing all breakage that
>>>>> new packages would introduce. It is maintenance work that one
>>>>> needs to consider when providing alternative builds, regardless
>>>>> of a distribution.
>>>> Exactly.  Ditto for debian. Even debian backports, while being part
>>>> of official debian and using debian infrastructure, needs
>>>> additional work. It is good if a new version does not introduce
>>>> incompatibilities, - this way it can be provided at less work to
>>>> previous releases.
>>>>
>>>> ..
>>>>>> Yeah, it would be best to build samba against mit krb5, if it
>>>>>> were a supported way.
>>>>> It is supported. It just provides a bit different set of features
>>>>> compared to Heimdal-enabled Samba builds. See our talk at
>>>>> SambaXP'23 for details.
>>>> I know it works, and it's kind of supported, with
>>>> --enable-experimental-mitkrb5-kdc or something.
>>>>
>>>> The thing is: personally I don't have resources to support it by my
>>>> own in debian. Everything I do there, I do at my "free from work"
>>>> time, I don't know how all this AD-DC thing work.  After all, my
>>>> only intention when I come here was to fix a bug in samba form
>>>> which I suffered in my work (had to restore lots of user profiles
>>>> lost due to samba data corruption), and am still there because it
>>>> was not "just flip this one bit and it all works" thing :)  So I
>>>> entirely rely on upstream samba for almost all support work.  And
>>>> there, MIT-Krb5 AD-DC is "not supported".  Hence that's what I mean
>>>> above :)
>>> I think that statement of 'not supported' added more damage than
>>> helped. I hope we can move forward from that by acknowledging there
>>> are different use cases for Samba AD that involve configurations
>>> where one or the other Kerberos implementation is better suited. For
>>> example, not everyone needs read-only domain controllers in all
>>> environments. Or not everyone even need to use Windows (shocking,
>>> right?) as domain members. ;)
>>>
>>> There are still issues at how to present two separate builds in a
>>> distribution but that's a different story, not an upstream problem. At
>>> some point we have to bite a bullet and move forward.
>>>
>> Hi Alexander, I have nothing against using MIT on a Samba, in fact I
>> would welcome it, but according to this wiki page:
>>
>> https://wiki.samba.org/index.php/Roadmap_MIT_KDC
>>
>> These are things that Heimdal does but MIT doesn't:
>>
>> Add auth logging support
>> Allow starting the MIT KDC with multiple worker processes
>> Define API for a libkdc in MIT Kerberos
>> Running as a Read only domain controller (RODC)
>> Support for Claims
>>
>> Now the page was last updated on the 18 July 2023, so some of the above
>> may now work.
> Audit logging is possible on MIT Kerberos side for years, it is not
> implemented fully on Samba side. libkdc is needed for RODC support but
> is unlikely to come without a serious investment from a party interested
> in it. Support for claims needs a small fix on MIT side and a minor
> effort on Samba side, it is in our plans.
>
> Overall, it is better to define a focus for the specific use cases and
> admit they are being covered by these different implementations.
>
> Samba AD/MIT Kerberos combination is far from being 'unsupported' and
> being 'experimental'. What was agressively enforced over mailing lists
> as an unsupported claim made more damage than helped, in my opinion.
>
>
>> It is my opinion that Samba has enough on its plate trying to get the
>> Heimdal version to the full 2016 functional level without having to get
>> the MIT version to the same level.
>>
>> If all the work is done to the MIT version and it comes up to the same
>> level as the Heimdal version, will RHEL ship a version of Samba that
>> can be provisioned as an AD DC ? (I think I know the answer to that
>> one) If this answer is no, then what is the point of carrying out any
>> work on the MIT version ?
> In my opinion you are mixing completely different questions (and
> possible answers) together for no good reason. This does not help at
> all.
>
> As an upstream contributor, I do not see a request for RHEL to ship (or
> not) Samba AD as a definitive reason to make (or not) Samba AD/MIT
> Kerberos 'supported' or 'unsupported' upstream. I am together with other
> fellow developers providing this support already: we do support Samba
> AD/MIT Kerberos in Fedora for years. As a major Linux distribution's
> package maintainer, I do have enough data to consider a
> distribution-wide context for this configuration being useful to be
> supported.
>
> Heimdal is missing quite a few other features that make MIT Kerberos
> attractive for a distribution wide integration of Kerberos features in a
> modern world as well. Granted, most of that is not used or cannot
> currently be used directly by Windows and by extension of that might not
> be interested for Samba AD consumers willing to integrated with Windows
> systems directly. However, it does not mean Samba integration is not
> important in a pure Linux world.
>
> Hopefully, I'll be able to show something concrete this year's SambaXP
> as well.

I am quite sure you will be doing just that :-)

After the developments presented at FOSDEM, and seeing what is already 
flowing into 4.20, one can only look forward to the next SambaXP!