Admin Users

From UGP-Wiki

Jump to: navigation, search

Contents

[edit] II. Users

[edit] A. Adding a User via the Normal Workflow

[edit] Workflow: Stand-Alone Grids and lower-level Grids in a Hierarchy

For a stand-alone Grid or a lower-level (Campus) Grid, a new user applies to use the Grid by going to the Grid Portal home page and clicking on Apply for Grid Access. A page will open asking the user to authenticate. One of several authentication methods will be used. Shibboleth authentication, the most general, verifies that the user is a member of the community that can make use of the Grid. SSH authentication, proves that the user has a login id on at least one of the clusters participating in the Grid.

After the user authenticates he/she is asked to fill in a form including: name, email address, and proposed Grid Username and Password; and to Select a Resource. The resource selected can either be a cluster, the default pool or another pool. The workflow depends upon what the user selects:


 - A cluster
    1. An email is sent to the Cluster Admin of the cluster the user selected
       asking the Cluster Admin to approve the user. The Cluster Admin should
       approve the user ONLY if the user already has a login id on the
       cluster.
       The Cluster Admin then takes the following steps:
        a. If the Cluster Admin also administers the Grid Appliance and
           approves of the user, the Cluster Admin must take all the steps
           necessary to Grid-Enable the user.
        b. The Cluster Admin clicks on the link in the email message. This
           takes the Cluster Admin to a web page where the Cluster Admin is
           asked to SSH authenticate to prove that he/she can login to the
           cluster.
        c. The Cluster Admin then clicks on Approve or Deny next to the user's
           name.
    2. The Cluster Admin clicking on Approve causes a message to be sent to
       the Grid Admin.
       The Grid Admin then takes the following steps:
        a. If the Grid Admin is the one who administers the Grid Appliance,
           not the Cluster Admin, then the Grid Admin must take all the steps
           necessary to Grid-Enable the user.
        b. The Grid Admin clicks on the link in the email message,
           authenticates, and clicks on Approve next to the user's name.
 - A pool other than the Default Pool
   An email message is sent to the Pool Admin for that pool. The Pool Admin
   takes the following steps:
    1. The Pool Admin clicks on the link in the email message. This takes the
       Pool Admin to a web page where the Pool Admin is asked to SSH
       authenticate to prove that he/she can login to some cluster.
    2. If the Pool Admin knows the user and wants to let the user join the
       pool, the Pool Admin should click Approve next to the user's name.
       Otherwise, the Pool Admin should click on Deny.
    3. When the Pool Admin clicks on Approve, an email message is sent to the
       Grid Admin. If the user is a new user to the Grid, the Grid Admin must
       treat the user just like a user who is applying to the Default Pool and
       assign that user a Storage Area. The Grid Admin then clicks on the link
       in the message, authenticates and clicks on Approve next to the user's
       name.


 - The Default Pool
   An email message is sent to the the Grid Admin. The Grid Admin has to
   allocate a Storage Area for the user on the Storage Server associated with
   the the Grid Portal and Grid-Enable that user there. After that, the Grid
   Admin should click on the link in the email message, authenticate and click
   on Approve next to the user's name.

[edit] Workflow: Highest-level Grids in a Hierarchy

In a hierarchy of Grids, users must apply for access at their local lower-level Grid Portal. When a user applies at the lower-level Grid Portal, he/she is given access to both the lower-level Grid Portal and the higher-level Grid Portal.

[edit] How to Grid-Enable a Cluster User

To Grid-Enable a Cluster User the person who controls the Grid Appliance, either the Cluster Admin or the Grid Admin depending on the arrangement, must take the following actions:

1. Add the user's login id to the Grid Appliance
   As root, copy the /etc/passwd entry for that user from the cluster head
   node to the /etc/passwd file on the Appliance. The login id is needed so
   that the Grid can perform work on behalf of the user and so that the user
   can get to his/her home directory from the Grid Portal. The user will never
   login to the appliance directly. Make sure that the line for the user maps
   to the correct home directory. For safety, change the user's shell to /sbin
   /nologin.
2. Allow the user globus to do work on behalf of the user.
     a One-time-only setup required:


        1. As root, create group globus2 in /etc/group.
        2. As root, add the following lines to /etc/sudoers:
               globus ALL=(%globus2) \
                  NOPASSWD: /homeg/globus/gt4.0.2/libexec/globus-gridmap-and-execute \
                  -g /etc/grid-security/grid-mapfile \
                  /homeg/globus/gt4.0.2/libexec/globus-job-manager-script.pl *
               globus ALL=(%globus2) \
                  NOPASSWD: /homeg/globus/gt4.0.2/libexec/globus-gridmap-and-execute \
                  -g /etc/grid-security/grid-mapfile \
                  /homeg/globus/gt4.0.2/libexec/globus-gram-local-proxy-tool *
           where /homeg/globus/gt4.02 is the directory in which you have
           installed the Globus Toolkit.
     b For each user to be Grid-Enabled, add the users Grid Appliance login id
       to group globus2 by issuing the following command as root:
           usermod -a -G globus2 loginid
       Replace loginid with the cluster login id of the user applying for Grid
       access.
       Note that early versions of Fedora Core do not support the -a argument.
       In that case, you must look up all the groups to which the user
       currently belongs and include them with group globus2 after the -G
       argument.
3. Add the user to /etc/grid-security/grid-mapfile. In that file there are
   records of the form:


      "/C=US/O=University of California/OU=UC Grid/OU=ucgrid.org/CN=username1" userid1
      "/C=US/O=University of California/OU=UC Grid/OU=ucgrid.org/CN=username2" userid2
      "/C=US/O=University of California/OU=UC Grid/OU=ucgrid.org/CN=username3" userid3


   Where username1, username2, username3 are the Usernames that the users will
   use to login to the Grid Portal and userid1, userid2, userid3 are the local
   Unix usernames for those users on the cluster. Each line in grid-mapfile
   associate a Grid Portal Username with a Unix login id (username) on the
   cluster. The Username and the real name for the user to be added is
   included in the messages to the Admins. Look up the real name of the user
   in the /etc/passwd file on the cluster head node to figure out what the
   user's login id is. Then add a record for that user in /etc/grid-security/
   grid-mapfile with the Username and appropriate login id.

If you are anticipating that every cluster user will want to be able to access it via the Grid Portal, then you can take steps 1 and 2 in advance of a user request. At UCLA, whenever a new cluster is added to the Grid, we run a script (see Scripts/forClusterApplicance/rootbin/gridusers.pl and gridusers.README) that takes as input all the lines pertaining to real users in the /etc/passwd file from the cluster head node and produces a file of all the commands necessary to perform steps 1 and 2 for all of them. Then we login to the Grid Appliance as root and execute that file. Also, we have a cron job that monitors the /etc/passwd files on the head nodes of all the clusters and notifies us whenever a new user has been added. Then we perform steps 1 and 2 above for each new user.

[edit] How to set up the Storage Area for and Grid-Enable a Pool-Only User

The Storage Server has to be set up with Globus Toolkit installed on it. Just as for an appliance, there should be a globus2 group which has been added to / etc/sudoers as shown above.

The tasks required to add a Pool-Only User are as follows:


1. Login to the Storage Server as root.
2. Add a login id for the user via the useradd command and specify the -m and
   -d options to create the user's home directory.
       useradd -c 'fullname' -u uid -g gid -s /sbin/nologin -d homedirectory
       -m loginid
3. Add the user to group globus2:
       usermod -G globus2 loginid
4. Add the user to /etc/grid-security/grid-mapfile. For example:
         "/C=US/O=University of California/OU=UC Grid/OU=ucgrid.org/CN=gridusername" loginid


You could, if you wanted to, assign the Pool-Only Users disk quotas on the Storage Server. Here is how you set up the Storage Server for quotas:


1. Login to the Storage Server as root
2. Edit the file /etc/fstab and add a line that looks like this:
         /dev/whatever    /mountedas  ext defaults,usrguota,grpquota 1 2
   Replace /dev/whatever with the mount point of the filesystem containing the
   user home directories and /mountedas with the name it is mounted as.
3. Then issue the following commands:
       touch /aquota.user /aquota.group
       chmod 600 /aquota.*
       mount -o remount /mountedas
       quotacheck -avugm
       quotaon -avug
4. Then for each login id that you add set a user quota on that login id.
       setquota -u loginid nnnn nnnn 0 0 -a
   Replace nnnn with the quota in megabytes. 1000 is equal to 1GB. See man
   setquota for information on hard and soft quotas.

[edit] B. Adding a Cluster User Manually -- Outside of the Normal Workflow

We highly recommend that ALL users be added to the Grid Portal via the normal workflow as described above. That being said, it is possible to add a user manually, without that person applying on the Grid Portal web site. Extreme care should be taken when doing this for two reasons: 1) the user must be known to the Admin and known by the Admin to be legitimate because the user will not be asked to authenticate and 2) because the steps will be done manually, it is possible to omit a necessary step and have to fix up the user's record later.

1. The Admin who controls the Grid Appliance for the cluster the user is to
   use, has to Grid-Enable the user on the Appliance.
2. Login as Grid Admin to the (lower-level, stand-alone or campus) Grid
   Portal. Click on the Grid Admin tab and then on User Admin. At the bottom
   of the list of users click on Create a New User. In the form that is
   presented to you, enter the information about the user in question. Select
   the cluster for which the user has been Grid-Enabled and enter the Username
   you have chosen for the user.
3. The user will now receive an email message informing him/her of the
   activation. This message contains a link. When the user clicks on the link
   he/she will be asked to authenticate via SSH authentication by entering his
   /her login id and password on the cluster for which he/she has been
   Grid-Enabled. The user will next be asked to enter a new password for use
   with the Grid Portal.

[edit] C. Workflow Followed when a User Forgets his/her Password

If a user forgets his/her Grid Portal password:


1. He/she should go to the Grid Portal home page and click on Forgot your Grid
   Password?.
2. He/she will be asked to authenticate using the authentication method used
   by the Grid Portal (Shibboleth for the UCLA campus).
3. UGP will lookup the user in its database and send an email message to him/
   her at the email address of record.
4. The user must confirm that he/she is actually the one who requested a
   password change by clicking on a link in the message he/she receives.
5. A message is sent to the Grid Admin for approval.
6. As Grid Admin, when you get the email message that results from this
   process, asking you to reset the user's password:
    a. Login to the Grid Portal.
    b. Click on the Grid Admin tab and then on User Requests.


    c. You will see a number of records there. Find the record that has
       ResetPasswordGridAdminApproval in the column labeled Label and the
       user's Username in the column labeled Who. Click on Approval/Reject on
       that line. This will take you to another form. At the top you will see
       Approve and Reject radio buttons. Approve should already be selected.
       To allow the user to reset the password, click on the Submit button.
7. An email message will be sent to the user asking the user to change his/her
   password.
8. The user will click on a link in the message, be asked to authenticate, and
   be asked to enter a new password for use with the Grid Portal.

Once the user has entered a new password, the user can login immediately.


[edit] D. Adding a Resource to a User

A user can request access to an additional cluster or pool by clicking on Add Resource under the My Home tab. The user will be shown a list of those clusters and Resource Pools to which he/she does not yet belong. The user can select a resource from this list and click on the Submit button.

The workflow here is similar to the workflow that occurred when the user was added to the Grid Portal in the first place. If the user has requested access to a cluster, the Admin who controls the Grid Appliance has to Grid-Enable the user for that cluster and both Admins have to click on Approve. If the user has applied to add a Pool, the Pool Admin for that pool has to approve of the user.

We don't recommend doing it, but the Grid Admin can add the access to a specific cluster to a user manually without the user applying through the standard workflow process. After Grid-Enabling the user for that particular cluster, the Grid Admin can go to ClusterAccessList under the Grid Admintab, select the user's Username from the list of users and click the load button, click the check box next to the cluster name and then click update for the change to take effect.


[edit] E. Disabling or Deleting a User

To disable a user, login to the Grid Portal as Grid Admin and select User Admin under the Grid Admin tab. Click on the user's name in the list of users and then on the next page that appears click on the box labeled Disable account?.

Deleting a user is a dangerous action. We do not suggest you actually delete users but instead simply disable them. For example, currently in a hierachal set of Grids, such as the one we have in the UC System, if a user has access to resources on more than one Campus Grid and he/she is deleted from his/her home portal, the user will also automatically be removed from the UC Grid Portal and will no longer be able to access resources that he/she might still have access to on other campuses.

To delete a user:

1. Login to the Grid Portal as Grid Admin and select ClusterAccessList under
   the Grid Admin tab. Select the user's Username from the pull-down list and
   click on the Load button. Unselect everything, and click the Update button
   The user will be automatically disabled as the user no longer has access to
   any clusters or other resources. The user will be sent an email message.
2. Now select User Admin under the Grid Admin tab. Select the user from the
   user list and click the Delete User button. The user will be deleted from
   the Grid Portal and from the higher-level Grid Portal if there is one.

Deleting a user from a Grid Portal will not delete him/her from the CA. To delete a user from a simpleCA, the administrator of that CA should take the following steps on the machine that runs the CA:

 - Clean up the simpleCA
   Edit the file:
       HOME/.globus/simpleCA/index.txt
   Remove the line that contains that user's name.
 - Remove the user from:
       INSTALLDIR/certificates/username
Personal tools