shellonboss.txt 7.02 KB
Newer Older
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
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
  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
Leigh Stoller's avatar
Leigh Stoller committed
16
  files, and especially your .ssh directory, from a breakin on ops or an
17 18 19 20 21 22
  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
  protected!

23 24 25 26
* 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.

27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43
* 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!

44 45 46
  Let me repeat: DO NOT TYPE PASSWORDS OVER THE NETWORK WHEN LOGGING
  INTO BOSS! USE THE SSH AGENT!

47 48 49 50 51 52
* 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.

Leigh Stoller's avatar
Leigh Stoller committed
53 54 55 56
* 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. 
57 58 59 60 61

* 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,
Leigh Stoller's avatar
Leigh Stoller committed
62
  which lets you use "sudo". No password to gain root is required.
63 64 65 66
  BE CAREFUL!


Okay, enough about security. Lets talk about building and installing
67
testbed software. I'll describe how I operate; others in the group almost
68 69 70 71 72 73 74 75 76
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.

77 78 79 80 81
* 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!
82 83 84 85 86 87

* To create a devel tree:

	mkdir ~/testbed
	cd ~/testbed
	mkdir obj-devel
88
	cvs -d cvs.flux.utah.edu:/usr/flux/CVS checkout testbed
89

90 91
  Also:
	# Links your web tree into the main tree so you get to it.
92
	ln -s ../../devel/USER/www /usr/testbed/www/dev/USER
93 94 95 96 97 98 99 100 101 102 103 104 105 106

	# 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

Leigh Stoller's avatar
Leigh Stoller committed
107 108 109 110
* You should join the testbed/emulab-ops projects.

* You need to be in the wheel/flux groups. Ask tbops to do this.

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 148 149 150 151 152
* 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 \
		--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
	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:

	  https://www.emulab.net/dev/USER/index.php3

  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
153
	cvs -d cvs.flux.utah.edu:/usr/flux/CVS checkout testbed
154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179

* 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
	../testbed/configure
	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
	sudo gmake post-install

  Do not forget the post-install; the main tree will break and users will
Leigh Stoller's avatar
Leigh Stoller committed
180 181 182
  be unhappy if you forget this.


183