> Am 22.03.2018 um 16:33 schrieb leconte jérôme > <jerome.leco...@i2bc.paris-saclay.fr>: > >> Maybe the correct question is - why do you not want the users to use SSH? >> If you are trying to restrict users to only being able to access a node >> that they have a job running on, there is a PAM module for that. > >> Ian > > > > Thank you Ian > > now My user use ssh to execute their own program without using qsub. > and it's not really fair for other user that use qsub. > > Then the simpliest way avoiding this is to forbiden the connection > > I'm not specialist of PAM and authentication have you got a link ?
After setting up the cluster in the way I outlined, this step is optional to allow users to peek around on the exechosts while their jobs are running (one can even limit the "cpu time" for the SSH login in the limit to prevent abuse of this granted option). But this is optional. GridEngine writes the stderr and stdout files live (other queuingsystems copy them only after the job to the working directory [resp. specified directory]). Even setting the working directory to be $TMPDIR in the job script (as many jobs will put their scratch data just there), still allows to write any other file live. Some applications which won't accept any specified paths in command line argument can be tricked by a symbolic link. Imagine the special output is called "foo" and will go to $TMPDIR without option to change it, and you want to see it during execution without logging in to the node: #!/bin/sh ... OUTPUT_FILE=foo WORKDIR=$(pwd) cd $TMPDIR ln -s "$WORKDIR/$OUTPUT_FILE" # No typo: missing link name will use the file name of the target file So it will in reality be written to the directory with the input file of the job (and often such "foo" files are small text files and won't create much network traffic or load on the file server). -- Reuti _______________________________________________ users mailing list users@gridengine.org https://gridengine.org/mailman/listinfo/users
