Confused about samba4 & s3fs

[Andrew Bartlett]

On Thu, 2012-08-16 at 10:33 -0700, Jeremy Allison wrote:
> On Thu, Aug 16, 2012 at 06:58:12PM +0200, steve wrote:
> > On 16/08/12 16:10, Arvid Requate wrote:
> > >Hi,
> > >
> > >maybe I should have explained more clearly,
> > 
> > No, that's a good POV.
> > 
> > All we need is confirmation from the devs of what they want. Which is it?
> > 
> > 1. recommend we test s3fs
> 
> This.
> 
> > 2. do not use s3fs
> > 3. use ntvfs
> > 4. use smbd on a member server S3 box for everything
> 
> Try this :-).
> 
> > Yeah, I know. 'It depends'. Some rough guidelines would be great.
> 
> See above :-).

Very well put Jeremy!

So, to put a bit more flesh on this discussion.

The issue here isn't the maturity of the file servers - indeed, both
ntvfs and smbd file servers are quite mature for their respective
roles.  

As only the smbd file server is seeing further development, we have put
great efforts into integrating it with the AD DC.  This continues to be
the bulk of my daily work. 

The reasoning behind my initial comments to steve are:

 - It is simply best network design to, on a network the scale of
steve's, to have file services distinct from domain control services.
It allows the file server or DC to be upgraded separately and provides a
separation of roles.  While we have issues in replication, multiple DCs
are valuable on large networks, so having them similar to each other
(not also doing other things) is also good network design. 

 - The key difference between deployments of our latest file server as a
file server and as part of the DC (so called s3fs) is not the file
server, but the integration of the file server with the rest of the
DC.  

 - Specifically, the winbind implementation (a key part of that
integration) in the AD DC (in the binary 'samba') simply isn't as
featured as the implementation in winbindd.  Features such as the ones
requested by steve are just not there, and are not expected to be
added. 

 - The winbindd implementation in the 'samba' binary also has other
issues under loads such as squid authentication:
https://bugzilla.samba.org/show_bug.cgi?id=9097

 - The configuration of the file serving component is in part
auto-configured by the DC.  We load modules to ensure we always show the
correct NT ACL for example, as well as passdb and authentication
modules.  We also have no experience regarding the compatibility of
other 'file server' configuration options on the AD DC.

 - The development of the smbd file server in Samba 4.0 is very, very
hectic at the moment.  The team's track record of test based development
gives us great confidence, but we have traditionally been quite cautious
in recommending pre-release file servers to our users. 

Given that we have always said that the file server in the AD DC is
optimised for serving sysvol, my view is that situation remains.  At
this stage, we only really have the resources to recommend this much.

That isn't to say that the file server is not useful on an AD DC:  We
know folks will want to run Samba 4.0 on home networks and Small
Business Server replacement projects, with just one combined file server
and DC.  The simple requirements of the installation will easily be
tested before deployment, and I expect everything will work quite well,
as they always have done. 

We also expect this situation to improve, and while the larger network
design suggestions won't change, Samba 4.1 may include a change to the
winbindd implementation, which will in turn make even more
demanding/exotic multi-role deployments practical. 

Finally, I'll try and tidy up the statements in the release notes, some
of which reflect an over-abundance of caution from when we first pulled
the switch to s3fs.  

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org