Turns out we have not been installing (via slicefix) the local site certs
on nodes after they have been imaged. We haven't noticed because we don't
usually use SSL-enabled tmcd. Leigh noticed because we do use it in the
script that locks down ARP entries.

(Also, add support for user to change container entrypoint at runtime.
Note also that the server side now stores the entrypoint/cmd/env
attributes as base64url-encoded virt_node_attributes, so that we can
just use the existing table_regex for those values.)

We add a new runit service (/etc/service/dockerentrypoint) to
clientside/tmcc/linux/docker/dockerfiles/common to handle the
entrypoint/cmd/env/workingdir/user emulation.  From the comments:

  Docker's semantics for ENTRYPOINT/CMD vary depending on if those
  values are specified as arrays of string, or simple as single strings
  (which must be interpreted by /bin/sh -c).

  Handling all the quoting possibilities in the shell is a major pain.
  So, this script handles the basic stuff (in particular, sourcing env
  vars, because we want the shell to interpret them!) -- then execs our
  perl companion script (run.pl) to deal with the entrypoint/command
  files that libvnode_docker::emulabizeImage and
  libvnode_docker::vnodeCreate populated.

  libvnode_docker creates these single-line files in /etc/emulab/docker
  as either string:hexstr(<entrypoint-or-cmd-string>), or
  array:hexstr(a[0]),hexstr(a[1])... .  This allows us to preserve the
  original type of the image's entrypoint/cmd as well as the runtime
  entrypoint/cmd, and to preserve the exact bytes for the eventual final
  call to exec.

  The static files builtin to an emulabized image are
  /etc/emulab/docker/{entrypoint.image,cmd.image}, and those created
  dynamically at runtime if user changes the entrypoint or cmd are
  bind-mounted to /etc/emulab/docker{entrypoint.runtime,cmd.runtime}.

  Given the presence (or absence!) of those files, this script
  implements the emulation, based upon the content in those files.

(Also link the dbus machine-id file to the one systemd will generate on
the next boot.  This seems safe and correct.)

Certain things (like systemd's dhcp client) use the machine-id as a seed
for derived values.  For instance, systemd's dhcp client offers a
ClientIdentifier in the new client style, and some servers will return
the same address to *all* requesting clients, instead of returning only
based on source MAC.  Can't have any of that confusion.

tables from outer Emulab, use dumpuser/newuser since in a target system
setup, we do not do any DB state transfer from the outer Emulab.

Also add partial support for 11.2 MFS (just kernel right now,
binaries are still 10.3).

hardware address.
Fixed a egrep expression which was preventing the matching of said list.

(If the DOCKER-USER chain exists, we now can enable Docker's iptables
handling because its rules will no longer supplant ours.  But then, we
also have to permit the default network and our control network to reach
the outside world; that behavior seems to have changed somewhere along
the line.)

Docker containers may be (and default to, and in the shared host case,
must be) deprivileged; thus, they cannot mount devices, much less tell
the kernel (via iscsi userspace tools, etc) to make devices.

Therefore, we must setup any storage backing devices (temp LVs, iscsi
attachments) outside the container.  This commit makes that possible for
rc.storage and linux liblocstorage.  Basically, rc.storage now supports
(for the Linux liblocstorage and Docker) the -j vnodeid calling
convention; and if it's being called on behalf of a vnodeid, it uses
per-vnodeid fstab for any mounts, storage.conf for its state; etc.

I modified libvnode_docker to *not* create virtual networks for
remote blockstore links, because those are pinned to /30s, and thus I
have no client blockstore link address to place on a device in the root
context.  However, I (ab)used the existing Docker network setup for the
blockstore links, and that all happens the same as it used to; we just
no longer create the Docker virtual network nor attach the container to
it.

Finally, I modified tmcd dostorageconfig slightly to return
HOSTIP/HOSTMASK for remote blockstores; and now
libsetup::getstorageconfig will use HOSTIP in preference to its own
HOSTID->HOSTIP translation.  I had to do this so that libvnode_docker in
the root context would not have to go through the mess of translating
HOSTID on behalf of a vnode.

We now try to emulate any simple COPY <src> <dst> instructions via rsync
prior to image build.

This *does* mean that artifact builder scripts must be careful to create
all necessary dirs according to the base image semantics, because the
base image content is not there when we emulate the COPY instructions.
For instance, many of the modified Dockerfile-runit and
runit-artifacts.sh files depended on built runit packages being
installed into /tmp in the final image -- but they didn't create the
/tmp dir because the COPY instruction they used was running atop a
fully-populated base image that already had /tmp.  Thus, the
runit-artifacts.sh scripts had to be changed to create /tmp with the
proper permissions.

as per issue #440.

pass along the IP of the FreeBSD OPS jail to XEN client setup, and havit
add that IP to the iptables rules (antispoofing) so that ops can talk to
the control network.

These scripts should not ever exit, lest they block other hook
scripts from running.  return isn't really correct
either, but at least it won't prevent future scripts from running;
it will just nullify some of the logging dhclient-script does.

Also fixes an unrelated minor bug.

We cannot simply source into the shell; must stringify values with
whitespace.