To release Samba 4.0 'as is'

[simo]

On Thu, 2011-11-24 at 08:44 +1100, Andrew Tridgell wrote: 
> Hi Andreas,
> 
> > * Samba 4 needs to be able to link against MIT Kerberos. This is a requriement
> >   to be shipped with Enterprise distributions. OpenLDAP and CUPS and other
> >   libraries are linked against MIT Kerberos. It isn't possible to mix this
> >   with heimdal.
> 
> It is perfectly possible to mix these, as the symbol versions are
> different. We have been running with samba linked to both for a long
> time.

Symbl versions are available only on some platforms.

> As to the base idea that it is a requirement for enterprise distros that
> we must use MIT kerberos, I'd ask those enterprise distros to put some
> work in and propose patches. The idea of blocking Samba 4.0 because of
> the political needs of the enterprise distros is not something I like at
> all.

It's not just a political problem, and resources have been put, but it
doesn't help that work was done to actively remove MIT Kerberos compat
(by removing all ifdefs carefully added before the KDC work was done).
Also when people attempted to build bridges they were basically burned
by *demands* of having MIT code immediately present all the features
(libkdb and others) that Heimdal had w/o any regard for the complexity
of such demand and no willingness to allow for alternative solutions to
be integrated like running the KDC in it's own process (krb5kdc) forked
off /usr/bin/samba instead of as libkdb within /usr/bin/samba

But it makes no sense to rehash past mis-dealings, the point is simply
that distributions have some constraints on how they can integrate code,
and you have been made aware of these constraints long ago and
deliberately choose to not care.

At last do not paint it like unreasonable demands that come out of the
blue.

> > * waf needs to support all configure checks which the Samba3 autoconf
> >   provides. There are still options and defines missing.
> 
> could you provide a list and say why they are needed? 
> 
> We have certainly changed configure options in the past between
> releases, so we'd want to know why they are essential, not just that
> they are different
> 
> > * Linking of shared libraries in Samba4 needs to be fixed. For example take a
> >   look at libpdb: 'ldd bin/default/source3/libpdb.so' why is it linked to all
> >   heimdal libraries? http://pastebin.com/8aM8tx8q
> 
> it probably doesn't need to link to them, although I think it's rather
> strange to have this in a list of things blocking a release, as it is
> cosmetic. All of the Samba 3.x releases have been broken in much worse
> ways with regard to shared libraries (for example, lack of symbol
> versions in public libraries).

lack of symbol version in s3 is historic, using it as an argument to say
that s3 libraries were broken is specious at best. When libsmbclient was
create versioned symbols were basically not available on the platform
that were important at that time and still aren't on many platforms so
basing anything on symbol version means dropping support for all those
platforms (ie everything but Linux and Solaris basically).

> > If there is none, then I think distribution will ship smbd as 4.0 and
> > might ship AD as an unsupported package.
> 
> we have a way of doing this, see the s3fs-wip branch in the either mine
> or andrews git repos. That integrates the s3 file server into samba,
> while still leaving smbd to run separately if the user prefers that. 

We seem to have a lot of experiments, but no official solution, nor
anything that is going to be easy to set up out of the box.

This is one thing we need to fix before a 4.0 release IMHO. Or we will
just dump the pain of reconciling later by breaking many of these
'experiments' if/when we resolve to an official solution in 4.1

This is great material for a beta release where it is expected that some
things are unfinished and major components can still change. Not
something you can call a 'stable' release in my book.

> > * We need a working (and tested) migration from existing installations to
> >   Samba 4.
> 
> this falls into two categories:
> 
>  - migration of file/print servers. The easiest answer is for users to
>    just use smbd/nmbd. If we want to move them onto onto the single
>    samba binary then see the s3fs-wip branch

Does the s3fs-wip branch have support with the spoolss and lsa daemons
we have in smbd now ? Afaik all of that is dropped there.

That solution makes sense only for a DC, but requiring completely
different setups for a file server and a DC makes no sense to me.
This is integration work that need to resoled and is a blocker IMO for a
4.0 "stable" release. 

> - migration of s3 DCs to AD. See the migration script that Amitay and
>    Andrew developed, which has been successfully used on real sites.

This is certainly an option, but there is a 3rd.

Use 4.0 as a NT style/improved DC, just like it work now in samba 3.6
which is something some users may want to continue to use as they feel
no need for the complexity or the features of a full blown AD DC or
because they have their own LDAP server that is use by a bazillion other
applications and cannot change the whole DIT because S4 has to be
identical to AD or whatever other million custom plugins or overlays
they use on their current ldap servers.

> > * The autoconf-only build needs fixing (Volker reports broken).
> 
> then Volker or someone else can fix it.

I am at a loss here, I was not present at the last SambaXp, but at least
at the previous one it was agreed to maintain the autoconf build. If
this is not the case can you take a clear stance on this ?
If the autconf build is not maintained then it should be removed ?
Having broken stuff serves nobody interest.

> > * Replace source4 winbindd with source3 winbindd.
> 
> why? I'll follow up in a separate email as to why the functionality
> provided by winbind needs to be very different when you are an AD DC
> compared to when you are a member server.

So we need to keep 2 different winbinds ??

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>