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

1: 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.

{subsection: 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:

{code}
START = ( (User == "userfoo@baz.edu") || \
          (User == "userbar@baz.edu") )
{endcode}

{subsection: 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:

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

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.