A DRAFT statement on our build systems for Samba 4.0

[Andrew Bartlett]

On Fri, 2012-05-18 at 21:15 +0300, Alexander Bokovoy wrote:
> On Fri, May 18, 2012 at 8:38 AM, Andrew Bartlett <abartlet at samba.org> wrote:
> > On Fri, 2012-05-18 at 08:28 +0300, Alexander Bokovoy wrote:
> >> On Fri, May 18, 2012 at 7:13 AM, Andrew Bartlett <abartlet at samba.org> wrote:
> >> > On Thu, 2012-05-17 at 20:54 -0700, Jeremy Allison wrote:
> >> >> On Fri, May 18, 2012 at 01:42:46PM +1000, Andrew Bartlett wrote:
> >> >>
> >> >> > That is why, despite the demand, I'm hesitant to create a 'not AD DC'
> >> >> > build, because there is challenge in defining where to define the line.
> >> >>
> >> >> Doesn't the "not AD DC" build come naturally when MIT krb5 is
> >> >> selected instead of Heimdal ?
> >> >
> >> > Sort of.  Currently the patches just disable the KDC and a couple of
> >> > other things, but leaves most of the build intact.
> >> >
> >> > You would be correct to note that this could be quite a confusing result
> >> > for our users, and we should probably exclude at least the AD server
> >> > binaries and provisioning tools.
> >> Our goal is to have samba 4 client side deliveries produced with MIT
> >> krb5 build + samba3 file/member server. I tried to minimize number of
> >> disabled components to those absolutely depending on Heimdal and not
> >> being able to work with MIT krb5 for a reason to reduce affected code
> >> paths. However, it means certain functionality will make little sense
> >> without KDC-based parts. These components are still built and
> >> installed but not utilized.
> >>
> >> If there is a consensus that these should be disabled, I can make a
> >> separate switch that triggers MIT krb5 configuration and disables
> >> these non-working components as well. We then can call this mode "MIT
> >> krb5" build. There is still need to separate such mode with a pure
> >> switch to MIT krb5 in order to keep possible advancing AD DC
> >> functionality with MIT krb5 when libkdc will become a reality or we
> >> find a way to extend KDC operations in a separate process akin to EPM
> >> work.
> >
> > I think it makes best sense if there is a single mode that:
> >  - Uses and requires MIT kerberos
> >  - Only builds non AD DC components (starting by omitting the AD DC
> > binaries and provision tools, possibly also some libraries)
> >
> > That way we satisfy all these needs with one combination.
> I now have patches to get this working. When one would pass
> --with-system-mitkrb5, samba 4 DC will be disabled and only samba 4
> client bits and samba 3 servers/client code will be built and
> installed. There is also a help message telling explicitly that no
> Samba 4 DC will be built this way.

So, would it make sense to call this or make an alias of
--without-ad-dc?

The detail about this also using the MIT krb5 could be made a
documentation point.  Users who want the internal Heimdal will just
build the lot (even if they don't install or use it all). 

> There are few additions that I had to make to support this:
> - Make possible for SAMBA_MODULE to note that subsystem it belongs to
> is disabled and return early, similar to current handling of enabled=
> parameter to SAMBA_MODULE.
> - Support this behavior for both internal, statically linked, and
> external, shared modules.
> 
> With these changes and few code moves to satisfy server-side specific
> dependencies (mostly areas where headers were depending on
> autogenerated prototypes from server side), I'm getting MIT krb5 build
> without DC binaries and provision tools.

Great!

> I need to fix two outstanding issues in MIT build (current solution
> for weak crypto detection in torture tests is not yet acceptable) and
> squash about 3-4 patches before this work can be considered upstream.

Can you give me some more details here?  I'm sure we can sort it out
(the weak crypto isn't very important these days)

> > Later, if there is development to have an MIT KDC work for Samba4 (not a
> > small task, but you have done well with these so far), then we can
> > revisit this.
> Yes. As explained before, most important parts with specific
> dependencies to Heimdal are marked with SAMBA4_USES_HEIMDAL already,
> both in code and WAF scripts where it is required.

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org