[torqueusers] disabling direct access to compute nodes

Prakash Velayutham prakash.velayutham at cchmc.org
Fri Oct 5 13:35:51 MDT 2007


Hello,

Sorry, my bad. If you compiled Torque with the option --with-pam, you  
should have a pam_pbssimpleauth PAM module already available in the  
compilation area. You can just drop this .so file in the PAM security  
libraries location and depending on your distro docs, do the required  
PAM config.

That should go easily and you should have everything work well.  
Please holler if you need more help.

Prakash

On Oct 5, 2007, at 3:24 PM, Markus Seto wrote:

> I've been trying to find this contrib directory but the only
> directories installed in my torque directory on the master node are:
>
> bin
> etc
> include
> lib
> man
> sbin
>
>
> where is the default location for this directory?
>
> thanks
>
> On 10/5/07, Prakash Velayutham <prakash.velayutham at cchmc.org> wrote:
>> Hello,
>>
>> Use pam_authuser that comes with Torque distribution under contrib
>> folder. This works beautifully and lets a user access a node using
>> SSH only if he has a valid job running in that node. Otherwise he is
>> rejected.
>>
>> Prakash
>>
>> On Oct 5, 2007, at 3:08 PM, Ole Holm Nielsen wrote:
>>
>>> Markus Seto wrote:
>>>> Hi, I've recently started fiddling with a torque installation, and
>>>> was
>>>> wondering if it's possible to disable direct access to the compute
>>>> nodes
>>>> from the master node.  I've noticed some users cheating the system
>>>> and
>>>> directly logging into compute nodes to run jobs, and I want to
>>>> force them to
>>>> use the queue system, but I was told that direct access with ssh
>>>> keys is
>>>> needed for torque to run.  any ideas?
>>>
>>> The low-tech bullet-proof method we use is to have separate login
>>> nodes for
>>> users.  We restrict logins to the master server by using the
>>> AllowUsers
>>> option in /etc/ssh/sshd_config (see "man sshd_config") so that
>>> normal users
>>> can't login there.
>>>
>>> Now, the login nodes are on our public network, whereas all compute
>>> nodes are on a private network (the master server of course connects
>>> to both of these networks).  Users on the login nodes can submit  
>>> jobs
>>> etc., but they have NO way of ever communicating with the compute
>>> nodes !
>>> They can communicate with the master server, and that's it !
>>>
>>> Some people may think that the submit nodes must be able to
>>> communicate
>>> with the compute nodes in order for the batch system to work, but  
>>> that
>>> is just not true.  Of course, your NFS filserver (if it's different
>>> from
>>> the master server) must connect to both the private and the public
>>> network
>>> as well.
>>>
>>> The disadvantages: With our setup interactive Torque jobs (qsub -I)
>>> are not possible.  The workaround: If a few select users genuinely
>>> need interactive login access to the compute nodes, then we enable
>>> their login to the master server by adding them in the /etc/ssh/
>>> sshd_config
>>> file.  If you don't like to allow user logins to the master server,
>>> a dedicated login server with restricted logins could be made in  
>>> stead
>>> with a second network card that connects to the private network.
>>>
>>> Best regards,
>>> Ole
>>> _______________________________________________
>>> torqueusers mailing list
>>> torqueusers at supercluster.org
>>> http://www.supercluster.org/mailman/listinfo/torqueusers
>>
>> _______________________________________________
>> torqueusers mailing list
>> torqueusers at supercluster.org
>> http://www.supercluster.org/mailman/listinfo/torqueusers
>>
> _______________________________________________
> torqueusers mailing list
> torqueusers at supercluster.org
> http://www.supercluster.org/mailman/listinfo/torqueusers



More information about the torqueusers mailing list