GitLab

N.B. This fix is now update 599. What was update 599 is now 600.

This is for the per-experiment root keypair. Note that the sitevar is not
"hooked in" yet, just wanted to get it in place for testing.

interfaces and interface_state table to card_saved,port_saved. The
primary keys are dropped and new ones added for node_id,iface.

1. Get rid of direct queries to wires and interfaces, use library.

2. Allow node:iface on the command line for ports.

3. Add -i option to print out results in node:iface. Eventually we want
   to flush card.port output, but lets wait on that for a while.

4. Switch from card,port to iface lookups.

5. The DB change adds iface to the port_counters table, no longer using
   card,port. Eventually flush them.

interfaces table for auto creating interfaces, in case I need to back
them out in a hurry.

interfaces.  Also add a couple of generic interface types (40G and 100G).

with something other then their row index. Something unique in fact.

1. Add display_start and display_end datetime fields for scheduling when
   an announcement should be shown/retired.

2. Add priority integer for ordering messages, default is 3.

1. Add a unique uuid for a shared lookup token with the web UI.

2. Add pid_idx for targeting announcements to projects (issue #258).

Provide automated setup of an ssh keypair enabling root to login without
a password between nodes. The biggest challenge here is to get the private
key onto nodes in such a way that a non-root user on those nodes cannot
obtain it. Otherwise that user would be able to ssh as root to any node.
This precludes simple distribution of the private key using tmcd/tmcc as
any user can do a tmcc (tmcd authentication is based on the node, not the
user).

This version does a post-imaging "push" of the private key from boss using
ssh. The key is pushed from tbswap after nodes are imaged but before the
event system, and thus any user startup scripts, are started. We actually
use "pssh" (really "pscp") to scale a bit better, so YOU MUST HAVE THE
PSSH PACKAGE INSTALLED. So be sure to do a:

    pkg install -r Emulab pssh

on your boss node. See the new utils/pushrootkeys.in script for more.

The public key is distributed via the "tmcc localization" command which
was already designed to handle adding multiple public keys to root's
authorized_keys file on a node.

This approach should be backward compatible with old images. I BUMPED THE
VERSION NUMBER OF TMCD so that newer clients can also get back (via
rc.localize) a list of keys and the names of the files they should be stashed
in. This is used to allow us to pass along the SSL and SSH versions of the
public key so that they can be placed in /root/.ssl/<node>.pub and
/root/.ssh/id_rsa.pub respectively. Note that this step is not necessary for
inter-node ssh to work.

Also passed along is an indication of whether the returned key is encrypted.
This might be used in Round 2 if we securely implant a shared secret on every
node at imaging time and then use that to encrypt the ssh private key such
that we can return it via rc.localize. But the client side script currently
does not implement any decryption, so the client side would need to be changed
again in this future.

The per experiment root keypair mechanism has been exposed to the user via
old school NS experiments right now by adding a node "rootkey" method. To
export the private key to "nodeA" and the public key to "nodeB" do:

    $nodeA rootkey private 1
    $nodeB rootkey public 1

This enables an asymmetric relationship such that "nodeA" can ssh into
"nodeB" as root but not vice-versa. For a symmetric relationship you would do:

    $nodeA rootkey private 1
    $nodeB rootkey private 1
    $nodeA rootkey public 1
    $nodeB rootkey public 1

These user specifications will be overridden by hardwired Emulab restrictions.
The current restrictions are that we do *not* distribute a root pubkey to
tainted nodes (as it opens a path to root on a node where no one should be
root) or any keys to firewall nodes, virtnode hosts, delay nodes, subbosses,
storagehosts, etc. which are not really part of the user topology.

For more on how we got here and what might happen in Round 2, see:

    #302

Add new table experiment_keys to hold RSA priv/pub key pair and an SSH
public key derived from the private key.

Initialized when experiment is first created, I have not done anything
to set the keys for existing experiments yet.

But for testing, you can do this:

	use lib "/usr/testbed/lib";
	use Experiment;

	my $experiment = Experiment->Lookup("testbed", "layers");
	$experiment->GenerateKeys();

the unsigned int.

needs admin approval. I can figure this out from the data, but easier
if we just set a flag.

server. Not sure what to do with it yet, need to get with Jon.

partition/partitions/stored/virtual

In the beginning, the number and size of experiments was small, and so
storing the entire slice/sliver status blob as json in the web task was
fine, even though we had to lock tables to prevent races between the
event updates and the local polling.

But lately the size of those json blobs is getting huge and the lock is
bogging things down, including not being able to keep up with the number
of events coming from all the clusters, we get really far behind.

So I have moved the status blobs out of the per-instance web task and
into new tables, once per slice and one per node (sliver). This keeps
the blobs very small and thus the lock time very small. So now we can
keep up with the event stream.

If we grow big enough that this problem comes big enough, we can switch
to innodb for the per-sliver table and do row locking instead of table
locking, but I do not think that will happen

experiments created in that project. For now, we are going to set this
on the Cloudlab project to prevent 500 users from being created on
those experiments, since thats where most people coming from the trusted
signer live.

1. Okay, 10-15 seconds for me, which is the same as forever.

2. Do not sort in PHP, sort in javascript, let the client burn those
   cycles instead of poor overworked boss.

3. Store global lastused/usecount in the apt_profiles table so that we
   do not have to compute it every time for profile.

4. Compute the user's lastused/usecount for each profile in a single
   query and create local array. Cuts out 100s of queries.

Our storage server don't always quite make it through the OS boot to
DHCP in 120 seconds.

If we assign a unique constant random value to every user, and spit that
out in the initial ga() stuff at the beginning of each page load, google
can combine interactions from the same user across different devices.
Say, like work vs home computer.

have been machine converted from rspecs to geni-lib scripts.