Registration

Samba being a classic single-threaded daemon faces requirements that make the use of helper threads necessary. Helper threads and a forking daemon do not really play well together.

This talk will highlight the problems that Samba has to face serving it's clients needs and its approach to make use of the Linux kernel's features to make multi-threading possible in a thread-agnostic daemon.

The team at Catalyst IT has been busy implementing quite a range of new features to Samba Active Directory. In doing so, there have been some unintended, but generally positive, consequences which have changed the way we have been developing new features. One such consequence has been from our new backup tools which has resulted in a huge improvement in our ability to test networks more reliably. Particularly at larger scales, it has made identifying performance issues significantly easier.

For users, these side-effects should also be appreciated like the potential for more reproducible lab networks, as we continue to build tools and features like Windows but a little differently (and maybe a little better).

This talk will go over some of the basics of the new backup and restore tools for AD domains, and cover some of the work that was done to make simple group policy objects (GPO) portable. It will also include some of the changes in how we have been doing testing and some of the impacts to the selftest system. Hopefully there'll be something interesting to everyone.

How Samba processes incoming pathnames is a black art, and very old code that has been developed over twenty years. Listen to one of the developers go through the pathname processing code, function by function and explain how and why it got to be this way, and what we can do about it. This talk will be of interest for Samba VFS developers as well as general SMB1/2/3 fileserver developers.

To the newcomer, Samba's command line user interface appears to be a haphazard jumble of scripts and binaries with options and design principles that fade in and out of use according to some esoteric pattern. The tools report back to the user with a eclectic mixture of python tracebacks, NT_STATUS error codes, and friendly messages that sometimes neglect to say what was attempted and if it worked.

To the expert it is actually worse, because in the time it took them to become an expert another layer of new functionality has settled over the UI. The expert realises there is no underlying principle--the interface just collects up like leaves in a drain--and memorises the minimal set of finger-patterns to get their job done.

Can we do better? Without breaking anybody's scripts and finger habits? Could samba-tool provide consistently useful feedback? Is automatic shell-completion possible? Can we get beyond a simple text UI without falling into a horrific expanse of GTK checkboxes or web based graph visualisations?

Some of these questions might be answered.

What can be achieved, in terms performance and reliability, by isolating SMB3 message marshalling and unmarshalling into a separate layer? This talk will describe experimentation with a low-level SMB2/3 message

handling engine.

Managing AD via terminal commands can be alien to many Windows users and admins, so providing them with familiar tools could ease their transition. This talk will demonstrate new GUI tools, which can run via either qt in a graphical environment, or also via ncurses in the terminal, which simplify the administration of users and groups in an AD domain. These tools emulate the familiar ADUC and ADSI tools in a Windows environment.

cifsd is a new SMB server implementation for the Linux kernel,
intended to provide higher performance than user-space analogues. 
This talk will start with a brief introduction to CIFSD architecture
(high level) and its main design goals: outline components, their
responsibilities and communication protocols. In the second part
of the talk we will focus on current state of affairs and our future
development plans.

Samba 4.10 is the first release to support Python3 (and also Python2)

• The reasons why we are moving to Python3

• Some details that attempt to explain what will be supported and in which version.

• Some of the challenges encountered migrating to Python3

• Lessons learned

On the way to Samba 4.0 a more feature-complete DCE/RPC server was designed and implemented which allows asynchronous execution, a fundamental requirement for some services such as the witness protocol.

This talk will present an approach to DCE/RPC server reunification where the server core has been extracted from the samba4 implementation and a new PIDL compiler class generates code able to invoke samba3 RPC interfaces implementations.

The topics will cover the dissection of the DCE/RPC server to present the components that compose it, the analysis of the initialization to identify the parts that can not be shared, the execution of the common processing loop, the new PIDL compiler class and finally some problems such as the local dispatching (rpcint vs irpc binding handles) and how they have been solved.

With Samba 4.10 and older versions, Samba is currently implementing its own cryptography primitives for commonly used ciphers and hashes(AES, RC4, SHA-1/SHA-2, MD4 and MD5). Writing cryptographic functions is not that hard, you do not even need to understand the math behind a cryptographic primitive you want to implement to be able to construct a set of functions that correctly encrypts and decrypts a ciphertext.

Cryptographers keep saying you should not implement your own crypto. History of Samba shows why it is indeed a sensible suggestion to anyone.We look into why we implemented our own crypto primitives and why it was a bad idea.

This talk will explain the benefits of moving to a proper crypto library for an open source project implementing a complex network-facing protocol set. We also will look into how this helps us to become a predictable code base to be able to pass a FIPS 140-2 certification.

Adding SMB3 multichannel as a fully supported feature to the Samba SMB server has been a long and difficult journey. Not only some aspects of the protocol regarding oplocks and leases needed to be properly

researched and tested - also the implementation design needed to be adapted to the way SMB clusters are run with CTDB. The talk will give an update to the completeness of the multichannel feature and also explore other aspects of clustered SMB with Samba and CTDB using the Gluster filesystem.

In the Microsoft world, AD is well established as "the only" source of identity information for workstations and servers. However, in the opensource world, we have a variety of artisinal solutions to identity management, every one with pros, cons, complexities and hurdles. Sadly as a result, almost no business gets the arcane system right, and wide issues exist.

We want our Linux and BSD machines to "just work" in the same way that Windows "just works" with AD. But surely this is a dream? I'll explore the current changing landscape of services and authentication in opensource and application deployment. From there I will talk about the ways that Samba 4 can be turned into the default LDAP server for use in opensource environments. Finally I'll talk about the future of applications and how Samba 4 could step up to be the default directory server in any environment.

This presentation will provide details of improvements to CTDB's testing infrastructure and to Autocluster.

CTDB's test suite was created in an ad hoc manner to run a limited range of test cases. This included running multiple "local daemons" to allow CTDB's clustering, messaging and database capabilities to be tested. As more test cases appeared, the local daemons functionality was extended in more ad hoc ways, but was still embedded in the "simple" test suite. The "local daemons" support was recently extracted into a standalone script that relies on CTDB's test mode. While this is still used by the "simple" test suite, it can also be used for standalone debugging and could be integrated into Samba's autobuild to test some Clustered Samba capabilities.

Autocluster is a tool for generating virtual clusters for testing Clustered Samba. The first version was written by Tridge one weekend after he became bored of recreating virtual clusters by hand. Autocluster predates nearly all modern virtual machine deployment applications and system configuration/deployment applications. It was a bash script that started off small and grew. Eventually, after we saw some examples of modern tools, Autocluster started to gain some structure with a view to replacing subsets of the code with those modern tools. Michael Adam's 2015 SambaXP talk about Vagrant provided more motivation but time was never available for a rewrite. However, recently bit-rot, test system upgrades and an inability to work with

recent Linux distributions provided the necessary motivation. Autocluster has now been rewritten as a small Python script that reads configuration from a YAML file, creates a cluster with Vagrant and configures it with Ansible. As a result it is now about 5.5K lines smaller and much more maintainable.

In the third talk talk of the quest to get a more modern programming language supported in Samba we are re-visiting the re-visit to finally get it right (tm).

Last year, we saw a proof of principle project implementing a DNS-like protocol in Rust, and then using the server-side parser for it from a C server providing the rest of the business logic. When the time came to figure out how to handle memory ownership between C and Rust functions, my solution was to implement a Rust wrapper to Samba's Talloc memory management library and keeping the C process in charge of all allocated memory. This turned out to be an unpopular design decision.

So this time around we'll stick to handling the Rust-allocated memory in Rust while giving the project another go. In addition, the talk gives an overview of the current state of automatic C binding generation from Rust and other features relevant for integrating Rust into a real world project.