Il 12/02/2016 06:26, Christopher Samuel ha scritto:
> It's interesting timing as I'm helping a group bring up a cluster
> themselves that they want to auth against the university AD and
> so we could be in the same boat.
Auth is not a big issue. If you need help with joining the machine, I
can help you off-list.
Authorizing only some groups to submit jobs to a queue is a completely
different story. It was easy in torque+moab, since it leveraged the
standard Unix lookups.
I resorted to a scipt, called by
PrologSlurmctld=/etc/slurm-llnl/SlurmCtldProlog.sh
The scipt is:
--8<--
#!/bin/bash
case "$SLURM_JOB_PARTITION" in
hpc_inf|hpc_large) ALLOWED=Str957-bl0-abilitati-baldi
;;
*) ALLOWED=Str957-bl0-abilitati
esac
RV=0
# "getent groups" does not recurse :(
ID=$(/usr/bin/id $SLURM_JOBUSER)
echo $ID | /bin/grep -qi $ALLOWED || (RV=1; /usr/bin/scancel $SLURM_JOBID)
#/usr/bin/env >> /tmp/env.txt
return $RV
--8<--
BTW I think doc is not accurate, since it says (from
http://slurm.schedmd.com/prolog_epilog.html ) that
>> Note that for security reasons, these programs do not have a
>> search path set.
Actually, at least /bin and /usr/bin are searched anyway, but I
preferred to use the full paths.
Probably it could be better to add an
echo 'print Cancelled for insufficient privilege'
just before scancel, but I've not tested it.
> They reckon, though, that the fact that the intention is to limit
> cluster access to a particular group in AD means that the enumeration
> will be limited to members of that group.
> It'll be interesting to see if they're right..
Yep. But watch out for nested groups!
I just noticed that "getent group <groupname>" does *not* return users
in nested groups.
--
Diego Zuccato
Servizi Informatici
Dip. di Fisica e Astronomia (DIFA) - Università di Bologna
V.le Berti-Pichat 6/2 - 40127 Bologna - Italy
tel.: +39 051 20 95786
mail: [email protected]
