To release Samba 4.0 'as is'

[Stefan (metze) Metzmacher]

Hi Andrew,

sorry for the late reply.

Am 22.11.2011 07:13, schrieb Andrew Bartlett:
> I would like to propose that we proceed to making a pre-release of Samba
> 4.0 in the next month (ie, before Christmas), and that we propose to
> release Samba 4.0 'as is' regarding major features.
> 
> To be clear, I propose that the DNS server work continue, and we seek a
> resolution of the best approach here over the time between now and a
> release, but we do not block a release on this point.  (I am confident
> however that those involved will have a good solution, and even the
> current flat file is clearly good enough for our many users). 
> 
> I also propose that we do not make the major architectural changes
> between now and the release to change file server or winbind
> implementations for the AD DC.  Instead, we continue to build on the
> massive efforts already made here over the next few months, but we will
> not change the default behaviour for a 4.0 release.
> 
> This will give the vendors (Univention and Resara) and our numerous
> users who are building on top of Samba 4.0 alpha releases a stable
> release to move to, based on the current architecture, before we make
> the change to a common file server for Samba 4.1.  

At least Univention uses 'smbd' and 'nmbd' (with cldap proxy mode, to
get browsing support)
by default.

I think we have to support such setups for a final 4.0 release.

Currently they need to use some hacks to rewrite idmap.ldb to avoid
IDMAP_TYPE_BOTH, as the smbd file server can't handle them yet.

Like all the work to get to a common code base again, this is not
a black or white thing. We can't just take one or the other
components, we have to actively do some work to get all pieces together.
This often means that we have to provide two solutions, until one can
take over all features from the other.

I'm fine with using the source4/smb_server for simple AD domain controllers,
which just expose NETLOGON and SYSVOL, for a 4.0 release and then
change the default in 4.x.

But both alternatives have to work and use the same persistent storage
for acls and other NT style stuff.

Currently one server uses 'user.DOSATTRIB' while the other one uses
'user.DosAttrib' to store dos attributes.

I recently fixed smbd to read all formats of security.NTACL.

We have to go through all this little details to make sure
an admin can use one or the other file server, without
destroying persistent information like ACL.

I hope to get some time to file bug reports for all things
I know, which would block a release.

> This will mean we continue to ship smbd, nmbd, winbindd, samba etc as
> found in the current alpha releases. 

For a release we also have to make sure that everything from source3
is in a good state (I think they currently are, but we need to recheck
before the release). In the same way as if it were a 3.7.0 release.

> With this plan, and with the quality brought about by our continuous
> integration approach, I think we can make a Samba 4.0 release in a
> reasonable time-frame, perhaps with a final release in about three
> months time.  

My hope was to have a least 20 alpha releases, then 3-5 beta releases
followed by a few pre releases and then a few rc releases.
This would be very similar to what we've done for 3.0.0 years ago.
(I'd guess something like 6 month from now).

But all this depends on the blocker features/bugs, we'll define for the
release
and the time that's required to fix them.

We also think we need to make 100% sure that an admin can't write invalid
data via LDAP. We should treat our sam.ldb like a file system!
And for production file systems everybody would expect that
it's not possible to corrupt from any user space application!

I'll try to file some bugs for this.

> I do wish to be clear that I'm certainly not abandoning the idea of a
> single file server, and I know many others on the team have also
> invested great amounts of their own time in this effort.  It is
> important not only for NAS vendors who wish to add AD to the NAS (an
> idea I raise with every NAS vendor I get the chance to speak to), but
> also our users who still regularly ask for a combined release with the
> AD server, file server and print server all present in the same runtime
> installation.

Yes, it's very important to get everything together again
and goal for the long term future needs to be that we have just one
component
for each thing.

I hope to finish the smb1/2 client library work this week,
which means we'll use the same low level library for all parts of
master. This is the ground work to write a common the low level dcerpc
layer.

During the work on SMB2.x features, I'll try to combine messaging layers
of source3 and source4, so that all components can talk to each other.
As we plan to use something like IRPC in the SMB2 server.

I think a common messaging layer would be really good for a final 4.0
release.

BTW: we'll have to make sure, we list all thing we want to support
     and also the things we'll not support!

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20111129/73a2d575/attachment.pgp>