|
|
### Project Groups
|
|
|
|
|
|
As an instructional aid, project leaders may designate TAs to lead smaller
|
|
|
groups of project members. This is accomplished by creating a *project
|
|
|
group*, and designating the TA as the leader of the group. A project group
|
|
|
is a lot like a unix group, and in fact unix groups is the mechanism used
|
|
|
to protect members of one project group from members of other groups in the
|
|
|
same project. For each new project group, a new unix group is created, and
|
|
|
the members of the project group added to the unix group. When a project
|
|
|
member starts an experiment, a dropdown menu is presented to set the
|
|
|
group in which to create the new experiment.
|
|
|
|
|
|
All of the nodes in the experiment will have user accounts for only members
|
|
|
of the selected project group. Thus, multiple groups of a project can work
|
|
|
independently, and be protected from each other via the generally well
|
|
|
understood unix group protection mechanism.
|
|
|
|
|
|
To create a new group, go to your dashboard, click on the __Membership__
|
|
|
tab, and then on the project you want to create a group in. On the project
|
|
|
page, click on the __Groups__ tab, and then on __Create New Group__.
|
|
|
|
|
|
To add members to the group, navigate back to the project page, click
|
|
|
on the __Groups__ tab, and then on the group. On the group page, click
|
|
|
on the __Members__ tab. Here you will find all the members of the group
|
|
|
and the members of the project you can add to the group. You will need
|
|
|
to choose a privilege setting for each member you add, more on that
|
|
|
below.
|
|
|
|
|
|
#### The Default Group
|
|
|
|
|
|
Every new project has a single *default* group. All project members are in
|
|
|
the default group, and as its name implies, whenever the group is left
|
|
|
unspecified in a form, it defaults to the default group (this allows you to
|
|
|
create a project without any additional groups at all; new members join the
|
|
|
default group, new experiments are created in the default group, etc.).
|
|
|
|
|
|
#### Group Leader Privileges
|
|
|
|
|
|
The project leader and designated project *managers* may create new groups,
|
|
|
but only the leader can destroy groups (this is a safety mechanism to
|
|
|
prevent loss of important state by accident). The project leader and
|
|
|
managers may edit the membership of any group in the project. Normal users
|
|
|
may also be designated as the leader of a project group. Whoever is the
|
|
|
group leader, has permission to approve new users to the group, change
|
|
|
their permissions in the group, and terminate any experiments in the group.
|
|
|
|
|
|
#### Group Member Privileges
|
|
|
|
|
|
Users may have one of several permissions in a group:
|
|
|
|
|
|
* __User__: Users with this permission are not allowed
|
|
|
to start new experiments, nor do they have root access on
|
|
|
nodes. Typically this permission is used in classes, where
|
|
|
students need to log into nodes, but not be able to alter
|
|
|
any state or view anything except what standard unix
|
|
|
permissions allow. See the note below for additional
|
|
|
information.
|
|
|
* __Root__: The most common permission granted, users
|
|
|
with this permission are allowed to start new experiments,
|
|
|
and have root access on all nodes
|
|
|
belonging to experiments in the group. In
|
|
|
a class setting, this means that users can log into the
|
|
|
nodes of other students and view any files they want.
|
|
|
* __Manager__: In addition to the privileges granted with __root__,
|
|
|
managers are allowed to approve new users to
|
|
|
the group, as well as set the privileges for
|
|
|
other members of the group. Typically class
|
|
|
TAs would be given this permission so that they can help
|
|
|
the instructor manage the class.
|
|
|
|
|
|
For teaching a class, a typical approach is to place different sets of
|
|
|
students in different groups and give them __root__ privileges so that they
|
|
|
can create experiments in those groups. Or you might put just a single
|
|
|
student in each group so that they are walled off from each
|
|
|
other. __However__ for this to be completely secure, __you must assign
|
|
|
*user* permissions to students in the project default group__. This will
|
|
|
prevent students from creating experiments in the main group, which would
|
|
|
give them root access on nodes that include the accounts of all students in
|
|
|
the project. And with root access, they can access all the files of all the
|
|
|
members of the project.
|
|
|
|