We would like to create a “no submit” group, such that any users in that group are prevented from submitting jobs to any queues. My intuition says to do something like this at the top level of the config:
set server acl_groups_enable = True
set server acl_groups -= no_submit_group
But I have a couple of questions:
Can a user in no_submit_group circumvent the ACL by setting their submit group to another group they belong to?
Will this have any unintended trickle down effects into other ACLs? For example, we have several acl_groups and acl_users directives in individual queues, operating as whitelists. Will a top-level blacklist interfere with queue-level whitelists?
Which ACLs at which levels take precedence? Say, for example, I want a group that can only submit to a single queue and no other queues. Would I do a acl_groups -= only_queue_x at the server level and then acl_groups += only_queue_x at the queue level?
which can check the user, their group and queue to which they have submitted the job and take actions on accepting or rejecting the job with an appropriate message or instructions or info on why it was not accepted. In this way, these jobs would not be accepted into system at all in the first place and users are well informed
or
queuejob hook can be made to read a file which has all the mappings of the users , groups and queue and then upon job submission , this queuejob hook can check the user and their requests against this mapping file and decide whether to accept or reject the job submission.
Please follow this section:
snippet from the PBS Professional Administrator Guide
Just to be clear: Are you saying that queue ACLs cannot work as blacklists?
I get that you can do pretty much anything with the hooks framework, but for us, it is a last resort because it adds an additional layer of complexity that makes the scheduler configuration more difficult to reason about.
acl_groups is not a server level attribute, it is a queue level attribute
Yes, acl_users and acl_groups (to which user might belong and might or might not be part of acl_users) would have some issue ( i think/suspect). For all these use cases , if there are discrepancies increase server and scheduler log level and check the cause for not working correctly.
Yes, that can happen
From admin guide and man pages:
acl_groups : List of groups which are allowed or denied access to this queue. The groups in the list are groups on the server host, not submitting hosts. List is evaluated left-to-right; first match in list is used.
group_list : man qsub
A list of group names used to determine
the group under which the job runs. When
a job runs, the server selects a group name
from the list according to the following
ordered set of rules:
Select the group name for which the
associated host name matches the name of
the server host.
Select the group name which has no
associated host name.
Use the login group for the user name
under which the job will be run.
queue ACLs can work as blacklists, however, you get more control and logic appliend in queuejob hook event.
Thanks, @adarsh. This is all very helpful. Especially the bit about not being able to use ACLs at the server level. In that case, I can see why you recommend the hook approach.
