Reduce build systems in master

simo idra at
Wed Sep 7 07:12:25 MDT 2011

On Wed, 2011-09-07 at 09:41 +1000, tridge at wrote:
> Hi Simo,
>  > It's not ok for me.
>  > 
>  > I need a few samba4 libs already and I need to use MIT.
> Can you clarify what you mean here? Are you currently using the s3-waf
> build to build MIT-linked libraries?
> If what you are saying is that you'd like s4 to build with MIT
> kerberos then I think that is a quite separate question from what
> Andrew is asking about. 
>  > So I need to build as mush as I can of the code without having to use
>  > the embedded KDC or heimdal libraries.
> That really comes in two parts. If you don't want to use the embedded
> KDC, then just don't start it (ie. use "server services -= kdc") or
> just don't start Samba as a domain controller.

That's what I've done with my MIT-KDC glue, that's not an issue.

> If you want to build it with MIT kerberos libraries then someone needs
> to put in the time to get all of the current kerberos code to work
> without Heimdal.

Yes, and I will have to. But I mostly care for client libraries and in
general non-AD-DC cases.

>  Quite a bit of effort has been put into that in the
> past, but it hasn't been achieved, and the biggest part of it won't be
> the initial work to make it build/link, the biggest part will be the
> ongoing maintainence effort to ensure it stays working as we discover
> new idiosyncrasies in AD that need kerberos changes. We quite commonly
> need to make changes to the underlying kerberos implementation in
> order to correctly interoperate with Windows. We can't have the
> situation where we need to wait for MIT to release a bugfix before we
> can fix interoperability problems with Windows.

I am ok if you keep using Heimdal for that, of course it would be nice
to have this knowledge of each major Heimdal chnges in some central
README file so that someone that needs to do the same can see what were
the needed changes. It's all obscure right now as nobody documented the
changes that were needed. That information is all buried within tons of
other commits and often very hard to find out.

> For example, Andrew and I had to make a change to the Heimdal KDC code
> yesterday to deal with an issue with cross-domain trusts in a
> forest. We were able to make that change quickly as we have the
> Heimdal sources in-tree, and we know we can work with Love to get the
> change (or an equivalent change) upstream very quickly. I'm not at all
> confident that will work with MIT.

It is not a big deal if the MIT build breaks from time to time, as long
as needed changes are somehow documented in broad strokes so I (or
whoever else is interested) can pick them and make sure they are made to
MIT if necessary.

> So if you really want to build with MIT then I can see only one way to
> achieve that. First off, someone (maybe someone from RedHat?) would
> need to put the effort in to get the current code to build with MIT
> kerberos. Then when it breaks (which it will!) we'd have to just
> accept that it is broken until whoever volunteers to maintain the MIT
> support fixes it. We could not have support for MIT kerberos be an
> autobuild requirement or we will end up regularly stalling our AD
> development for long periods.

This is fine.

> One way to think of this is that kerberos is as fundamental a part of
> Samba as an AD DC as SMB is for Samba as a file server. Can you
> imagine trying to support building Samba3 with an external SMB server
> library provided by another project?

Yes I could, it's done every day in other projects including projects
that depend on samba. And as said above this does not need to stop you
as you can go on with the Heimdal code.

> However, I don't think any of this is relevent to the question that
> Andrew asked at the start of this thread. The source3/ waf build
> currently doesn't allow you to build any of the s4 libraries with MIT
> kerberos as far as I know. 

Yes, I know, and I am not using the waf build. What I said I am not ok
with, is to loose the ability to use MIT in source3 first, but also
elsewhere, at least in client code. I do not want to get in a situation
where I have to become crazy to debug a project that uses samba4 derived
libraries, because they are internally use Heimdal code while the rest
of my app uses MIT.

You can understand how undesirable that would be.


Simo Sorce
Samba Team GPL Compliance Officer <simo at>
Principal Software Engineer at Red Hat, Inc. <simo at>

More information about the samba-technical mailing list