[Beowulf] Restricting users from ssh into nodes

[Daniel Kidger]

Just 3 more things to think about re where ssh should be enabled or
disabled.

1. Many people's job scripts use ssh either directly (to say clean up /tmp)
or indirectly from mpirun. (good mpirun's use the batch engine's per-node
daemon to launch the binaries not ssh). Hence simple disabling of ssh will
break many batch scripts.

2. Some 'batch jobs' are actually interactive sessions - eg salloc in SLURM
for interactive debugging sessions.

3. If a user has a a set of say 32 nodes allocated to them and in use for
one of their batch jobs, it is reasonable to allow them interactive access
to those compute nodes - eg for profiling, debugging or computational
steering.

Daniel

Daniel Kidger
Bull Information Systems, UK



On 25 July 2013 06:08, Christopher Samuel <samuel at unimelb.edu.au> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 25/07/13 14:40, Mark Hahn wrote:
>
> > do you really find users who decide to choose their own nodes?
>
> In the past yes, they've come from places who either haven't had a
> queuing system or who haven't use HPC before and haven't read the docs
> or been to the courses.
>
> > limiting ssh access, done right, can permit (c) and prevent (a).
>
> That's what we do.  Users can login to nodes their jobs are on. I'm
> hoping that the aims of the Slurm PAM module to be able to move users
> SSHing into the node into the cgroup for their jobs will get
> implemented.   That way if they do login and run stuff that impacts
> they'll only hurt their own jobs.
>
> > we don't really see (a) enough to worry about it (we're pretty big
> > on at least basic user inculcation...)  and most of (b) I see is
> > actually not helped, since the rogue jobs are usually escapees,
> > rather than mis-aimed.
>
> Yeah, we see rogue jobs and have health check scripts that can fix
> them up for the simple cases (and alert us and take the node offline
> for others).  That helps with having to deal with the emails from
> users asking why their jobs are running slower than usual.
>
> > I suppose you could charge by utime+stime rather than real time.
>
> That would mean a lot of extra hacking around as we're using Gold
> (with Torque and Moab) at the moment and will be moving to Slurm in
> the very near future (as it's what we run on our BG/Q), so we bend to
> their whim on charging.
>
> cheers!
> Chris
> - --
>  Christopher Samuel        Senior Systems Administrator
>  VLSCI - Victorian Life Sciences Computation Initiative
>  Email: samuel at unimelb.edu.au Phone: +61 (0)3 903 55545
>  http://www.vlsci.org.au/      http://twitter.com/vlsci
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlHwss4ACgkQO2KABBYQAh8UywCgiFnVHUxTCAF8DPQkdMQCutD8
> PuEAnRz91qSEQM1mfwZfBV7CsoVjZLk/
> =+JDY
> -----END PGP SIGNATURE-----
> _______________________________________________
> Beowulf mailing list, Beowulf at beowulf.org sponsored by Penguin Computing
> To change your subscription (digest mode or unsubscribe) visit
> http://www.beowulf.org/mailman/listinfo/beowulf
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.beowulf.org/pipermail/beowulf/attachments/20130820/6b6bab6e/attachment.html>