To release Samba 4.0 'as is'
obnox at samba.org
Wed Dec 7 02:06:54 MST 2011
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
Is that something we can agree on?
This is imho the first and most basic thing we need to agree
(or disagree) on.
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.
* 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
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.
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