How To Allow Only One User

Sometimes you may want to limit a set of machines to either

  1. only run jobs from a specific user or set of users, or

  2. only allow ONE active user per execute node, so that on a execute node using partitionable slots, if UserA lands on machine Execute1 and uses say 2 out of 10 cpus, then UserA is also allowed to claim more slots on that machine and UserB would not be allowed. Once UserA jobs have completed on Execute1, then if UserB landed on that machine, only userB would then be allowed to claim additional slots/resources on Execute1.

We give recipes for each of the above scenarios below.

Only run jobs from a specific user or set of users

To specify that a given machine should only run certain users' jobs, and always run the jobs regardless of other activity on the machine, load average, etc., place the following entry in the machine's HTCondor configuration file:

START = ( (User == "userfoo@baz.edu") || \
          (User == "userbar@baz.edu") )

Only allow ONE active user per execute node

Imagine you only want to allow ONE active user per execute machine on machine configured to use partitionable slots. This may be a security requirement at some sites. So the idea is if UserA lands on machine Execute1 and uses say 2 out of 10 cpus, then UserA is also allowed to claim more slots on that machine and UserB would not be allowed. Once UserA jobs have completed on Execute1, then if UserB landed on that machine, only userB would then be allowed to claim additional slots/resources on Execute1.

To accomplish this on HTCondor v8.4 or above, append the following into the condor_config file(s) of the machines where you only want one user per node:

START = ( $(START) ) && \
        ifThenElse(PartitionableSlot=?=True && UpdatesLost=!=UNDEFINED, \
                size(ChildRemoteUser)==0 || member(User,ChildRemoteUser), \
                RemoteUser=?=UNDEFINED || User=?=RemoteUser)

The expression above leverages the fact that User is an attribute in the job classad that identifies the submitting user. Attribute RemoteUser is in a slot ad, and equals the user of whomever claimed the slot. Attribute ChildRemoteUser is in the partitionable slot ad in the collector, and will be a classad list containing the all RemoteUser values of all the dynamic slots created under that partitionable slot.

The above configuration is a bit complicated. We hope to make the idea of one user claiming an entire machine more straightforward in a future release.