GitLab

(to tftpboot-elabinelab.tar.gz) so we can evolve it
separately without affecting the advertised tarball.

install.  This had been fixed for ops-install, but not boss.

Enable windows support by default now.  This ensures exports_setup creates
samba shares.

* rc.mkelab - modify logic s.t. --disable-windows is passed to configure if
  WINSUPPORT is not set.

constructed. This is avoid the emulab source code leaking out too
easily.

We leave it on boss, since at the moment mere users do not get shells
on inner boss, so getting the source code that way is a bit harder
(although not that hard of course). Besides, for development its much
nicer to have that source left on boss.

longer comes from the project directory (really, my source directory
in the various projects). Instead, the source code comes from one of
two places:

* Using fetch on the inner ops and boss, make a special request to the
  outer webserver to return a tarball, currently stored in
  /usr/testbed/src, and created by toplevel makefile target "elabinelab".
  So, in your object tree (preferably one that is pure, without any of your
  own hacks) run "make elabinelab" and it will create the tarfile for you.
  The tarball is returned only to elabinelab experiments providing the
  experiment secret key (a variant of the existing spewrpmtar file stuff).

* Using the standard tarfile install command, albiet indrectly cause of how
  we hide all of the elabinelab NS goo. So, in your NS file you can do:

	tb-elab-in-elab 1
	set ::TBCOMPAT::elabinelab_source_tarfile \
			"/proj/testbed/tarfiles/emulab-src.tar.gz"

  Which will arrange for this tarfile to be installed in /usr/src, and then
  copied to the approriate place later when inner boss and inner ops are
  setup. The tarfile should be created in the top of your testbed source
  tree. This is given preference over method 1 above.

XXX Currently the tarfile is unpacked in /usr/src cause install-tarfile
does not create the target directory. As soon as we have new images, I'll
move this unpacking to a more suitable place.

emulab config returned by tmcd.

are setup with static routing/ifconfig by adding proper goo to rc.conf.
Previously, I was asking outer boss on each bootup, but this approach is
unworkable in a firewalled setting.

dying to see whats going on. These changes can go into new images; it will
be ignored in non ElabInElab experiments;

rc.inelab: A terrible hack that I now regret. The whole point of this
script to allow inner boss/ops to 1) play by the standard state machine goo
(ISUP) for the outer emulab. That way os_setup, node_reboot, etc all work
when dealing with setting up the inner elab. 2) Since the inner
control can fall on any of the interfaces (as picked by assign), we
need to still do ifc/route configuration using tmcd. At the time I did
this, I expected that swapmod/swapin/swapout would be possible and
that boss/ops would be coming in on different nodes using different
interfaces for the inner control net, and that I would want to ask
each reboot. Well, I think swapping an inner emulab is a really long
way off, maybe so far off I'll be retired by that time.

rc.mkelab: A lot of very ugly code that turns a node into an inner ops
or boss. I won't bother to describe this code other than to say the
operating model for this rev is to create a fully functional inner
emulab based on the DB state provided by the outer emulab. Currently,
the current testbed software is expected to be in the /proj tree, and
a full boss/ops install is done, followed by all kinds of
customizations (like building accounts for members of the project,
etc) to make it a fully function emulab with just a single project;
the project in which the inner emulab was created.