GitLab

First, a liblocsetup.pm for Linux (no target to install it yet.)
Mostly ripped off from the local-node liblocsetup .

Second, some changes to the mkemuman script, so that it will work
on Linux as well as FreeBSD.

fail (usually cause of network dropout), continue to try every minute
until it suceeds.

actually doing that on local nodes before. I guess I'm very ssh
centric (I never type passwords) but that appears not to be the case
for most people!

well. We use a UDP packet to keep it lightweight. If it does not get
through, thats okay, obviously. The return value is just a yes/no flag
that says an update needs to run. Right now, thats just accounts.
This allows us to churn a little less on accounts.
Other cleanups.

when remote is set timeouts when trying to update accounts, and fail
more gracefully.

down on the amount of password file churning by adding new accounts
from the watchdog, but not updating mundane stuff like the gecos and
group list, except via the explicit push from emulab. Eventually this
needs a more complex solution to avoid more work than necessary,
probably by some batch queuing system that handles updates to nodes
that are down.

have checked in some other file with that long comment.

watchdog at the moment, but it will be. Right now it does boot time
stuff; issues tmcc state event so the testbed knows (REBOOTED), does
an account update to get any accounts missed while dead, then sets up
and vnodes (tunnels and such) that where supposed to be running on
the node, then issues a tmcc ISUP event.

After that, goes into a loop doing periodic account update. At some
point it would be good to look for stale vnodes (that could not be
torn down because of network connectivity problems), but there are
some race conditions that I need to work out first.

node reboots. Currently, starts the watchdog daemon.

instead of account update. Doing an account update at boot is nice,
but hardly sufficient.

instead of waiting. This option used by new watchdog daemon that
runs on the RON nodes. No point in waiting if another is already
happening.

more thought, so just leave the directories.

1) Merge in the accounts code that I did for ron. Instead of resetting
   the password file on each reboot, look at the node status to
   determine if the password/group file should be reset. If the
   node is free, reset it. Otherwise, we track changes to the password
   and group file now, so that users can change it and not have their
   changes wiped out at each reboot. I had to do this for the ron
   nodes so that the testbed software would not alter or delete
   already existing accounts; I keep a couple of little dbm files
   listing all the accounts/groups added. The only downside right now
   is if a node is reallocated before it is wiped clean; I plan to add
   an os_teardown phase to experiment termination asap.

2) Add tunnels support. New DB table (tunnels) provides information
   for running vtund to link up to remote nodes. Creates a vtund.conf
   file on the fly, and fires them off. The complication is that you
   cannot do the ifconfigs or the routes until the tunnels are
   connected, so that stuff has to be configured within the vtund.conf
   file on a per tunnel basis. vtund.conf has some sections for
   running commands when tunnels are brought up or down.

3) Damage the routing configuration code that Mike did. To support
   tunnels, as noted above, rc,route is no longer a simple list of
   commands, but a program that adds/dels routes based on the netmask,
   with a special "enable" section for the other stuff. This allows me
   to call it from vtund.conf for up/down on each tunnel'ed
   interfaces, as needed. Quite gross, but no way around it.

4) For remote nodes, add a vnodesetup script, invoked from boss when
   experiments are setup/torndown. This gets the tunnel/route/trafgen
   configuration and runs them. It then goes into the background
   waiting for a death signal, at which time it brings them down and
   cleans out the vnode state.

* tmcd/ron: A new directory of client code, based on the freebsd
  client code, but scaled back to the bare minimum. Does only account
  and group file maintenance. I redid the account stuff so that only
  emulab accounts are operated on. Does not require a stub file, but
  instead keeps a couple of local dbm files recording what groups and
  accounts were added by Emulab. There is a ton of paranoia checking
  to make sure that local accounts are not touched.

  The update script that runs on the client node detaches so that the
  ssh from boss returns immediately. update can also be run from the
  node periodically and at boottime. The script is installed setuid
  root, but checks to make sure that *only* root or "emulabman" has
  invoked it.

* utils/sshremote: New file. For remote nodes, instead of using sshtb,
  use sshremote, which ssh's in as "emulabman", which needs to be a
  local non-root user, but with an authorized_keys file containing
  boss' public key.

* web interface changes: Allow user to specify his own public key in
  addition to the emulab key.

  Add option in showexp page to update accounts on nodes in the
  experiment. I was originally intending to do this from approveuser,
  but this was easier and faster. I will add an option to do it on the
  approveuser page later.

* libdb.pm: Add a TBIsNodeRemote() query to see if a node is in the
  local testbed or a pcRemote node. Currently, this test is hardwired
  to a check for class=pcRemote, but this will need to change to a
  node_types property at some point.

* node_update: Reorg so that there is a maximum number of children
  created. Previously, a child was forked for each node, but that
  could chew up too many processes, especially for remote nodes which
  might hang up. For the same reason, we need to "lock" the experiment
  so that it cannot be terminated while a node_update is in progress.
  Might be to relax that, but this was easy for now. Also add
  distinction between local and remote, since for remote we use
  sshremote insted of sshtb. Various cleanup stuff

* mkacct; When generating a new account, include user supplied pub key
  in the authorized keys file, in addition to the eumlab generated
  key. Both keys are stored in the DB in the users table. Anytime we
  update an account, get a fresh copy of the emulab pub key, in case
  user changes it.