Shellonboss

Danger Will Robinson

So you just got a real account (real shell, not paperbag) on boss. Congratulations! This section discusses condom like security hygiene so that boss is never compromised.

A security breakin on boss would be a disaster! I cannot stress this enough. A breakin on boss could lead to breakins at remote sites cause of the trust relationship between boss and remote nodes. It would also be a huge pain in the ass to recover from, not to mention lots of cranky people.
When you have a real shell on boss; you get a different home dir. Normal users get ops:/users/homedir as their homedir on boss, but if you have a real shell, you get a distinct homedir. This is to protect your dot files, and especially your .ssh directory, from a breakin on ops or an experimental node that is currently mounting your ops homedir (via NFS, which is totally insecure).
NEVER use your Emulab generated ssh keys on boss; it is not passphrase protected!
You should use a different password on boss then ops! Also, when you update your passwd via the web page, only your ops passwd is changed; your boss password is never changed this way.
Technically, you should have a separate key for boss, and not use your private key from Flux/CS since your homedirs are also kept on NFS exported filesystems. But this turns out to be difficult to do for most people cause their desktop is in Flux space.

I keep a separate private key with a different passphrase on my laptop for traveling. This pub key is uploaded to the web interface, and placed by hand in my boss .ssh/authorized_keys file.
All your private keys should be encrypted (require a passphrase to use)! Remember, security is transitive! A breakin to your account in CS can lead to a breakin on ops, which could lead to a breakin on boss.
You should *always* use an ssh-agent to avoid typing passwords and passphrases. Typing a passphrase over the network is a really bad thing to do!

Let me repeat: DO NOT TYPE PASSWORDS OVER THE NETWORK WHEN LOGGING INTO BOSS! USE THE SSH AGENT!
Watch for sudden changes in your logins. If you have been using an agent and not typing a password or passphrase for the last two years, and suddenly boss,ops,whatever asks you for a password, THINK THRICE! Something is odd, and it is better to ask then to risk having your password snooped by some Trojan.
Use good passwords and passphrases! Passwords like "microsoft" are not a good idea, and remember that Unix passwords are often limited to the first 8 chars, but passphrases (ssl,ssh) can be any length and include any characters.
If you were not in the habit of using xlock, then you should now get in the habit.
In order to install the testbed software, you need to be in group wheel, which lets you use "sudo". No password to gain root is required. BE CAREFUL! Think about where you are before you do something like:
```
sudo rm -rf *
```

Building and Installing

Okay, enough about security. Lets talk about building and installing testbed software. This is just one person's approach (Leigh's), others in the group almost certainly do things very differently.

Before continuing, you should be familiar with the source control tools that Emulab uses. Please read the WorkFlow document, which describes GIT and how to access the Emulab source repository. Create your public and private clones as described in the document.

Devel Trees

Each developer uses their own devel tree in /usr/testbed/devel/user in for development and testing. It includes a web tree so you can make changes to web pages, test them using your own web tree, and then install them. Your devel web tree will invoke your devel backend binaries as well. The exception are the long running daemons, which are harder to debug in a devel tree environment.

Typically, your devel tree uses the same database as the main tree, so you want to be careful about making changes that could screw up the DB. Note that we have the ability to run from your own copy of the DB, but that requires another section in this document. If you want to do this, send email and ask!

To create a devel tree:

mkdir ~/testbed
cd ~/testbed
mkdir obj-devel

Also:

# Links your web tree into the main tree so you get to it.
ln -s ../../devel/USER/www /usr/testbed/www/dev/USER

# Need these certs for various parts of the system to work
# properly, and they need to be be identical to the installed
# versions.
mkdir -p /usr/testbed/devel/USER/etc
cd /usr/testbed/devel/USER/etc
ln -s /usr/testbed/etc/emulab.pem .
ln -s /usr/testbed/etc/server.pem .

# There is an install tree on ops, via NFS that is used.
mkdir /usr/testbed/opsdir/devel/USER
cd /usr/testbed/devel/USER
ln -s /usr/testbed/opsdir/devel/USER opsdir

You should join the testbed/emulab-ops projects.
You need to be in the wheel/flux groups. Ask tbops to do this.
You need to have a "defs" file for configure to run. Each developer has their own defs file. Take a look at defs-stoller-emulab. It should be obvious what needs to change; search for stoller. Go ahead and check in your defs file; we sometimes make changes that require all of the defs files to be modified.
If you want to access this web tree from home, be sure to send tbops your IP address so we can add it to the apache config file.
Configure and build your devel tree. Replace USER with your login. BE SURE TO ADD THAT --prefix argument, or you will mess up the main tree.
```
cd ~/testbed/obj-devel
/your/src/tree/configure --with-TBDEFS=/your/src/tree/defs-USER-emulab \
	--prefix=/usr/testbed/devel/USER
gmake
```
Install your tree. Many of the scripts need to be setuid root.
```
cd ~/testbed/obj-devel
gmake boss-install
```
The boss-install target will use sudo to set some executables as setuid root.
You can now use your own binaries by running programs from your devel tree, and your personal web interface is:
```
https://www.emulab.net/dev/USER/index.php3
```

Replace USER with your login.

Main Tree

Okay, to install software into the main tree:

Create a separate tree that keeps a "clean" checkout of the software. I never change this tree, I just keep it uptodate from the repository:
```
mkdir ~/testbed-current
cd ~/testbed-current
mkdir obj-real
```
You should NEVER install from this tree unless you have updated from the repository and rebuilt it.

Configure and build the tree. You do not need to provide any arguments; everything defaults properly.
```
cd ~/testbed-current/obj-real
/your/clean/src/configure --with-TBDEFS=/your/clean/src/defs-default
gmake 
```
WARNING: You should always reconfigure your tree after you update from the repository. Thats cause some files are not rebuilt by the makefiles when they are updated, so it is best to just get in the habit of always doing a reconfigure if any files change (and they usually do!).

Also, multiple people install to the main tree, and so the timestamps on the installed files can trick your makefiles into thinking that files do not need to be installed.
Install the tree.
```
gmake boss-install
```

Developing in an ElabInElab

If you are unfamiliar with our ElabInElab feature, then please read the first section of the wiki page first.

Developing on an ElabInElab is a little different because typically you do not need to bother with development trees or the stringent security measures described in the first section of this page. Of course, you still want to be careful to avoid breakins, or corrupting your DB, since rebuilding your ElabInElab still takes time, and you might lose all your work!

Building and installing the emulab software is fundamentally the same as described in the previous section, except for the defs file that you are going to use; rather then defs-default, you want to specify:

/usr/testbed/src/testbed/defs-elabinelab

or make a copy of it and use that.