GitLab

Stargate client-side boot support.

Similar to linux, but the sg linux distribution is based on debian, so some
things are a little different.

WARNING: if you do a client-install in a cross-compile environment
(with DESTDIR set), watch out for bogus symlinks in <root>/etc/rc*.d!
Have to fix these up by hand in this case.

Also note that the stargate rc script doesn't yet start the robot pilot
daemon - Tim said he needed to do finalize some stuff w.r.t. this, so
he would take care of modifying the rc script.

The ntp settings are still not ideal.  Even though the root fs is on a
journalling jffs filesys, its still not good to write to it regularly.  Need
to point the ntp drift file off into /var (ramfs)

ELABINELAB: allow SSLXMLRPC from inside to boss.  Needed for frisbee load
	of images.
ALL: allow through all ICMP for now.

Only place the last bit of the address in the reverse file, not the
entire IP address.  Still, this whole file will probably only work for
a /24 net...

Tweaks for updating the robotmap:

	* robots/emc/emcd.c: Only send updates to loclistener when the
	position actually changes.

	* robots/emc/loclistener.in: Listen for SETDEST events and update
	the destination position in the nodes table.  Also update the
	orientation column.

	* robots/emc/test_emcd.config, robots/emc/test_emcd.sh.in: Update
	for changes elsewhere.

a certain number of tries go to sleep for a while; the idea is that they
try to recover once the obstacle has moved.

local...)

make it mean 10 thousand. We were running overflowing a 32-bit int
when we had 214 of these things - now we can go to 214 thousand.

cameras more intelligently.  Changed a debug level in vmcd.c .

* If there is a destination for a rebot, display that as a shadow circle.
  Draw a light grey line from source to destination.

* If an orientation is in the location_info table, the current location
  circle gets a stick drawn in that direction.

* If the destination has an orientation in the nodes table, the shadow
  circle gets a stick drawn in that direction.

* I added a little bit of code so that labels are drawn on top if the
  orientation stick would draw through it. I'm sure that will interact with
  cropping badly if a node is right at the edge of the picture.

option, because Mike uses --enable-windows while building imagezip on Ops.

This prevents needing a goofy rule just to allow DNS access for setting
up the other rules.

on the command line.

values to NULL.

	alter table nodes add destination_x float NOT NULL default '0';
	alter table nodes add destination_y float NOT NULL default '0';

Unlike other coords, these are meters and translated to pixels
later when displayed (trying to head in the right direction ...)

  looking for /proj/$pid/exp/$eid/rc.mkelab. This file constantly
  changes, so its convenient to just copy it over (since it is the
  script that drives inner emulab creation).

* No longer copy over rc.inelab; let it get installed when the inner
  boss/ops is created, from the testbed source tree that gets copied
  over.

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.

this was never done ... I guess no one uses tarfiles much.

more checking of the config file and its contents.