[slurm-users] Users able to submit jobs when they don't exist

Tim Bishop tim-lists at bishnet.net
Fri Sep 14 11:08:04 MDT 2018

On Fri, Sep 14, 2018 at 02:34:10PM +0200, Loris Bennett wrote:
> Tim Bishop <tim-lists at bishnet.net> writes:
> > New member to the list, and we've only been using Slurm for a few
> > months. Everything is working well but I have some questions about user
> > management.
> >
> > Our setup is that users are managed via LDAP. They exist on all compute
> > nodes and on the submission node, but not on the controller (possibly an
> > oversight). I've seen two problems here;
> >
> > 1. squeue shows jobs running as "nobody". I'm thinking this might be
> > because users don't exist on the controller? Presumably there needs to
> > be a UID->name mapping happening.
> >
> > 2. We have users on the submission node (it's used for other things too)
> > that don't exist anywhere else within the Slurm cluster and they can
> > still submit jobs. I'd have expected them to fail because the user
> > doesn't exist, however they just run under the UID.
> >
> > Old code [1] has a pwuid call which appears to generate a failure if a
> > user can't be found. But maybe this disappeared during some later
> > refactoring?
> >
> > I have accounting set up but haven't dug much in to this. I've just read
> > through the recent thread "Create users" and it looks like I need to be
> > creating users within Slurm and then use AccountingStorageEnforce to
> > ensure only users that exist in the accounting database can run jobs.
> > Does that look like the right approach? There's some useful stuff in
> > that thread about automating user creation too.
> Yes, you're on the right track.  You have to use 'sacctmgr' to create
> users that Slurm should know about, potentially within a hierarchy which
> reflects your organisation.
> Ole Holm Nielsen has some interesting tools here:
>   https://github.com/OleHolmNielsen/Slurm_tools/tree/master/slurmaccounts
> As mentioned, we on the other hand add users via a wrapper around
> 'sacctmgr' when we set users up.  This is just one step in a framework
> which also informs the user and the PI via email that the access has
> been granted.  The "create-Slurm-user-on-first-submit" approach Paul
> Edmon describes also seems interesting.

Thanks Loris, that's some useful information. I'll need to do something
that runs on a regular basis and syncs LDAP data to Slurm, but that
doesn't look too hard. The tools you linked above would certainly be a
good starting point.



Tim Bishop
PGP Key: 0x6C226B37FDF38D55

More information about the slurm-users mailing list