A DRAFT statement on our build systems for Samba 4.0

[Alexander Bokovoy]

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.

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.

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.

> 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.


-- 
/ Alexander Bokovoy