Selftest namespaces: Difference between revisions

From SambaWiki
(Created page with "{{subst:NewFeature}}")
 
Line 1: Line 1:
== Overview ==
== Overview ==


'''Added in Samba version:''' ''<The next Samba release containing the feature>''
'''Added in Samba version:''' v4.11


The use of namespaces in the selftest system is only really of interest to Samba developers, or users who want to utilize the ''customdc'' selftest environment.
''<What does the feature do, Why might users care about it, What is the Microsoft-equivalent that a Windows admin might be familiar with, etc>''

Currently the Samba selftest framework uses cwrap socket-wrapper to 'fake' network connections between the Samba testenv DCs. Each DC has a 127.0.0.<id> IP address and socket wrapper uses the '<id>' to work out which DC to pass the packets to.

As an alternative to using cwrap, there is experimental selftest support to use the kernel [https://en.wikipedia.org/wiki/Linux_namespaces Namespaces] to isolate the testenvs. This uses a mix of network namespaces in the kernel, for isolation, and veth tunnel interfaces, to connect together the separate testenv namespaces. The Samba testenv DC becomes more like a containerized system.

For more details on what namespaces are and how selftest uses them, see [https://gitlab.com/samba-team/samba/blob/master/selftest/ns/README selftest/ns/README].


=== How to configure it ===
=== How to configure it ===


To use namespaces instead of socket-wrapper, just add 'USE_NAMESPACES=1' to the
''<Just reference the relevant samba-tool/smb.conf options (your man-page/help documentation should already be clear enough)>''
make command, e.g.

* To run the 'quick' test cases using namespaces:
<pre>USE_NAMESPACES=1 make test TESTS=quick</pre>
* To setup an ad_dc testenv using namespaces:
<pre>USE_NAMESPACES=1 SELFTEST_TESTENV=ad_dc make testenv</pre>

:You can then connect secondary shells to the namespace your testenv is running in. The command to do this is a little complicated, so a helper 'nsenter.sh' script gets autogenerated when the testenv is created. E.g. to connect to the testenv that the ad_dc is running in, use:
<pre>./st/ad_dc/nsenter.sh</pre>


=== Known issues and limitations ===
=== Known issues and limitations ===

Revision as of 04:12, 10 June 2019

Overview

Added in Samba version: v4.11

The use of namespaces in the selftest system is only really of interest to Samba developers, or users who want to utilize the customdc selftest environment.

Currently the Samba selftest framework uses cwrap socket-wrapper to 'fake' network connections between the Samba testenv DCs. Each DC has a 127.0.0.<id> IP address and socket wrapper uses the '<id>' to work out which DC to pass the packets to.

As an alternative to using cwrap, there is experimental selftest support to use the kernel Namespaces to isolate the testenvs. This uses a mix of network namespaces in the kernel, for isolation, and veth tunnel interfaces, to connect together the separate testenv namespaces. The Samba testenv DC becomes more like a containerized system.

For more details on what namespaces are and how selftest uses them, see selftest/ns/README.

How to configure it

To use namespaces instead of socket-wrapper, just add 'USE_NAMESPACES=1' to the make command, e.g.

  • To run the 'quick' test cases using namespaces:
USE_NAMESPACES=1 make test TESTS=quick
  • To setup an ad_dc testenv using namespaces:
USE_NAMESPACES=1 SELFTEST_TESTENV=ad_dc make testenv
You can then connect secondary shells to the namespace your testenv is running in. The command to do this is a little complicated, so a helper 'nsenter.sh' script gets autogenerated when the testenv is created. E.g. to connect to the testenv that the ad_dc is running in, use:
./st/ad_dc/nsenter.sh

Known issues and limitations

<Any outstanding bugs, configurations not supported, etc>

Troubleshooting

<What debug level do you need to run to see messages of interest. Are there any other ways to verify the feature is doing what it should>

For Developers

How to test it

make test TESTS=blah

<Anything else notable about running the tests...>

Where the code is located

<Notable files/functions to start looking at...>

Reference Docs

<E.g. Microsoft specification/section that describes the feature in more detail>