1.3 Advanced Configuration
Home Up Previous Next TORQUE Resource Manager

1.3 Advanced Configuration

  • 1.3.1 Customizing the Install
  • 1.3.2 Server Configuration
    • 1.3.2.1 Server Config Overview
    • 1.3.2.2 Name Service Config
    • 1.3.2.3 Configuring Job Submission Hosts
    • 1.3.2.4 Configuring TORQUE on a Multi-Homed Server
    • 1.3.2.5 Architecture Specific Notes

1.3.1 Customizing the Install

The TORQUE configure command takes a number of options. A few key options:
  • By default, TORQUE does not install the admin manuals. To enable this, use '--enable-docs'
  • By default, TORQUE uses rcp to copy data files. Using scp is highly recommended, use '--with-scp'
  • By default, TORQUE does not enable syslog usage. To enable this, use '--enable-syslog'

Configure Option List

Recommended Configure Options

The complete list of ./configure options can be found here. Most recommended configure options have been selected as default. The few exceptions include '--with-scp' and possibly '--enable-syslog'.

1.3.2 Server Configuration

1.3.2.1 Server Config Overview

There are several steps to ensure that the server and the nodes are completely aware of each other and able to communicate directly. Some of this configuration takes place within TORQUE directly using the "qmgr" command. Other configuration settings are managed using the pbs_server nodes file, DNS files such as "/etc/hosts" and the "/etc/hosts.equiv" file.

1.3.2.2 Name Service Config

Each node, as well as the server, must be able to resolve the name of every node with which it will interact. This can be accomplished using "/etc/hosts", DNS, NIS, or other mechanisms. In the case of "/etc/hosts", the file can be shared across systems in most cases.

A simple method of checking proper name service configuration is to verify that the server and the nodes can "ping" each other.

1.3.2.3 Configuring Job Submission Hosts

Using RCmd Authentication

When jobs can be submitted from several different hosts, these hosts should be trusted via the R* commands (i.e., rsh, rcp, etc.). This can be enabled by adding the hosts to the "/etc/hosts.equiv" file of the machine executing the pbs_server daemon or using other R* command authorization methods. The exact specification can vary from OS to OS (see the man page for ruserok to find out how your OS validates remote users). In most cases, configuring this file is as simple as adding a line to your "/etc/hosts.equiv" as in the following:

hosts.equiv
#[+ | -] [hostname] [username]
mynode.myorganization.com
.....

Please note that when a hostname is specified, it must be the fully qualified domain name (FQDN) of the host. Job submission can be further secured using the server or queue acl_hosts and acl_host_enabled parameters.

Using the 'submit_hosts' Server Parameter

Trusted submit host access may be directly specified without using RCmd authentication by setting the server submit_hosts parameter via qmgr as in the example below:

qmgr
> qmgr -c 'set server submit_hosts = login1'
> qmgr -c 'set server submit_hosts += login2'
> qmgr -c 'set server submit_hosts += login3'

Note Use of submit_hosts is potentially subject to DNS spoofing and should not be used outside of controlled and trusted environments.

Allowing Job Submission from Compute Hosts

If desired, all compute nodes can be enabled as job submit hosts without setting .rhosts or hosts.equiv by setting the allow_node_submit parameter to true.

1.3.2.4 Configuring TORQUE on a Multi-Homed Server

If the pbs_server daemon is to be run on a multi-homed host (a host possessing multiple network interfaces), the interface to be used can be explicitly set using the SERVERHOST parameter.

1.3.2.5 Architecture Specific Notes

1.3.2.5.1 Mac OS/X Specific Notes

With some versions of Mac OS/X, it is required to add the line $restricted *.<DOMAIN> to the pbs_mom config file. This is required to work around some socket bind bugs in the OS.

1.3.2.6 Specifying Non-Root Administrators

By default, only root is allowed to start, configure and manage the pbs_server daemon. Additional trusted users can be authorized using the parameters managers and operators. To configure these parameters use the qmgr command as in the example below:

moab.cfg:
> qmgr

Qmgr: set server managers += josh@*.fsc.com
Qmgr: set server operators += josh@*.fsc.com

All manager and operator specifications must include a user name and either a fully qualified domain name or a host expression.

Note To enable all users to be trusted as both operators and admins, place the '+' character (plus) on its own line in the file server_priv/acl_svr/operators and server_priv/acl_svr/managers.

See Also


Home Up Previous Next