selftest/ns/README

   1 The scripts in this directory are experimental and are used to create testenvs
   2 in separate linux namespaces. This avoids the need for socket-wrapper.
   3
   4 What are Namespaces
   5 ===================
   6 Namespaces allow the kernel to segregate its system resources (files, CPU,
   7 etc), so that different processes only see the set of resources they are
   8 allowed to use. There are several different types of namespace: network,
   9 user, process, file, IPC, and so on.
  10
  11 Key points to grasp are:
  12 * Each type of namespace gets managed separately by the kernel, i.e. process
  13 namespaces are managed separately to network namespaces, which are separate
  14 to user namespaces. These scripts give each testenv its own network namespace,
  15 but otherwise they all still share the same user/process/etc namespace.
  16 (In future, we may want to give each testenv its own process and user
  17 namespace, to better mimic a production DC).
  18 * Namespaces are created using the 'unshare' utility. The new selftest
  19 namespaces are anonymous/nameless, and so the different namespaces are
  20 identified by the PID of the processes running within the namespace
  21 (typically samba).
  22 * Linux supports nesting namespaces within namespaces. In this case, each
  23 testenv DC has its own network namespace, which is a child of the overarching
  24 selftest namespace (which itself is a child of whatever namespace you run
  25 'make test' from - usually this would be the root namespace).
  26
  27 How does it work?
  28 =================
  29 Normally when 'make test' is run, every testenv uses a 127.0.0.x IP address
  30 and socket-wrapper passes the packets between them.
  31
  32 With namespaces, we can use real IP addresses and have the packets pass through
  33 the kernel's IP stack normally, as it forwards them between namespaces.
  34
  35 We use veth interfaces for this. veth is a type of virtual interface supported
  36 by the kernel. veth interfaces come in pairs, and act as a tunnel - any packets
  37 sent on a veth interface simply end up as received packets on the pair veth
  38 interface.
  39
  40 We create a new veth interface pair for each testenv, and use them to connect
  41 up the namespaces. One end of the veth pair is added to the main selftest
  42 namespace, and the other end is added to a new namespace that we'll run
  43 samba in. E.g.
  44
  45 selftest.pl  veth21-br ------------------------ veth21 samba (ad_dc_ntvfs)
  46              10.0.0.11                          10.0.0.21
  47  Namespace 1                                       Namespace 2
  48
  49 However, we need to run multiple different testenvs and have them talk to
  50 each other. So to do this, we need a bridge interface ('selftest0') to connect
  51 up the namespaces, which essentially just acts as a hub. So connecting together
  52 multiple testenvs looks more like this:
  53
  54 selftest.pl     +-- veth21-br ------------------------ veth21 samba (ad_dc_ntvfs)
  55                 |                                      10.0.0.21
  56     selftest0 --+                                        Namespace 2
  57     10.0.0.11   |
  58                 +-- veth22-br ------------------------ veth22 samba (vampire_dc)
  59                                                        10.0.0.22
  60  Namespace 1                                             Namespace 3
  61
  62 The veth interfaces are named vethX and vethX-br, where X is the
  63 SOCKET_WRAPPER_DEFAULT_IFACE for the testenv. The vethX-br interface is always
  64 added to the selftest0 bridge interface.
  65