GitLab

Resolve the slice/sliver credential and use that.

tuntest.py now takes three optional rspec files (examples are gec8*), one for each side of the tunnel and one providing the tunnel glue.

Now, if experimenters add users or groups to their nodes, and take
an image, they must explicitly tell prepare to overwrite the master
passwd/group/shadow files in /etc/emulab.  For Linux,
os_account_cleanup tried to update the masters automatically, but
this is not fullproof and can result in the masters getting passwd
hashes from shadow.  Now, a diff of the non-shadow files is printed
from prepare so that at least people can see that the masters need
to be manually updated.

type default. Let the other side figure it out.

unavailable error.

From: Leigh Stoller <stoller@flux.utah.edu>
Date: July 1, 2010 11:35:08 AM MDT
Subject: Re: Event System Issues

Mike and I exchanged a couple of email messages. Mike has indicated
that we should drop all Elvin support. A nice goal, but not possible
cause of the basic mistake I made in "version 0" of the event code.

What we *can* do is stop *generating* the elvin hashes completely in
Version 1. We also drop the elvin_gateway, thus no longer supporting
ancient images that are still using the real elvin libraries. I am
okay with this. Comment if you have objections.

Version 0 elvin-compat (these are pubsub clients with ELVIN_COMPAT=1)
binaries will work cause of the magic ___elvin_ordered___ flag, which
actually tells the client that the hmac is a pubsub ordered hmac. (I
know, I am just great at naming things). I just add this little flag
to events in version 1.

Version 0 non-elvin-compat binaries will not work, but this is okay.
The only case this matters right now is Protogeni, where we need to be
able to talk to non-elvin-compat binaries at remote sites. I have
solved this with a version0 gateway as described in the previous
message. ops will run a secondary pubsubd on another port, and the
protogeni client startup code will have clients connect to that
pubsubd instead. This is mostly tested, and it can roll out to other
sites as needed, once we roll out cooked mode.

Version 1 clients are fully interoperable.

Lastly, we still need to be able to compare elvin HMACs coming from
existing version 0 elvin-compat binaries (from our many many system
and custom images). Thats cause all those images are still going to be
generating the HMACs in elvin order, and so the server programs on ops
(event scheduler, tevc, etc) need that elvin hashing code built into
it. See first paragraph.

Anyway, I have all this done and tested on my elabinelab. I had wanted
to make it in time for code freeze, but not enough time to get proper
debugging, so I will push once code freeze is over.

Lbs

node. Currently this is rewritten to a disk_image tag in the
emulab-ops project of the CM the node is allocated from. This works
nicely for STD images since all Emulabs tend to have the same STD
images, but will not work for localized images. All of this image
stuff in cooked mode needs a bunch of work.

Also add support for talking to non elvin-compat nodes on other CMs by
having the event clients contact another pubsubd instance on the home
boss, which will gateway the events back and forth, munging them as
needed.

daemon that will gateway non elvin-compat clients into an elvin compat
server, as for protogeni cooked mode).

Also add support for talking to non elvin-compat nodes on other CMs by
having the event clients contact another pubsubd instance on the home
boss, which will gateway the events back and forth, munging them as
needed.

node. Currently this is rewritten to a disk_image tag in the
emulab-ops project of the CM the node is allocated from. This works
nicely for STD images since all Emulabs tend to have the same STD
images, but will not work for localized images. All of this image
stuff in cooked mode needs a bunch of work.

non-root. Really no reason to hide these.

it to the event system.