To release Samba 4.0 'as is'

Andrew Bartlett abartlet at
Fri Dec 9 00:02:32 MST 2011

On Wed, 2011-12-07 at 10:06 +0100, Michael Adam wrote:
> Hi folks,
> Andrew Bartlett wrote:
> > On Thu, 2011-12-01 at 14:51 +0100, Lars Müller wrote:
> > > On Thu, Dec 01, 2011 at 09:46:13PM +1100, Andrew Bartlett wrote:
> > > [ 8< ]
> > > > The problem is that the only smbd that works with Samba4 AD is the smbd
> > > > in master (to get the pdb_samba4 and auth_samba4 hooks, and the correct
> > > > version of the named pipe auth protocol).
> > > 
> > > How hard and risky would it be to make this work with 3.6.2?
> > > 
> > > If that's impossible I'd prefer to negotiate on a timeline for a 3.7
> > > release.  Let us reserve the initial 4.0 release for the release when we
> > > consider the merge as finished.
> > 
> > The changes made between when 3.6 was branched and now are not massive,
> > but they are not of the kind that can be put into 3.6.  pdb_samba4 and
> > auth_samba4 are built as part of the top level waf build, and operate in
> > that integrated build.
> > 
> > I don't mind what our next release is called - be it 3.7 or 4.0 or 4.0
> > AD, as long as it contains the AD server so our users can deploy it.
> I do mind in fact: I think it is very important to call the first
> release that contains the AD server 4.0.
> Let me state the main issues that I think we need to solve/agree on
> before we can move forward to releasing the samba AD server:
> 1. What version should contain which components?
>   As I stated in a previous mail, this is my view:
>   * As soon as a reasonable feature set of the AD server is
>     releasable in a fashion sufficiently integrated with the
>     s3 smbd file server, we should do the 4.0 release.
>   * Until that stage is reached, we should continue doing
>     3.X fileserver releases if new features in s3 are worth
>     releasing.
>   Is that something we can agree on?
>   This is imho the first and most basic thing we need to agree
>   (or disagree) on.

I do not think we have agreement on that, particularly as we already
agreed that our next release would be Samba 4.0.  If we feel we cannot
call our next release Samba 4.0 for some reason, then we should allow a
release of the AD components in the interim as Samba4AD or some other

> 2. Next thing to decide is what components to use together.
> in the AD-server mode.
> * I think I am not misinterpreting our previous discussions
>   when I state that we have agreed to have the s3 smbd file
>   server as the default file server. We can keep the s4
>   file server around and provide an option for enabling it
>   for testing/debugging and existing production setups for
>   some time at least.

If our file server is moving in the direction that metze indicated with
the NTFSA layer, it seems prudent to keep our working modal of such a
pattern (ntvfs).  In any case, the overhead to keep it is quite minimal,
and as a developer, I can assure you that the single process modal it
enables makes it much easier to debug issues in the AD server. 

> * The nmbd needs discussion. The s3 one lacks wins replication,
>   and the s4 one lacks browsing support.
> * It seems winbindd also needs discussion.
> 3. Next is the question of "integration", i.e. how should the
>    main samba daeomon and the chosen s3 components (especially
>    smbd) interoperate? As separate daemons (e.g. smbd spawned
>    by "samba") via the rpc channels and so on (basically the
>    franky approach) and via the pdb_samba4 or pdb_ads modules,
>    or via direct function calls, the smbd part loaded as shared
>    object (basically the libs3compat approach).
>    My impression here is that the franky style approach will
>    probably be the way to a releasable state (it is in fact
>    already used in the univention setup), but this might as well
>    be due to lack of knowledge about the stage of the s3compat
>    efforts.

It would be well worth looking carefully at how the plugin_s4_dc
environment is set up in the test system.  The named pipes are
forwarded, and the plugins provide consistent access to the
authentication and authorization layers.  Tridges s3fs-wip branch is
also worth a look.

The lesson learned from a long time working on the integration effort is
that how the smbd code is started is the smallest detail of the work
required here: the hard work is the behaviour once a connection is made.
Most of tridge's recent changes are not to handle starting smbd, but the
smaller fiddly changes that would hit any integration effort

The big tasks like reconciling (if not merging) loadparm, and smaller
but still important details such as handling GSSAPI secured connections
to s3 rpc pipes are all the same regardless of the 'grand scheme' of how
the smbd code is launched. 

> There are many more techical details and questions about which
> feature should belong to the supported feature set and so on,
> but I think these 3 topics are the fundamental ones to decide
> before we can move forward to releasing a 4.0.
> As for the release itself, when these things are settled and
> the implementation is far enough, we should for v4-0-test
> and v4-0-stable release branches and continue stabilizing
> the code base with betas, prereleases and release candidates
> just as we have done for the past 3.X releases.

Metze made some good points regarding the release process, and I have
addressed that in my reply to him.

Andrew Bartlett

Andrew Bartlett                      
Authentication Developer, Samba Team 

More information about the samba-technical mailing list