SYSTEM krb5 support matrix for Samba 4.0
obnox at samba.org
Thu May 31 08:20:39 MDT 2012
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
> 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.
> 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
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
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
* 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
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
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
Size: 206 bytes
Desc: not available
More information about the samba-technical