Workspace: Difference between revisions
(Insert and adapt description on Workspace Sharing from NEMO Wiki.) |
K Siegmund (talk | contribs) |
||
(4 intermediate revisions by 3 users not shown) | |||
Line 49: | Line 49: | ||
== Sharing Workspace Data within your Workgroup == |
== Sharing Workspace Data within your Workgroup == |
||
Data in workspaces can be shared with colleagues. Making workspaces world readable/writable using standard unix access rights with < |
Data in workspaces can be shared with colleagues. Making workspaces world readable/writable using standard unix access rights with <tt>chmod</tt> is strongly discouraged for bwUniCluster, as the groups are defined too course-grained, allowing access for too many people. They may work for you on the bwForClusters, where you and your co-workers of a research group share a common bwXXXXX unix group. |
||
ACLs have the additional advantage that you can set a "default" ACL for a directory, (with a <tt>-d</tt> flag or a <tt>d:</tt> prefix) which will cause all newly created files to inherit the ACLs from the directory. Regular unix permissions only have limited support (only group ownership, not access rights) for this via the suid bit. |
|||
It is therefore recommended to use ACLs (Access Control List) if they are available on the cluster. |
|||
Best practices with respect to ACL usage: |
Best practices with respect to ACL usage: |
||
* Take into account that ACL take precedence over standard unix access rights |
* Take into account that ACL take precedence over standard unix access rights |
||
* Use a single set of rules at the level of a workspace |
|||
* Make the entire workspace either read-only or read-write for individual co-workers |
|||
* Optional: Make the entire workspace read-only for your Rechenvorhaben, e.g. for large input data |
|||
* If a more granular set of rules is necessary, consider using additional workspaces |
|||
* The owner of a workspace is responsible for its content and management |
* The owner of a workspace is responsible for its content and management |
||
Line 64: | Line 64: | ||
{| class="wikitable" |
{| class="wikitable" |
||
|- |
|- |
||
!style="width: |
!style="width:45%" | Command |
||
!style="width: |
!style="width:55%" | Action |
||
|- |
|- |
||
|<tt>getfacl $(ws_find my_workspace)</tt> |
|<tt>getfacl $(ws_find my_workspace)</tt> |
||
|List access rights on the workspace named "my_workspace" |
|List access rights on the workspace named "my_workspace" |
||
|- |
|- |
||
|<tt>setfacl -Rm u: |
|<tt>setfacl -Rm u:fr_xy1:rX,d:u:fr_xy1:rX $(ws_find my_workspace)</tt> |
||
|Grant user " |
|Grant user "fr_xy1" read-only access to the workspace named "my_workspace" |
||
|- |
|- |
||
|<tt>setfacl -Rm u: |
|<tt>setfacl -Rm u:fr_me0000:rwX,d:u:fr_me0000:rwX $(ws_find my_workspace)</tt> |
||
<tt>setfacl -Rm u:fr_xy1:rwX,d:u:fr_xy1:rwX $(ws_find my_workspace)</tt> |
|||
|Grant user "fr_xy1001" read and write access to the workspace named "my_workspace" |
|||
|Grant your own user "fr_me0000" and "fr_xy1" inheritable read and write access to the workspace named "my_workspace", so you can also read/write files put into the workspace by a coworker |
|||
|- |
|- |
||
|<tt>setfacl -Rm g:bw16e001:rX,d:g:bw16e001:rX $(ws_find my_workspace)</tt> |
|<tt>setfacl -Rm g:bw16e001:rX,d:g:bw16e001:rX $(ws_find my_workspace)</tt> |
||
Line 82: | Line 83: | ||
|Remove all ACL rights. Standard Unix access rights apply again. |
|Remove all ACL rights. Standard Unix access rights apply again. |
||
|- |
|- |
||
|<tt>chgrp -R bw16e001 $(ws_find my_workspace)</tt> |
|||
⚫ | |||
<tt>chmod -R g+rX $(ws_find my_workspace)</tt> |
|||
|Set group ownership and grant read access to group for files in workspace via unix rights (has to be re-done if files are added) |
|||
|- |
|||
|<tt>chgrp -R bw16e001 $(ws_find my_workspace)</tt> |
|||
<tt>chmod -R g+rswX $(ws_find my_workspace)</tt> |
|||
|Set group ownership and grant read/write access to group for files in workspace via unix rights (has to be re-done if files are added). Group will be inherited by new files, but rights for the group will have to be re-set with chmod for every new file |
|||
⚫ | |||
|} |
|||
== Delete a workspace == |
== Delete a workspace == |
Revision as of 11:38, 11 September 2024
Workspace tools provide temporary scratch space so calles workspaces for your calculation on a central file storage. They are meant to keep data for a limited time – but usually longer than the time of a single job run. It is not meant for permanent storage, hence data in workspaces is not backed up and may be lost in case of problems on the storage system. Please copy/move important results to $HOME or some disks outside the cluster.
Create workspace
To create a workspace you need to state name of your workspace and lifetime in days. A maximum value for lifetime and a maximum number of renewals is defined on each cluster. Execution of:
$ ws_allocate blah 30
e.g. returns:
Workspace created. Duration is 720 hours. Further extensions available: 3 /work/workspace/scratch/username-blah-0
For more information read the program's help, i.e. $ ws_allocate -h.
List all your workspaces
To list all your workspaces, execute:
$ ws_list
which will return:
- Workspace ID
- Workspace location
- available extensions
- creation date and remaining time
Find workspace location
Workspace location/path can be prompted for any workspace ID using ws_find, in case of workspace blah:
$ ws_find blah
returns the one-liner:
/work/workspace/scratch/username-blah-0
Extend lifetime of your workspace
Any workspace's lifetime can be only extended a cluster-specific number of times. There several commands to extend workspace lifetime
$ ws_extend blah 40
which extends workspace ID blah by 40 days from now,$ ws_extend blah
which extends workspace ID blah by the number days used previously$ ws_allocate -x blah 40
which extends workspace ID blah by 40 days from now.
Sharing Workspace Data within your Workgroup
Data in workspaces can be shared with colleagues. Making workspaces world readable/writable using standard unix access rights with chmod is strongly discouraged for bwUniCluster, as the groups are defined too course-grained, allowing access for too many people. They may work for you on the bwForClusters, where you and your co-workers of a research group share a common bwXXXXX unix group.
ACLs have the additional advantage that you can set a "default" ACL for a directory, (with a -d flag or a d: prefix) which will cause all newly created files to inherit the ACLs from the directory. Regular unix permissions only have limited support (only group ownership, not access rights) for this via the suid bit.
It is therefore recommended to use ACLs (Access Control List) if they are available on the cluster.
Best practices with respect to ACL usage:
- Take into account that ACL take precedence over standard unix access rights
- The owner of a workspace is responsible for its content and management
Please note that ls (List directory contents) shows ACLs on directories and files only when run as ls -l as in long format, as "plus" sign after the standard unix access rights.
Examples with regard to "my_workspace":
Command | Action |
---|---|
getfacl $(ws_find my_workspace) | List access rights on the workspace named "my_workspace" |
setfacl -Rm u:fr_xy1:rX,d:u:fr_xy1:rX $(ws_find my_workspace) | Grant user "fr_xy1" read-only access to the workspace named "my_workspace" |
setfacl -Rm u:fr_me0000:rwX,d:u:fr_me0000:rwX $(ws_find my_workspace)
setfacl -Rm u:fr_xy1:rwX,d:u:fr_xy1:rwX $(ws_find my_workspace) |
Grant your own user "fr_me0000" and "fr_xy1" inheritable read and write access to the workspace named "my_workspace", so you can also read/write files put into the workspace by a coworker |
setfacl -Rm g:bw16e001:rX,d:g:bw16e001:rX $(ws_find my_workspace) | Grant group (Rechenvorhaben) "bw16e001" read-only access to the workspace named "my_workspace" |
setfacl -Rb $(ws_find my_workspace) | Remove all ACL rights. Standard Unix access rights apply again. |
chgrp -R bw16e001 $(ws_find my_workspace)
chmod -R g+rX $(ws_find my_workspace) |
Set group ownership and grant read access to group for files in workspace via unix rights (has to be re-done if files are added) |
chgrp -R bw16e001 $(ws_find my_workspace)
chmod -R g+rswX $(ws_find my_workspace) |
Set group ownership and grant read/write access to group for files in workspace via unix rights (has to be re-done if files are added). Group will be inherited by new files, but rights for the group will have to be re-set with chmod for every new file |
Delete a workspace
$ ws_release blah # Manually erase your workspace blah