shellonboss.txt 5.61 KB
Newer Older
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147
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!