Looking to once again re-bundle LDB

[Alexander Bokovoy]

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.

-- 
/ Alexander Bokovoy