Commit d58524c2 authored by Robert Ricci's avatar Robert Ricci
Browse files

New operation for firstuser. Now creates the 'elabman' user and

'emulab-ops' project, instead of an account for the user running
it. The elabman user is then used to bootstrap other accounts.

Also include a list of things to do to admin's accounts on boss, like
giving them shells.
parent 4807f865
......@@ -3,33 +3,58 @@
Note: we are working on better automating many of the procedures in this
document - for now, though, many of them are manual.
document - for now, though, a few of them are still manual.
Note: steps labeled "Local Only" are only required when setting up a testbed
with local nodes - they can be skipped in a widearea-only testbed.
##### Step 1 - Setup users
At this point, it's a good idea to get the nfs mounts between boss and ops
setup, as well at the ssh root keys. See the boss and ops setup documents for
Run the 'firstuser' script. This will get put in the utils subdirectory of your
object tree. (Note: configure will not set the executable bit on the script, so
you'll need to set it yourself, or run 'perl firstuser'.) This script will let
you create the first user and project in the database. By default, it will grab
information about the account it's being run as (probably you,) or you can
supply a username, an encrypted password string (grab it from a password file,)
etc. This script will also prompt you to create the first project - create the
project 'emulab-ops', which is a meta-project for holding experiments.
If you want to make sure that this account is a member of any Unix groups (such
as wheel,) run 'unixgroups -a <uid> <gid> ...'
##### Step 2 - Setup projects and experiments
At this point, you should get the webserver up and running on your boss node.
Again, instructions are in the boss setup documentation.
##### Step 1 - Setup users, projects, and experiments
In order to proceed, you should have the following working (from the boss and
ops setup documentation):
NFS mounts between boss and ops
Root ssh keys (so that root on boss can ssh to ops without a password)
The web interface (you don't need to be able to log in yet)
Run the 'firstuser' script on boss. This will get put in the utils subdirectory
of your object tree. (Note: configure will not set the executable bit on the
script, so you'll need to set it yourself, or run 'perl firstuser'.) This
script will create a dummy user, which will be used only to bootstrap 'real'
users. The firstuser script will prompt you for a password for this user, named
Make sure you can log into the web interface using the 'elabman' account. This
account is created as a testbed administrator, but there is one thing you will
need to do in order to use your admin powers. For the same reason that you use
'su' and/or 'sudo' on your UNIX boxes instead of logging in as root, you must
explicitly enable admin privileges after you log in. When logged in as a user
who is allowed to become an admin, you will see a green dot one the left side
of the header above the main page content. The green dot means that although
you are allowed admin powers, they are currently turned off, and you see the
same web pages that a regular user sees, and can use the sam actions. If you
click on the dot, it will turn red, and you will have full administrator
privileges; we call this 'going red dot'. Many of the procedures in this file
require you to be in red dot mode.
Now, we'll use the elabman user to bootstrap your own account. Log out of the
web interface, and use the 'Request Account' button to start a new project.
Create a project that you can use for the faculty/students/staff involved in
running your testbed - you can name it anything you'd like. Fill in your own
information in the 'Project Head Information' section. If you have created an
account for yourself by hand on boss and/or ops, it is important that you
either user a different username on this form, or delete your handmade account
(using 'pw userdel <username>') on BOTH boss AND ops. Shortly after submitting
this form, you should get email at the address you included on the form -
follow the instructions it gives for verifying your email address. After
entering your password, while still logged in to your new account, use the
'Join project' link in the menu to join the 'emulab-ops' project (leave the
'group' field blank.)
Okay, now log out of the web interface, log back on as elabman, and go 'red
dot'. Use the 'Approve New Projects' link on the menu to approve the project
you just started. Also, use the 'New User Approval' page to approve your new
account in the the 'emulab-ops' project - give yourself trust 'group root', so
that you can approve others into this project too.
Go to the web interface, and log in as the admin account you created. Create a
project for the administrators at your site (we call ours 'testbed', you can
......@@ -37,11 +62,51 @@ call yours whatever you call your project or group). As soon as you've sent
the request to sart the project, you can use the 'New Project Approval' link to
make it active.
Others at your site can now apply to join your project.
Now, that you have an account, there a few things you're going to want to do -
you'll also want to do these things to other admin-types too, when their
accounts get created:
1) Set your 'admin bit' - set the 'admin' column for your account in the users
table to '1' - you can do this, on boss, with:
echo 'update users set admin=1 where uid="<username>"' | mysql tbdb
2) Give yourself the ability to log in to boss - most users have a restricted
shell on boss, and are not allowed to log in using a password. Edit the
password file (use 'vipw', FreeBSD requires some special processing on the
password file after editing). Give yourself a real shell, and paste in your
encrypted password string from ops.
3) Add yourself to important groups - If you want to be a member of any UNIX groups
on boss, use the 'unixgroups' command (our automated account tools may wipe
out groups added by hand.) You will need to be logged in as yourself (not
root) on boss to run this command. You will want to be a member of at least
the 'tbadmin' and 'wheel' groups. The syntax for this command is:
unixgroups -a <username> <groupname> ...
There are three experiments that must be created in the emulab-ops project.
Just start them through the normal 'begin experiment' page, and don't give an
NS file. These experiments are:
Just as you need to go 'red dot' to use admin privileges on the web interface,
you must also explicitly enable them on the command line. To do this, prefix
the command you want to run with 'withadminprivs'. For example, I might invoke
unixgroups like this:
withadminprivs unixgroups -a ricci tbadmin wheel
(Note: withadminprivs and many other admin-type commands live in
/usr/testbed/sbin - you'll want to put this and /usr/testbed/bin in your
Now that you are an admin, you don't need the elabman account anymore. Log into
the web interface as yourself, go red dot, and go to the user list. Find
elabman (you may need to click on 'Show: all' a the top of the page). Go to
elabman's profile page (by clicking on the uid) and freeze the user.
Others at your site can now apply to join your project, or start their own.
There are three meta-experiments that must be created in the emulab-ops
project. Just start them through the normal 'begin experiment' page, and don't
give an NS file (you must be 'red dot' to do this.) Also, uncheck the
'idle-swap' checkbox so that they do not get swapped out accidentally.
These experiments are:
hwdown - Nodes that are down due to hardware failure
reloading - Nodes that are having their disks automatically reloaded
......@@ -50,7 +115,7 @@ reloadpending - Nodes that are awaiting disk reloading
Any other 'holding' experiments that you want for operations should be put
into the emulab-ops project.
##### Step 3 - Setup web sql editor
##### Step 2 - Setup web sql editor
Several of the steps below require you to add data to the database by hand. If
you're comfortable with SQL, you can do this directly with SQL queries, or you
......@@ -90,7 +155,7 @@ This is to protect against accidental database damage, as mentioned in the
warning above. We'll soon provide contents for this table
(webdb_table_permissions) with the testbed software.
##### Step 4 - Setup switches
##### Step 3 - Setup switches
##### Local Only
1) Create node types for switches
......@@ -157,18 +222,10 @@ Finally, add switches to these stacks by putting entries in the switch_stacks
table, listing the node_id of each switch and the stack_id of the stack it
belongs to.
##### Step 5 - Setup control hardware
##### Step 4 - Setup control hardware
##### Local Only
1) Boss/ops nodes
Optional step: You can put your control (boss and ops) nodes in the database if
you wish. You'll need to add entries to the nodes, interfaces, and wires
tables, and possibly the node_types and interface_types tables as well. See the
instructions for adding nodes below for descriptions of the contents of these
2) Power controllers
1) Power controllers
The only two supported power controllers at this time are the APC AP9210 and
the BayTech RPC27. Theoretically, other SNMP and serial-controlled power
......@@ -183,7 +240,7 @@ If you have serial power controllers, just create entries node_types and nodes
- no interfaces or wires. Again, the role in the nodes table should be
##### Step 6 - Images and OSids
##### Step 5 - Images and OSids
These will depend on the image(s) and any OSKit kernels you've recieved, or
built yourself. Since you're probably using disk images from Utah, the best
......@@ -193,6 +250,6 @@ required to load disk images. For a widearea-only testbed, no images entries
in the images table a required, but OSIDs are still useful, to determine what a
node's capabilities are.
##### Step 7 - Setup nodes
##### Step 6 - Setup nodes
To add nodes to the testbed, see setup-nodes.txt .
......@@ -8,60 +8,49 @@
use English;
use strict;
use lib '@prefix@/lib';
use libdb;
my $tbadmin = '@TBADMINGROUP@';
my $wap = '@prefix@/sbin/withadminprivs';
my $mkproj = '@prefix@/sbin/mkproj';
my $mkgroup = '@prefix@/sbin/mkgroup';
my $mkacct = '@prefix@/sbin/tbacct add';
print "IMPORTANT: You should ONLY use this script to create the first\n";
print "testbed user - others should be created through the web interface\n";
my $protouser = 'elabman';
my $protouser_name = 'Emulab Manager';
my $protouser_email = '@TBOPSEMAIL@';
my $protoproj = 'emulab-ops';
my $protoproj_desc = 'Operations Meta-Project';
my $username;
if ($UID != 0) {
my $name = getpwuid($UID);
print "Make account for $name? (Y/N) ";
if (<> =~ /Y/i) {
$username = $name;
my $result = DBQueryFatal("select * from users where uid='$protouser'");
if ($result->num_rows()) {
die "This script has already been run, there is no need to run it again\n";
if (!$username) {
print "New username (you): ";
$username = <>;
if ($UID != 0) {
die "Sorry, this must be run as root\n";
my ($userfull, $password, $uid);
if (getpwnam($username)) {
print "User already exists, using existing user information\n";
my @user_info = getpwnam($username);
$password = $user_info[1];
$uid = $user_info[2];
$userfull = $user_info[6];
} else {
print "New user's full name: ";
$userfull = <>;
print "Encrypted password for user: ";
$password = <>;
$uid = 10000;
while (getpwuid($uid)) { $uid++; }
print "This script will create the 'proto-user' $protouser, which you will\n";
print "use to bootstrap other users. It also creates the emulab-ops\n";
print "meta-project.\n\n";
print "New project pid: ";
my $project = <>;
# Get a password for the user
print "Pick a password for $protouser (warning, will be echoed): ";
my $password = <>;
my @salt_chars = ('a'..'z','A'..'Z','0'..'9');
my $salt = $salt_chars[rand(@salt_chars)] .
my $encpass = crypt($password, $salt);
print "New project description: ";
my $projdesc = <>;
# Get uid for the user and a gid for the project
my $uid = 10000;
while (getpwuid($uid)) { $uid++; }
my $gid = 6000;
while (getgrgid($gid)) { $gid++; }
......@@ -69,50 +58,59 @@ while (getgrgid($gid)) { $gid++; }
my $ggid = $gid + 1;
while (getgrgid($ggid)) { $ggid++; }
if (!$username || !$project || !$password || !$userfull || !$projdesc) {
die "Not all information given, exiting\n";
# We put the proto-user in the tbadmin group, because the emulab-ops
# group does not exist yet
my $agid = (getgrnam($tbadmin))[2];
if (!defined $agid) {
die "Unable to get group ID for $tbadmin\n";
# Quote special characters in user-supplied data
$userfull = DBQuoteSpecial($userfull);
$projdesc = DBQuoteSpecial($projdesc);
print "Creating user/project: Are you sure? (Y/N) ";
if (<> !~ /Y/i) {
die "Aborted\n";
print "Creating user on boss...\n";
if (system "/usr/sbin/pw useradd $protouser -u $uid -g $agid -h - " .
"-s /bin/nologin -c \"$protouser_name\"\n") {
die "Unable to add user to the password file!\n";
print "Creating user in database...\n";
DBQueryFatal("insert into users set uid='$username', usr_created=now(), " .
"usr_name=$userfull, usr_pswd='$password', unix_uid=$uid, ".
"usr_modified=now(), admin=1, dbedit=1, status='active'");
DBQueryFatal("insert into users set uid='$protouser', usr_created=now(), " .
"usr_name='$protouser_name', usr_pswd='$encpass', unix_uid=$uid, ".
"usr_modified=now(), admin=1, webonly=1, status='active'");
print "Creating project in database...\n";
DBQueryFatal("insert into projects set pid='$project', created=now(), " .
"name=$projdesc, head_uid='$username', unix_gid=$gid, " .
DBQueryFatal("insert into projects set pid='$protoproj', created=now(), " .
"name='$protoproj_desc', head_uid='$protouser', unix_gid=$gid, " .
print "Creating group in database...\n";
DBQueryFatal("insert into groups set pid='$project', gid='$project', " .
"leader='$username', created=now(), description='Default Group', " .
"unix_gid=$ggid, unix_name='$project'");
DBQueryFatal("insert into groups set pid='$protoproj', gid='$protoproj', " .
"leader='$protouser', created=now(), description='Default Group', " .
"unix_gid=$ggid, unix_name='$protoproj'");
print "Putting user in group...\n";
DBQueryFatal("insert into group_membership set uid='$username', " .
"pid='$project', gid='$project', trust='project_root'," .
DBQueryFatal("insert into group_membership set uid='$protouser', " .
"pid='$protoproj', gid='$protoproj', trust='project_root'," .
"date_applied=now(), date_approved=now()");
# Flip UID to the new user so that the mk* scripts are happy - they can't
# be run as root for accountability reasons
$EUID = $UID = $uid;
$EGID = $GID = $gid;
print "Running mkproj...\n";
system "$wap $mkproj $project";
system "$wap $mkproj $protoproj";
print "Running mkgrp...\n";
system "$wap $mkgroup $project $project";
system "$wap $mkgroup $protoproj $protoproj";
print "Running mkacct...\n";
system "$wap $mkacct $username";
system "$wap $mkacct $protouser";
print "User created. Once the web page is up, you should be able to log in\n";
print "as the user you just created. Make sure to go to the user and project\n";
print "pages, and fill out information such as phone number, web URLs, etc.\n";
print "as '$protouser' with the password you just entered. Refer to\n";
print "setup-db.txt for instructions on creating a 'real' user account for\n";
print "yourself.\n";
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