Is there a mechanism by which multiple users can be authorized to interact with a job? As an example, on another scheduler I have worked with, there was a --run_users=userid1:userid2:…:useridN option on qsub. That enabled any user in the list to hold, alter, delete, etc the job. The reason for this is that we occasionally have projects that run “campaigns” 24x7 and they rotate people on shifts to monitor and make necessary fixes / adjustments to the jobs, so they want anyone on the list to be able to control the jobs. I went through the doc and did not see anything. I thought -u might do it, but that appears to be to map different usernames on different systems to the same person. Did I miss something? Any ideas for a different way to address such a situation?
I would propose creating a functional account that “owns” the “campaign” work and instruct users to “su” to that account in order to submit jobs (qdel, qalter, etc).
The functional account and the users in question could even all belong to the same group, and if the functional account’s umask is set appropriately the users could still interact with the data from the jobs without needing to access the account.
Thanks for the idea. I will explore it, but unfortunately, I suspect I will get lots of pushback. Shared accounts are absolutely verboten, so our cyber folks would probably nix it, and I would also not make friends in our user services group if they started having to create a bunch of extra accounts, though it doesn’t happen that often, so that would probably be manageable.
There are three “roles” in PBS… users, operators, and managers. Managers have full reign, able to set security related attributes. Operators are restricted managers, unable to alter security related settings but able to delete/rerun/hold jobs for all users. This may be more privilege than you want to offer, but it is an option.
Of course, we can always extend PBS to allow such additional functionality, and this one sounds like a good proposition. How about we request the community to implement this? Sounds like a fairly low hanging fruit to me!
We will probably implement it at some point, just not sure when. I was mostly looking for input as to whether this functionality might be already there and I had just missed it or there was a way to get the equivalent functionality some other way.