Decomposition and Samba Technical Architecture (follow on from Dan's SambaXP talk)

[Andrew Bartlett]

Dan,

In your SambaXP talk, which I've finally had a chance to listen to over
the past few days, you suggest a post-presentation discussion of Samba's
technical architecture, to take advantage of what you see as a coming
step-change in Samba adoption thanks to the great work of OpenChange, or
to address the 'cloud' use case. 

First, while I got a copy of the slides you sent privately, but would it
be possible for you to post your conference slides publicly, so others
can the gist without needing to listen to the 30min talk?

Until then, the audio link is here:
http://sambaxp.org/fileadmin/user_upload/SambaXP2014-AUDIO/thu/track1/sambaxp2014-thu-track1-Dan_Shearer-TheBigNewsthatNeverQuiteHappen.mp3

Second, as I mentioned in the other thread, I fundamentally disagree
that Samba is failing or has failed.

However, the reason I wanted to start this particular thread is that I
see the few technical matters you address rather differently to how you
describe it.  It wouldn't be the first time two team members have
disagreed, but I thought it would be helpful to discuss them more fully
and perhaps i/we could write up a wiki page to avoid future confusion,
or to suggest and plan concrete steps with well understood benefits.  

In short, my perspective is that while Samba operates a monolithic build
process and git repo, it is much more 'decomposed (and I dislike that
term)' than you might expect.  The 'monolithic' approach is actually a
disguise, primarily for backwards compatibility and to avoid accidental
presentation of an incomplete protocol implementation to our clients.

For example, we use IRPC inter-process messaging extensively in the AD
DC, because while we launch from a single binary each task in 'server
services' runs in it's own child by default.  In the 'source3' code, the
RPC services can likewise run in an independent daemon mode, as
demonstrated in the s3dc 'make test' environment.

I'll also point out that Since Samba 3.4 we have been able to forward
RPC pipes to external processes, and use DCE/RPC extensively internally
(such as between the RAP/winbindd and RPC servers). This is something
which became key to the 'franky' design that inspired the final Samba
4.0 architecture.  Samba 4.2 improves this further, with unix domain
socket based inter-process messaging now standard across the whole
code-base. 

You mentioned the OpenLDAP back-end and MIT KDC work as examples of
'decomposition'.  I'm not sure if you are aware, but while both these
efforts have significant reasons why they are important, being able to
start the KDC or LDAP server independently is already possible by
carefully specifying the 'server services' parameter.

Finally, perhaps I'm way off-base, and this isn't at all what you meant.
You didn't explicitly suggest any changes in your talk, did something
come of discussions after the presentation?

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba