As such, FAS RC has created new roles within our systems to allow nominated individuals to gain additional responsibilities with approval from their PI. To accommodate the various desires of the faculty, several roles have been created. 

Roles: 

PI (Data Steward)

• Leader of the group and responsible for all data generated by the lab
  • PI responsibilities at FASRC
• Add or remove users from group membership
• Add or remove users from Slurm access 
• Modify, add or remove account expiration 
• Enable or disable existing accounts
• Modify user roles, including those defined here
• Sponsor and create new user accounts (Account Request Tool) 
• Request modifications to storage allocation amounts
• Update notification recipients for storage emails
• Access to the Coldfront and Starfish Zones data management tools
• Approve storage folder access changes (ownership & permissions)

General Manager (Lab Data Manager)

• Add or remove users from group membership
• Add or remove users from Slurm access
• Modify, add, or remove account expiration 
• Enable or disable existing accounts
• Modify user roles, including those defined here 
• Request modifications to storage allocation amounts
• Update notification recipients for storage emails
• Access to the Coldfront and Starfish Zones data management tools
• Approve storage folder access changes (ownership & permissions)

Storage Manager (storage only)

• Modify or adjust storage allocation amounts
• Update notification recipients for storage emails
• Access to the Coldfront and Starfish Zones data management tools
• Approve storage folder access changes (ownership & permissions)

Access Manager (accounts only) 

• Add or remove users from group membership
• Modify, add, or remove account expiration 
• Enable or disable existing accounts
• Access to the Coldfront and Starfish Zones data management tools

User

• Access to the Coldfront and Starfish Zones data management tools
• Access to all resources provided by the PI’s lab group including storage
• Request new personal user account (Account Request Tool) 

Additional Information: 

• The ‘General Manager’ role cannot be approved by another ‘General Manager’ role; they must be affirmed through approval by a PI or group leader. See the ‘FASRC Data Ownership and Access Policy’ for additional details about data ownership and allowable modifications to data ownership with PI approval.
• New accounts require PI approval using the Account Request Tool. 
• Role definitions and responsibilities may be modified over time. Any modifications made to the responsibilities for each role will be in line with their original intent.

On an annual basis, FAS Research Computing will send a spreadsheet of accounts that you have sponsored, and group memberships for groups you approve.  The intent is to identify sponsored accounts that may be disabled, and group memberships that may be removed.

Access Review Sheet

These sheets are named YourAccountName-access_date.xlsx.  They describe each member of each group you are an authorized approver for.  The intent is to identify any individuals who should no longer have access granted by the group.

What FASRC Needs

Review each line item.  If any user should be removed from a group, provide FASRC the Group and Username to remove.

Access Review Fields

Many of these are self-described.  For further clarification:

• Fields describing the group you are reviewing:
  • Group – Name of the group
  • GroupPortalDescription – Description of the group from our Portal
  • GroupADDescription – Description of the group from our identity system
  • OtherApprovers – Other authorized approvers for this group
• Fields describing a member of the group you are reviewing:
  • Username – a member of this group, either:
    • Username for the member of this group, or
    • Name of another group granted access to the group you are reviewing (indicated via [nested group])
  • First
  • Last
  • Mail – Mail address on record in our identity system
  • Expires – Date account is set to expire, if any
  • PrimaryGroup – Primary group (generally, their lab’s group) of the user
  • Title
  • Department
  • School
  • IsFASRCAccount – Whether this is a FAS RC Staff account (i.e. you can ignore)
  • Created – Date the account was created
  • LastLogonDate
• Fields used by FASRC to debug, you may ignore these
  • DBGManagedBy
  • DBGPortalGrant
  • DBGApprovesMembership
  • DBGManagedByViaGroup

Account Sponsor Sheet

These sheets are named YourAccountName-sponsor_date.xlsx.  They describe each account you are the sponsor of.  The intent is to identify any account you no longer sponsor, and thus, which accounts should be disabled.

What FASRC Needs

Review each line item.  If you no longer wish to sponsor a user, provide FASRC the Username to disable.

Account Sponsor Fields

Many of these are self-described.  For further clarification:

• Username – Username for the member of this group
• First
• Last
• Mail – Mail address on record in our identity system
• Expires – Date account is set to expire, if any
• PrimaryGroup – Primary group (generally, their lab’s group) of the user
• Title
• Department
• School
• Created – Date the account was created
• LastLogonDate

Ownership and Access Groups

Owner Group Other

These are the three permission sets applied to files and directories.

1. Owner is a single user. The account/user who is the owner of the file. Regardless of Group or World access, the owner has access to modify or remove the file.
2. Group is a collection of users (such as your lab group). The owner of a file or directory may extend and control access permissions (read, write, execute) for a single group.
3. Other (aka Everyone or World) indicates all other valid users on the system. This can be used to grant or deny access to all valid users in the system.

If you have used the ls -l command in a terminal, you have seen this signified like so:

drwxr-x---  jharvard  jharvard_lab   4096 Dec 10  2021  MyData
-rwxrwxr-x  jharvard  jharvard_lab   3257 Feb 23 17:21  myscript.sh

The d in the first line indicates that this object is a directory. It has read, write (aka modify), and execute (rwx) permissions for the Owner, read and execute permissions for the Group, and no permissions for Other. This means: Owner jharvard has full access to this directory (and can change permission at will via the chmod command). Group jharvard_lab can read and execute files in this directory, but cannot modify it. All other users who might have access to this share have no access to this directory.

The second object is a file (hence the -, signifying ‘not’ or ’empty’ value, in place of d). It has read, write, and execute permissions for the Owner, read, write, and execute permissions for the Group, plus read and execute permissions for Other. This means jharvard has full access to the file (and can change permission at will via the chmod command). Group jharvard_lab can read, write/modify, and execute this script. Other, assuming they have access to this share, can read and execute this script.

Note that for Other to actually have access, they would need also to be able to access the top-level share itself. We’ll go over this a litttle further down.

Permissions in Practice – A Quick Metaphor

Let’s look at your lab directory or tiered storage share as an example, but using a metaphor. In most cases, these directories/shares havc a top-level permission like

drwxr-xr-x – Meaning the Owner (probably your PI) has rwx access to the share, the Group has r-x access to the top-level but generally have write access to sub-directories within (see One,Many, All below), and all other users not in the group have potential read and execute access on any file or directory inside the share that explicitly allows access to Other (like myscript.sh in the earlier example), but otherwise no access.

If the top-level of the lab directory or share is set drwxr-x--- or drwxrwx— or drwxr-s---, then Other has no access to the directory/share, even if a file inside is set -rwxrwxrwx. Other must first be able to ‘see’ into the directory/share. Otherwise, it has no access at all. Please note that FASSE/L3 shares should never allow Other access.

To our metaphor:

Say you have a keycard to let you into your group’s office building and its common areas. That keycard also let’s you open your private office door, your keycard is required again to open the door to exit to the common area. Your office also has a large window to the outside that you can open and close with your keycard.

You and all your co-workers can access the building and common areas using your individual keycards.

Each person can open their own office door with their personal keycard. You can, if you wish, also set your office door to allow other members of your group to open it with their keycards. You can revoke this permission at any time.

Now let’s imagine your building is inside a secure compound, and not accessible to the public (like the FASRC cluster). And you want to allow other people in the compound to come into your office any time they wish, but not have access to your group’s common areas. You can do so by opening the window to the outside world. They can enter your office, but they cannot open the office door to the rest of the building as they are not you (Owner) or part of the group (Group). But you cannot control who comes in, it could be anyone inside the compound.

If you need to allow a single person from outside, you could ask your boss to make them a member of your Group, which would then give them keycard access to the building and common areas. If you have set your door to allow members of your group to open it, then this person would now also have access to your (and potentially other group members’) office door.

This is analogous to the POSIX permissions scheme works: Owner is a single user, Group is a curated (by your PI) collection of users, and Other is everyone else on the cluster.

One, Many, All

As you can see, this doesn’t allow for ‘I want this person and this person’ to have access, but not this person’. POSIX permissions require conforming to the idea of one, many, and all. One being the Owner, many being the Group, and All being Other, which is everyone else on the cluster, in this case.

To facilitate this idea, lab directories and tiered shares (except FASSE/L3 shares) by default contain some special directories to help ease the issues of sharing within a POSIX-like environment:

Lab – This directory is set drwxrws– so that every member of the lab group has read/write/execute (the s here being the setuid  bit, for this discussion just think of it as is equivalent to x ) access to share  data amongst the group. This directory is also visible to lab group members when accessing the share via Globus (if applicable).

Users – Please Note: The Users directory only exists on shares created prior to Octpber 2024. On new shares and /n/netscratch please use the Lab directory to create personal folders.  The sub-directories in the Users directory are owned by individuals and by default only allow execute (using the setuid bit as above) access to the group. You may, if you wish, make your Users directory open to others in the group using the chmod command. But using the Lab directory instead is the preferred method to share data with your lab group. This directory is also visible to the owner (and only the owner) when accessing the share via Globus (if applicable).

Everyone – This directory is set drwxrwsr-x and is useful for sharing data with Other (all other cluster users). This directory is not available from Globus.

Real name for a username

One can find the real name associated with a username using the Linux command getent. This is a Unix tool that is used to retrieve user details on Unix system by obtaining information from databases, such as passwd and group. Execute the following command to obtain the real name associated with a FASRC username:

getent passwd <username>

Related Links

https://docs.rc.fas.harvard.edu/kb/unix-permissions/

https://docs.rc.fas.harvard.edu/kb/storage-service-center/

https://docs.rc.fas.harvard.edu/kb/globus-file-transfer/

https://en.wikipedia.org/wiki/Getent

1. You are trying to SSH to a login node and you are repeatedly asked for your password over and over.
   You did not request cluster access in your original account request. Without Cluster Access, you will not have a home directory and will not belong to the cluster_users/cluster_users_2 group. You can request cluster access by following these directions: Adding additional lab groups or cluster access
2. You get an error saying “Home directory not found” on VDI or other login.
   You did not request cluster access in your original account request. Without Cluster Access, you will not have a home directory and will not belong to the cluster_users/cluster_users_2 group. You can request cluster access by following these directions: Adding additional lab groups or cluster access
3. You receive an error saying your account is disabled.
   Each user is assigned a single FASRC account for the entire time that they need to use FASRC services, even if they leave and return. It can be disabled for a number of reasons: after long period of inactivity, if it has expired, or if we have been asked to disable it. When your account is disabled please have your current sponsoring PI contact FASRC providing your FASRC username. We will need their direct approval by e-mail to re-enable your account. Again, DO NOT SIGN UP FOR A NEW ACCOUNT – YOU CAN ONLY HAVE ONE FASRC ACCOUNT
4. You have entered a wrong password or two-factor code too many times and your account is locked.
   Account locks expire after about 5 minutes. Please wait and try again. If you need to reset your password, see Reset Password

Adding an Additional Lab Group

If you only need to add an additional lab group in order to use their resources, you can simply request membership in an additional lab group. Once approved by the PI/approver, you will be added to the group.

Your primary group will remain the same as will your primary SLURM (job/fairshare) group.

NOTE: If you will need to be able to run jobs under that secondary group’s fairshare, please send FASRC a ticket (via Email) asking to be added to the lab’s SLURM group. See managing dual/multiple lab affiliations for details on using switching fairshare affiliations on jobs.

Changing Your Primary Lab Group

If, instead, you have a new PI/lab and need to be added to their group and have that become your primary group and sponsor, you will need to:

1. Request membership in the lab group via the FASRC Portal.
   Once approved by your new PI/sponsor you will be added to their group.
2. Once you belong to the new group, send FASRC a ticket (Email) explaining that you have been added to the new group and would like to have your primary group changed to the new lab.
   You should also indicate whether or not you should retain membership in your previous lab group.
3. FASRC will contact your new PI for confirmation then change your primary group to your new lab group, change your sponsor to your new PI, and, unless otherwise noted, remove you from your previous lab group.

Please note that FASRC has no indication when people change lab groups and rely on the user or PI informing us and asking for this affiliation change.

NOTE: Acquiring a grant does not ascribe PI rights unless/until the university confers those rights.

Each PI has a lab group, each lab group has resources, and each lab group can have members who are approved by that PI through the Portal. Every account belongs to a primary lab group (their sponsor), but they may also belong to secondary groups in order to collaborate and access their resources.

NOTE: Adding an additional group does not change one’s sponsor/primary group.

Q: I’ve changed lab groups, do I just request access to that lab group through the Portal?
A: You can request membership in the lab group via the Portal, but you will need to contact FASRC to have your primary group/sponsor changed.

Q: I belong to another lab group. How do I run jobs under that group’s fairshare and not my primary?
A: You will need to use the --account flag in your jobs. See this doc for more: Manage dual/multiple lab affiliations

Your FASRC Unix username does not contain any symbols, and is not your email address/Harvard Key. It contains only letters and possibly numbers. For example: jharvard is a username, while jharvard@harvard.edu is not.

CLUSTER LOGIN

So, for example, when you log into VDI or our Portal you will use your FASRC username and password. Like:

Username: jharvard
Password: *********

When you SSH to a cluster login login node you will use your FASRC username, password, and two-factor code. Like:

ssh jharvard@login.rc.fas.harvard.edu (The @ here signifies what node to connect to. It’s not a part of your username.)
Password:
Verification code:

NOTE: You will NOT see any dots or typing in the Password or Verification Code fields when you  SSH.

EXCEPTIONS

There are some exceptions:

1. When connecting to the FASRC VPN, you will need to use your username + a VPN realm name. That realm name is almost always @fasrc unless you access a different realm for your work (for example, if you are in the NCF you will use @fasse).
   Example: User jharvard would connect to the VPN as jharvard@fasrc
   
2. When connecting to a lab share via Samba (aka SMB, CIFS, ‘mapped drive’), you may need to prefix your username with our Samba domain name. See the following doc for more information on mapping shares: Mounting Storage on Desktop or Laptop
3. When resetting your password, you will use your email address to request a password reset. This is the only place where your email address is used.
   

HARVARD KEY

If a system requires your Harvard Key/Email address, that will be made clear in the login form details.

The sharing of passwords or login credentials is not allowed under RC and Harvard information security policies. Please bear in mind that this policy also protects the end-user.

Sharing credentials removes the ability to audit and accountability for the account holder in case of account misuse. Accounts which are in violation of this policy may be disabled or otherwise limited. Accounts knowingly skirting this policy may be banned.

If you find that you need to share resources among multiple individuals, Faculty can approve accounts for outside collaborators to their lab groups. Otherwise, please contact us and we will be happy to assist you with finding a safe and secure way to do so.

This is not permanent and your account will automatically unlock after about 5 – 10 minutes. If your account remains locked for longer please contact us.