A DRAFT statement on our build systems for Samba 4.0

[Alexander Bokovoy]

On Sun, May 20, 2012 at 11:21 AM, Andrew Bartlett <abartlet at samba.org> wrote:
> 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).
I've been asked already by another person to call it that way.
Theoretically it could work either way (Heimdal or MIT), if we would
fix remaining parts where I intentionally didn't add enable= trigger
depending on the setting of this option due to the fact that the path
is not exercised in non-Heimdal build.

I would like to keep it --with-system-mitkrb5 for time being and by
next release, when we'll make sure both krb5 implementations are
supported for "source3/ daemons + source4/ librs) make a separate
--without-ad-dc switch.

>> 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)
Look into source4/torture/rpc/remote_pac.c,
test_PACVerify_workstation_des(). The test there attempts to see if
krb5.conf [libdefaults] section contains reference to
'allow_weak_crypto' to test DES. krb5_config_get_bool_default() is not
supported in MIT krb5 and appropriate values should be fetched with
use of libprofile library. That library was supposed to be portable
across multiple implementations of Kerberos and also used in other
libraries so it ended up being separate from libkrb5/libkrb5support in
MIT krb5. However, it is not implemented in Heimdal.

We can solve this by making a helper in krb5samba,
smb_krb5_is_weak_crypto_enabled_by_default() which uses either profile
library or krb5_config_get_bool_default(). I just haven't found time
to do that yet. This is the only place where it is used, in
remote_pac.c, and our selftest code enforces 'allow_weak_crypto = yes'
in generated krb5.conf. So removing this check affects only a
standalone version of smbtorture.

-- 
/ Alexander Bokovoy