GitLab

Allow tmcd to specify speeds of 0 with a warning, and then use
autonegotiation to select media and speed.  Also, if the speed was Gb,
turn on autonegotiation first, then force speed/duplex settings.  This
has to be done because you cannot run at Gb without enabling
autonegotiation -- it's part of the protocol.

Get rid of a noxious warning from the boot config when rc.healthd fails
because it is not supported on...well, just about anything.

Also noticed that the long dead nodetype script was about 10 years out of
date with respect to what nodes it recognized, so for some strange reason
I was compelled to fix it.

Leigh is about to get rid of these anyway, but I thought I would at least
screw up his merge!

The current state of affairs is that you can only set the "link emulation"
style at the experiment level, and that forces link emulation on physical
nodes as well as virtual nodes. Thus you are forced into using either 802.11
tagged vlan emulation or an OS that supports something called "veths" on
physical nodes.

From the comment:

   This is a very, very, very special case. If a non-encapsulating veth
   interface (veth-ne) maps 1-to-1 with an underlying physical interface,
   we want to just use the physical interface instead. This allows OSes
   (on physical nodes) which don't support a veth device (i.e., most of
   them) to talk to vnodes which are using veth-ne style.

   This can go away once we have separated the notion of multiplexing
   links from encapsulating links (a historical conflation) so that we
   don't have to force virtual devices onto physical nodes just because
   some virtual nodes in the same experiment require multiplexed links.

I believe this is left over from a bygone era and should not be needed
(in addition to being wrong, since it always sets the link to 100Mb).
rc.ifconfig (via the generated rc.ifc) will properly configure physical
interfaces that underly multiplexed links.

Note also that the Linux version of the delaysetup script never did this.

and that we return the group mount to the vnode so that it can be
mounted inside the VM.

CreateSliver(), to handle multiple accounts.  This somewhat reflects
the Geni AM API for keys, which allows the client to specify multiple
users, each with a set of ssh keys.

The keys argument to the CM now looks like the following (note that
the old format is still accepted and will be for a while).

[{'urn'   => 'urn:blabla'
  'login' => 'dopey',
  'keys'  => [ list of keys like before ]},
 {'login' => "leebee",
  'keys'  => [ list of keys ... ]}];

Key Points:

1. You can supply a urn or a login or both. Typically, it is going to
   be the result of getkeys() at the PG SA, and so it will include
   both.

2. If a login is provided, use that. Otherwise use the id from the urn.

3. No matter what, verify that the token is valid for Emulab an uid
   (standard 8 char unix login that is good on just about any unix
   variant), and transform it if not.

4. For now, getkeys() at the SA will continue to return the old format
   (unless you supply version=2 argument) since we do not want to
   default to a keylist that most CMs will barf on.

5. I have modified the AM code to transform the Geni AM version of the
   "users" argument into the above structure. Bottom line here, is
   that users of the AM interface will not actually need to do
   anything, although now multiple users are actually supported
   instead of ignored.

Still to be done are the changes to the login services structure in
the manifest. We have yet to settle on what these changes will look
like, but since people generally supply valid login ids, you probably
will not need this, since no transformation will take place.

domanifest returns service configuration info (both static,
administrator info and per-experiment info), and also service hook
configuration.

getmanifest grabs any service configuration, and per-service hook
information.

runbootscript runs one of our client-side boot scripts (or the
replacement the user specified), and any hooks (via runhooks).

We need blobs potentially before rc.keys runs to grab the keyhash, so we
have to grab it right away if the file doesn't exist.

a lan attribute, get it directly from the vlans table.

Also, some tweaks to Ryan's state fixes.  Only run through the reload
states in vnodeCreate if we have loadinfo (i.e., we are in the PCVM_RELOAD
state machine).

The mserver wants to validate nodes by looking up their IP address in the
interfaces table, and vnodes have no interfaces table entries.  So when we
invoke the frisbeehelper in compat mode, do so with the pnode identity
instead. For validation purposes, this is identical.

Is this an issue for non-compat mode? Not right now since all our vnode
implementations that load images make their loadinfo request from the
physical host.  If vnodes start to call the master server on boss directly,
we will have an issue.

This way I don't have to bother with backward compat for frisbee distribution
of blobs.

Add script to start it up with the right options and tweak the rc.mksubboss
script for setting up a subboss.

Properly reset some variables prior to parsing loadinfo info for an image.
This could cause failure if loading multiple images.

Neither of which as causing any problems.

The big backward compatibility issue is that we no longer store running
frisbeed info in the DB.  This means that loadinfo could not return
address:port info to clients and thus old frisbee MFSes could no longer
work.  While not a show stopper to require people to update their MFS first,
I made a token effort to implement backward compat as follows.

When an old frisbee MFS does "tmcc loadinfo" (as identified by a tmcd
version < 33), tmcd will invoke "frisbeehelper" to startup a daemon.
Sound like frisbeelauncher?  Well sorta, but vastly simplified and I only
want this to be temporary.  The helper just uses the frisbee client to make
a "proxy" request to the localhost master server.  The Emulab configuration
of the master server now allows requests from localhost to proxy for another
node.

frisbeehelper is also used by webfrisbeekiller to kill a running daemon
(yes, just like frisbeelauncher).  It makes a proxy status request on
localhost and uses the returned info to identify the particular instance
and kill it.

If downloading big blobs, /var/tmp can fill up.

PREPARE means we are reloading the disk to a default state, so no custom
MBRs allowed.

Client-side builds again, but haven't got node to boot correctly.
Need to get pubsubd installed correctly as a service in place of elvind.

Repeating myself since not everything got committed last time...

In the lastest version of SelfLoader they fixed the taint problem.  It is
literally one line of code (plus updating version string) so I just made
a patch.  Also, fixup boss/ops-install to apply the patch and change the
 default to use the SelfLoader again.