All new accounts created on Gitlab now require administrator approval. If you invite any collaborators, please let Flux staff know so they can approve the accounts.

Commit a3321542 authored by Leigh B. Stoller's avatar Leigh B. Stoller

Add mini howto file for people who get real accounts on boss.

parent f71e3057
So you just got a real account (shell, not paperbag) on boss.
Congratulations! You are now one of the chosen few; those who are trusted
to build and install testbed software that 10s of thousands of people rely
on everyday, and to exercise condom like security hygiene so that boss is
never compromised. Okay, lets get serious.
* 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
* 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 ops or an
experimental node that is currently mounting your ops homedir (via NFS,
which is totally insecure).
* NEVER use your Emulab generated key on boss; it is not passphrase
* 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!
* 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!
* 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 your use "sudo". No password to gain root is required.
Okay, enough about security. Lets talk about building and installing
testbed software. I'll describe how I operate; other in the group almost
certainly do things very differently.
* 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.
* To create a devel tree:
mkdir ~/testbed
cd ~/testbed
mkdir obj-devel
cvs checkout testbed
* 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
../testbed/configure --with-TBDEFS=../testbed/defs-USER-emulab \
* Install your tree. Many of the scripts need to be setuid root.
cd ~/testbed/obj-devel
gmake boss-install
sudo gmake post-install
If you forget the post-install, many things will break. Don't run the
boss-install target as root, just the post-install.
* You can now use your own binaries by running programs from your devel
tree, and your personal web interface is:
Replace USER with your login.
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
cvs checkout testbed
* 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
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
sudo gmake post-install
Do not forget the post-install; the main tree will break and users will
be unhappy!
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment