Spent some of yesterday playing with VOMS and the static grid-mapfile mappings we put into the system. The point of these was to support users who were not yet in any VO and might be using globus-job-* commands to submit jobs to the cluster. For these users it was obviously important that they mapped to the same account on the batch system as on the UI. (What actually happens is that the UI mirrors its grid-mapfile from the CE.)
However, we now have a different class of user, one who might use gsissh to access the cluster, but use the RB to submit jobs and be in a VO. For this user we need a local mapping in the grid-mapfile, but we need to ensure that job submission is made with a normal VO mapped pool account.
To test this I mapped myself to a local account (gla012) on the UI, using gsissh to login. Then I initalised a VOMS proxy and submitted a job. The job correctly ran as dteam.
This means we can support our multiple classes of users, and also users in multiple VOs, in a relatively straightforward way.
One point for the local account, though, is that we will put the local account into the correct group for the user's expected VO. This means that job submission with a vanilla proxy will work as expected.
(An outstanding problem might well be data write access - at the moment the data users put onto nfs using their local account is fine for writing, but the area cannot be written to. This may be an issue for some people.)
No comments:
Post a Comment