SYSTEM krb5 support matrix for Samba 4.0

[Michael Adam]

Hi Andrew,

Andrew Bartlett wrote:
> I recently did some work on our krb5 support, and so as not to waste the
> background I obtained, here is the matrix of what krb5 versions we
> support when we are asked to use the system kerberos lib, with both
> build systems.
> 
>               MIT              Heimdal
> autoconf:     1.8 minimum      recent (> 1.1 at least, needs DCE_STYLE gssapi)
> waf:          1.9 minimum      current (needs to essentially match lorikeet-heimdal)
> 
> Of course, on any waf-compatible platform we can build the bundled
> heimdal internally.  
> 
> We agreed on the MIT 1.8 minimum in order to use real GSSAPI on the
> server.  
> 
> The waf minimum of 1.9 is due to gss_krb5_import_cred, which is needed
> to import a credentials cache into a GSSAPI context without using a
> global environment variable. 
> 
> The autoconf Heimdal minimum comes from the need to support gss_wrap_iov
> and DCE_STYLE GSSAPI.  The waf Heimdal minimum comes from the fact that
> we need to provide plugins for the KDC.
> 
> Either way, the Heimdal krb5 1.1 shipped by default in FreeBSD 8.2 and 9
> isn't able to provide the things Samba needs.  
> 
> Volker,
> 
> This means that we cannot restore ADS support to your FreeBSD
> development environment unless you install MIT krb5 1.8 or are willing
> to use the waf build. 
> 
> I hope this clarifies things, and helps others with a summary of the
> situation,

Thanks for that summary. This is very helpful!

Let's see what the implications are (for the pure s3 file server
build, something that is certainly used out there and will be for
a while):

The basis for the problems that we discuss is this:

>>>>> There are systems out there that neither have a recent <<<<<
>>>>> (enough) version of kerberos nor python available.     <<<<<

For all other systems, we can somehow work around with the above
matrix (without the need to fiddle with the system-installed
libs and so on), given one is willing to accept some compromise:

  * On a system with too old kerberos but appropriate python
    available (e.g. SLES11), we can use the waf build to produce
    a samba build using shipped heimdal which should work.

    The same applies to FreeBSD 9 in principle, but it has been
    reported that the waf build had problems (build failures)
    there that did not show up on recent linux platforms, so
    the hurdle might be higher on non-Linux systems.

    This assumes that one is ok with using the waf build!...

    BTW: We should make sure that the configure runs have the
    same results under waf and autoconf. I know that Andrew and
    Andreas (and others) have put some effort into this in the
    past, but maybe we should make this scriptable, so that
    we have a (top lvl make) test facility to compare the results
    (say config.h) of waf and autoconf configure. This is
    actually imho a prerequisite for establishing the waf build
    as a replacement for autoconf for the pure fileserver
    installation.

  * On a system with recent krb5, one can use the autoconf build
    (if one does not want to or can not use the waf build).

So how can we make it possible or more easy for those other
systems without recent python and krb5, to get to the goal
of a full samba(3) build?

Possible internal solution:

  * Add support for building and using shipped heimdal from
    the autoconf build.
    This would be an internal change that would work on any
    system without the need to change system installed
    libs/programs.

    It would make it easier for people who for some reason
    can not or do not want to use the waf build to still
    be able to build a recent file server.

If the waf build is an option but python support is lacking:

  * Can we make it very easy to build an appropriate python?

    I assume that the python code is too big to ship along
    samba, but can we provide mechanisms (scripts/makefiles)
    that allow for a very easy building of python, e.g. using
    a python tarball url on the web or a local path where
    the builder has dropped an appropriate tarball and then
    build a local version of python only to be used for the
    waf build?

    I think something like this was already done by
    Tridge(?) and others for the build farm. Can we integrate
    such a mechanism as an optional step in our build process?



So the fundamental questions/proposals are these:

1) Can we force alignment of the configure results
   between autoconf and waf build (s3-part) or at least
   provide a mechanism to chech these?

2) Can we add internal heimdal support to the autoconf build?

3) Can we add building (if not shipping) of appropriate pyhton
   as an option to the top level build?


Cheers - Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20120531/b22ffa22/attachment.pgp>