To release Samba 4.0 'as is'
ronniesahlberg at gmail.com
Wed Dec 7 02:31:40 MST 2011
>* The nmbd needs discussion.
Please just let it go the way of dinosaurs.
Netbios names became obsolete a decade ago, just drop support for it and NBNS
On Wed, Dec 7, 2011 at 8:06 PM, Michael Adam <obnox at samba.org> 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
> 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
More information about the samba-technical