[torqueusers] disabling direct access to compute nodes

Prakash Velayutham prakash.velayutham at cchmc.org
Sat Oct 6 05:59:26 MDT 2007


Hi,

If you compiled with --with-pam, you should find a  
pam_pbssimpleauth.so under <TORQUE_SRC>/src/pam folder. Please copy  
this over to /lib<64>/security/ folder.
And then edit your pam files (I am using SuSE, so I had to edit just  
the common-account file, but different distros package this a little  
differently). This is what I have in my common-account file.

account required        pam_unix2.so
account    sufficient   pam_pbssimpleauth.so debug
account    required     pam_access.so

That is it.

Let me know if you need more help. Do provide your distro and  
version, so I can give more specific tips.
Prakash

On Oct 5, 2007, at 4:08 PM, Markus Seto wrote:

> Hey,
>
> No problem.  I compiled with the --with-pam option, and i have a
> pam_authuser.so file now.  But the docs say to edit /etc/system-auth ,
> but it doesn't say how - do you know to work it?
>
>
> On 10/5/07, Prakash Velayutham <prakash.velayutham at cchmc.org> wrote:
>> 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