Workspace and Submit Access Control Through Groups
Search
- Version 35
- by (unknown)
- Version 36
- by (unknown)
Deletions or items before changed
Additions or items after changed
| 1 | When you get a new hub, by default everyone gets a workspace and can submit jobs to | |||
|---|---|---|---|---|
| 2 | your attached cluster(s). This means that the user can run many different | |||
| 3 | commands both on your hub and on your clusters, in addition to | |||
| 4 | the software applications your hub provides. | |||
| 5 | ||||
| 6 | For some sites, this causes security issues, so you may wish to limit access to the | |||
| 7 | software the user can execute and the clusters he or she can submit jobs too. Usually | |||
| 8 | only tool developers need workspace access. | |||
| 9 | ||||
| 10 | == Limiting Workspace Access == | |||
| 11 | ||||
| 12 | The first thing to do is to ask HUBzero staff to '''change the default to not provide workspace | |||
| 13 | access'''. | |||
| 14 | ||||
| 15 | The user will still be able to run portal applications and pick up their output files | |||
| 16 | by sftp or webdav. | |||
| 17 | ||||
| 18 | Then, to give users a workspace: | |||
| 19 | ||||
| 20 | * login to the Joomla interface | |||
| 21 | * select Components/Groups | |||
| 22 | + | [[Image(findjoomlagroupscomponent.jpg)]]
|
||
| 23 | * locate the app-workspace (Workspace Development) group, click Total Members | |||
| 24 | * add users as appropriate | |||
| 25 | - | + | ||
| 26 | ||||
| 27 | == Limiting Submit Access == | |||
| 28 | ||||
| 29 | There are several aspects to submit access control. | |||
| 30 | ||||
| 31 | # Allow a user run a HUB application that gets submitted | |||
| 32 | as a job to a cluster. | |||
| 33 | # Allow a user run standard unix and shell commands as jobs submitted | |||
| 34 | to a cluster, even something as simple as '''echo hello''' | |||
| 35 | # Allow a user stage his or her own executable to a cluster and run it. | |||
| 36 | ||||
| 37 | === Getting Started === | |||
| 38 | To set access control, you will need to be a member of the group name ''apps''. | |||
| 39 | Membership will give you write permissions | |||
| 40 | on the files ''/opt/submit/sites.dat'' and ''/opt/submit/tools.dat'' and on your HUB. | |||
| 41 | You can add yourself through the Joomla interface as described above. It can take | |||
| 42 | a day before the change propagates through the system. | |||
| 43 | ||||
| 44 | It is a good default to limit the user to running HUB applications. | |||
| 45 | To limit a user to only running HUB applications, ask the submit rules be | |||
| 46 | tightened so that if a user is not in group submit they can | |||
| 47 | '''only run staged applications or executables from ''/apps/'''''. These executables | |||
| 48 | are under control of group ''apps'' thus providing some oversight for the application code. | |||
| 49 | ||||
| 50 | ==== To limit the clusters a user can run on ==== | |||
| 51 | ||||
| 52 | Whether running submit from a workspace or HUB applications, you | |||
| 53 | may want to limit the supercomputing sites that a user can run on. | |||
| 54 | You first need to create a group for each cluster. For example, | |||
| 55 | the hpc2.org HUB has three groups: ''ccr'' (Center for Computational Research), | |||
| 56 | ''ccni'' (Computational Center for Nanotechnology Innovations) and | |||
| 57 | ''sbbnl'' (Stony Brook/Brookhaven National Lab). | |||
| 58 | ||||
| 59 | Next, edit sites.dat | |||
| 60 | ||||
| 61 | For each cluster, add a line to restrict use of the application to the | |||
| 62 | site group associated with the cluster with '''restrictedToGroups = groupname''', e.g. | |||
| 63 | ||||
| 64 | ||||
| 65 | u2-grid | |||
| 66 | venues = u2-grid.ccr.buffalo.edu | |||
| 67 | remotePpn = 2 | |||
| 68 | remoteBatchSystem = PBS | |||
| 69 | remoteUser = hpc2 | |||
| 70 | remoteManager = mpi | |||
| 71 | venueMechanism = ssh | |||
| 72 | remoteScratchDirectory = /san/scratch/grid/grid-tmp/grid-data/hpc2/hpc2jobs/ | |||
| 73 | siteMonitorDesignator = u2-grid | |||
| 74 | arbitraryExecutableAllowed = False | |||
| 75 | checkProbeResult = False | |||
| 76 | restrictedToGroups = ccr | |||
| 77 | ||||
| 78 | ||||
| 79 | Then you can invite the user to join groups for clusters on which | |||
| 80 | she'll be able to run applications. | |||
| 81 | ||||
| 82 | === To limit where the user can run a specific application === | |||
| 83 | ||||
| 84 | An application may be run at more than one site, but you wish to direct a user's | |||
| 85 | run to one particular site. | |||
| 86 | ||||
| 87 | You will need to edit ''/opt/submit/tools.dat'' to set each execution to match one site. | |||
| 88 | Below is an example. If the user is in group ''ccni'', lammps will run on ccni's opteron cluster. | |||
| 89 | If the user is in group ''ccr'', lammps will run on ccr's cluster. | |||
| 90 | ||||
| 91 | ||||
| 92 | lammps | |||
| 93 | destinations = u2-grid | |||
| 94 | executablePath = lmp_linux | |||
| 95 | remoteManager = u2-grid_lammps | |||
| 96 | restrictedToGroups = ccr | |||
| 97 | ||||
| 98 | lammps | |||
| 99 | destinations = rpi-opteron | |||
| 100 | executablePath = ${HOME}/apps/lammps/bin/lmp_opteron | |||
| 101 | remoteManager = rpi-opteron_lammps | |||
| 102 | restrictedToGroups = ccni | |||
| 103 | ||||
| 104 | ||||
| 105 | === To prevent a user from running arbitrary shell commands on a cluster through submit === | |||
| 106 | ||||
| 107 | Users who have a workspace can submit jobs to clusters. | |||
| 108 | Ask the HUB staff to tighten the range of submit jobs so | |||
| 109 | restrictions by user or group can be specified for sites as well as | |||
| 110 | tools. (The keywords and parameters will be specified in sites.dat in | |||
| 111 | the same fashion as tools.dat.) | |||
| 112 | ||||
| 113 | Open the file '' /opt/submit/sites.dat'' on your HUB. | |||
| 114 | For each cluster name, add or change the setting '''arbitraryExecutableAllowed''' to '''False'''. | |||
| 115 | ||||
| 116 | Then you can add users who have a workspace to the group ''submit''. | |||