Pushing users into the pit of success - stories from the Samba 3→Samba 4 transition.
Channel: Linux.conf.au 2015 -- Auckland, New Zealand
Date: 16/01/2015

Andrew Bartlett
http://lca2015.linux.org.au/schedule/30191/view_talk
This is a talk about building complex software that 'just works' for the
vast majority of our users, lessons learned in that process and the
complexity of managing a broad project that stretches from simple
command line utilities to a whole Active Directory domain controller.

Samba needs no introduction to most attending linux.conf.au, but it is
worth explaining the full scope of the project, because our software
is certainly used well beyond our mantra of "Opening Windows to a
Wider World".  Indeed, on many distributions uninstalling Samba
(specifically tdb) uninstalls the whole desktop!

Samba's progression up the stack starts with the provision of basic
libraries like tdb and talloc to client tools and libraries
(libsmbclient, libnet and others).  Built on top of those are our file
server, and what we call a 'classic' domain controller, the sort of
like NT4.  Further built on top of that is our Active Directory Domain
controller, including Kerberos KDC and LDAP server, and beyond that
are the hooks that projects beyond such as OpenChange reuse.

All in all, it is a complex stack, but one that we must make 'just
work', because the alternative (leave the administrator to piece
together the parts) littered with horrible failures.

Yet it is not an easy road, and has created a number of 'NIH' moments
that have become embedded in our code-base.

It is also a talk about upgrades, about unwritten and unenforced rules
and where the rules of 'of course X is always true' meets the
realities of deployed software on live networks.  

This will also be a talk with a few war-stories, the rules we expected
our existing domains to honour, and how far from those expectations
our users actually were, and the steps we have taken to help even the
most idiosyncratic domain move on to become a Samba AD DC. 

I will argue for software that enforces restrictions rather than
trusts that the administrator knows best.  I will argue that in
complex systems, that there should be one, scripted installation route
to a working system, not a web-full of conflicting HOWTO documents,
and that a secure, centralised authentication system should be easier
to set up than the server it was installed on.