Mailing List Archives
Authenticated access
|
|
|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[HTCondor-users] Automatically adding job attributes based on owner's LDAP groups
- Date: Tue, 11 Apr 2017 10:47:26 -0500
- From: Vladimir Brik <vladimir.brik@xxxxxxxxxxxxxxxx>
- Subject: [HTCondor-users] Automatically adding job attributes based on owner's LDAP groups
Hello.
I would like automatically add an "OwnerGroup" attribute to jobs at
submission time based on the the submitting user's LDAP group
memberships (OwnerGroup will later be used in RANK expression). I've
tried a couple of approaches but I am wondering if there is a better
solution I am not seeing.
Background: In the simplest case, if Special-Group-1 is among the groups
a user belongs to, I would like all their jobs to have
OwnerGroup=Special-Group-1 attribute set. I would rather avoid exposing
all LDAP groups in job classads. In some cases, a simple logic may be
required to properly determine OwnerGroup, depending on combination of a
user's LDAP groups.
My first attempt was to implement this as a custom ClassAd python
function, but I couldn't get it to work (my OwnerGroup SUBMIT_ATTRS
wouldn't actually evaluate, so the classad literally had
OwnerGroup=get_owner_group()). Is this a feasible approach? (I am on
8.5.8 but could upgrade).
The solution I have now uses TJ's trick from an earlier thread:
include command : /usr/local/libexec/set_OwnerGroup.sh
SUBMIT_ATTRS = OwnerGroup
My main concern with this approach is that set_OwnerGroup.sh is executed
whenever a condor daemon is configured. The script is very quick, but I
am a bit worried about what will happen on a busy submitter with many
shadows starting up and hitting nscd hard.
Is is possible to use if/else in condor config to restrict which demons
actually execute "include command"?
I guess I could also add an appropriate ~/condor_config to skel or
profile.d, but that seems hackish somehow.
I also wonder if I am trying to reinvent the wheel here. It seems like
getting owner's LDAP groups into job classad wouldn't be a very exotic
need. Perhaps a standard solution exists?
Apologies for another long message, and thanks in advance!
Vlad