[Contents] [Prev] [Next] [End]

Chapter 2. Installation

This chapter describes the procedure for loading LSF distribution files and installing the LSF system.

The first sections describe steps common to all installations. The remaining sections give details about specific and optional portions of the installation procedure. You need to read these sections only if you need information not covered in the earlier sections.

Appendix B shows example installation sessions.

Overview

The LSF installation procedure is divided into two parts. The first part is done once, on the file server that will contain the LSF files. The second part is done once on each host in the LSF cluster. After the software is read from the distribution medium, all further installation steps are performed using the lsfsetup command.

Installation takes from 10 to 20 minutes for the first host in an LSF cluster, and approximately 3 minutes for each additional host in the cluster.

The steps covered in this chapter are:

• Uncompressing the LSF distribution files
• Getting a software license key
• Installing the software with lsfsetup

After the software is installed, some setup must be done for each host in the LSF cluster. These steps are given in 'Configuring LSF Cluster'.

If you are upgrading from a previous version of LSF, see 'Upgrading From a Previous Version'.

Instructions for installing LSF in mixed clusters are given in 'Installing LSF with lsfsetup'. Additional information about installing LSF on systems running AFS is given in 'Installing on AFS'. Information about installing LSF on DCE/DFS can be found in 'Installing on DCE/DFS'.

LSF is installed using the lsfsetup command in the distribution directory. The lsfsetup command prompts you for all information needed to install LSF. Most prompts include a default value, displayed in square brackets. If you press [RETURN], the default value is used.

If you type a question mark ([?]) at any prompt, a short help message about that prompt is displayed.

Privileges Needed for Installation

You must have superuser privileges to install LSF.

If you are installing LSF on a Network File System (NFS) mounted directory then the NFS server must allow the root account on the client to write to the mounted file system (it must be exported and mounted setuid).

Reading the Distribution Medium

LSF is available on a variety of distribution media. Each LSF distribution medium is shipped with instructions for reading the software on your system. This procedure creates a directory on your disk, which is the distribution directory. The directory name starts with lsf and includes the LSF version number and host type. For example, the distribution directory for the SunOS 4.1.x version of LSF 3.0 is called lsf3.0_sunos4.

If you obtained LSF by FTP, you can skip directly to 'Uncompressing a Compressed Tar File'.

Loading LSF From a Tape

When LSF is distributed on tape, the tape is in tar format, and the contents are compressed tar archives for each host type supported by LSF. To see the contents of the tape, run the command:

% tar tv

You may need to use the tar f option and specify the name of your tape device.

After you identify the binary versions you want, extract them from the tape with the command

% tar xvf /dev/tape_drive_device filename ...

For example:

% tar xvf /dev/rst1 lsf3.0_aix.tar.Z lsf3.0_alpha.tar.Z

Then uncompress the compressed tar file for each host type as described below.

Uncompressing a Compressed Tar File

LSF is distributed as a compressed tar archive for each host type. The LSF distribution is named depending on the LSF version and host type, for example lsf3.0_sunos4.tar.Z.

To uncompress the distribution, move the compressed tar file to a temporary directory with at least 30 megabytes of available space and run the command:

% zcat lsf3.0_sunos4.tar.Z | tar xf -

This creates a distribution directory called lsf3.0_sunos4.

Getting a License Key

If you received a DEMO license key, you can proceed directly with the installation. To get a permanent license from your LSF vendor, see the Release Notes or 'Getting License Key Information'. You can install LSF with a DEMO license key and change to a permanent license later with no interruption in service.

Store the license key in a file. lsfsetup automatically finds your license key if you store the license key in a file named license.dat in the distribution directory. Otherwise, you must enter the path name of the file during the installation.

Exporting the /usr/local/lsf/mnt Directory

If the /usr/local/lsf/mnt directory (see Figure 2) is not already exported with read/write permission to the other hosts in the cluster, you must configure the file server host to export the directory. It must be exported with setuid enabled.

See the manual pages for nfs and exports for more details.

Installing LSF with lsfsetup

This section gives the steps required to install a mixed LSF cluster on an NFS file system. For a more detailed description of each step, see the sections that follow. If you are installing on an AFS file system, follow the instructions given in 'Installing on AFS'. If you are installing on DCE/DFS, follow the instructions found in 'Installing on DCE/DFS'.

Installing the First Host Type

These steps should be performed once, on the file server host. These installation procedures will work correctly even if the file server host is not the same host type as the LSF software you are installing.

These steps install all the host type independent files, along with the binaries for the first host type. In this example, the HP-UX version of LSF is installed first.

Step 1.

Log in to the file server host as root. Load the HP-UX version of the LSF software from the distribution medium or download it by FTP. Uncompress the compressed distribution file. Change directory to the distribution directory.

Step 2.

Run the ./lsfsetup command. Choose option 1, 'Install for the First Time'. Then specify one or more of the following components to install: 'Batch', 'JobScheduler', 'MultiCluster', or 'Base-only'. If you select more than one component, make sure you separate them with commas.

Step 3.

Select the installation directory. For the host independent installation directory, enter /usr/local/lsf. For the host type dependent installation directory, enter /usr/local/lsf/HPUX. Enter the name of the LSF cluster, and the login name of the LSF administrator.

Step 4.

Review and modify the settings as needed. Choose option 1, 'List Current Settings' to review the configuration settings. If you wish to change any setting or see the help text for any setting, choose option 2, 'Change Current Settings'.

Step 5.

Choose option 3, 'Install the Software Now'. This copies all the LSF files into their final locations and creates a default set of cluster configuration files. The lsfsetup command is installed into the LSF_SERVERDIR directory. You can use lsfsetup later to maintain LSF.

Step 6.

Next lsfsetup installs the FLEXlm license key for LSF. Choose option 2, 'Install a New License ...'. Choose the appropriate option for the type of software license you are installing. For more details see 'Setting Up the License Key'.

If you are not installing LSF on additional host types, continue with the procedure in 'Additional Steps on Each LSF Server Host' (below).

Installing Each Additional Host Type

These steps must be performed on the file server host, once for each additional host type. For this example, the SunOS 4.1 version of LSF is installed next.

Step 1.

Log in to the file server host as root. Load the SunOS 4.1 version of LSF from the distribution medium or download it by FTP. Change directory into the SunOS 4.1 distribution directory.

Step 2.

Run the following command:

# cp /usr/local/lsf/mnt/HPUX/etc/lsf.conf .

Step 3.

Run ./lsfsetup and choose option 3, 'Install Another Platform'.

Step 4.

The lsfsetup command asks whether you want to base your configuration on an existing lsf.conf file. Answer yes, and enter the name of the lsf.conf file you copied from the HP-UX host.

Step 5.

Enter /usr/local/lsf/mnt/SUN41 as the directory for machine-dependent files. The other installation settings are automatically updated.

Step 6.

Choose option 3, 'Install the Software Now'. The lsfsetup command installs all the components necessary for the additional host type.

Additional Steps on Each LSF Server Host

Each server host in the LSF cluster must be configured as follows:

Step 1.

If this host is not the file server, create the /usr/local/lsf/mnt directory and mount the /usr/local/lsf/mnt directory from the file server. You must not mount this directory with the nosuid flag; some LSF programs require setuid permission. See the manual page for the mount command for more details.

Step 2.

Create the symbolic links appropriate for the host type. For example, on an HP-UX host:

# ln -s /usr/local/lsf/mnt/HPUX/{bin,etc,lib} /usr/local/lsf

Step 3.

Log in as root and run lsfsetup. Choose option 6, 'Host Setup'.

During installation, the lsfsetup command created the lsf.conf file in the LSF_SERVERDIR based on your decisions. The LSF daemons and applications use this file to find the LSF configuration files and working directories. Now lsfsetup creates a symbolic link to the lsf.conf file in LSF_ENVDIR (/etc by default).

lsfsetup also adds the LSF services to the /etc/services file if they are not defined in NIS or NIS+ and configures the system so that the LSF daemons are started when the system boots.

The LSF daemons must be run by root on every host in the cluster. When LSF is first configured, the daemons are started by hand. Under normal operation, the daemons are restarted automatically each time the host boots. The steps required to set up daemons are different under different versions of UNIX. In any case, the LSF daemons should be started after all other networking and NFS daemons.

'Setting Up a Host' shows an example host setup using lsfsetup.

Continue with 'Initial Configuration'.

The remainder of this chapter covers specific topics related to LSF installation.

Installing on AFS

LSF manages user permission for NFS, AFS, and DFS accesses, so users can use LSF no matter what type of file system their files are stored on. The choice of installation directory for LSF does not affect user access to load sharing.

Installing LSF in AFS involves running lsfsetup from the standard LSF distribution, and then installing the additional LSF AFS distribution. Before installing, you need to choose the primary LSF administrator, and decide where to store the LSF configuration and executable files:

• If the LSF configuration files are to be stored in AFS, the primary LSF administrator must be defined in AFS; in this case, root cannot be used as the primary LSF administrator.
• LSF Batch needs read/write access to the working directories under LSB_SHAREDIR, which contain the LSF Batch log files. Before running lsfsetup, you have to decide where to store your LSB_SHAREDIR:

LSB_SHAREDIR on a local file system
If you install the LSF Batch working directory in a local file system on one host, only that host can act as the LSF master. You must list this host first in the lsf.cluster.cluster file. If this host goes down, LSF Batch becomes unavailable. Batch processing resumes when the master host becomes available again. Interactive load sharing is still available while the host is down.

LSB_SHAREDIR on an NFS file system
With this setup, the master daemon can be run on the hosts that have this directory mounted.

LSB_SHAREDIR on an AFS file system
LSB_SHAREDIR should be defined in AFS only if the potential master hosts are trusted. The LSF system elects the master host in the order that the hosts appear in the lsf.cluster.cluster file. The first host is the default master. If the first host is down, the second host takes over as master, and so on. 'Installing the LSF AFS Distribution' (below) gives additional information on configuring LSF to use LSB_SHAREDIR on AFS.

• You must not define LSF_RES_ACCTDIR and LSF_LOGDIR to be in AFS as the files in this directory are always written as the root user.
• The other configuration directories are accessed read-only by the LSF daemons and thus can be defined in AFS if the ACL for these directories contain system:any_user rl.

Follow the instructions in 'Installing LSF with lsfsetup' to install the standard LSF distribution. If some of your directories are defined in AFS, you must klog as the primary LSF administrator before running lsfsetup.

After running lsfsetup, add the following line to the lsf.conf file (stored in /etc by default):

LSF_AFS_CELLNAME=cell_name

At this point, you can create @sys symbolic links so that LSF_BINDIR, LSF_LIBDIR, and LSF_SERVERDIR access the corresponding architecture directory.

The next step involves installing the additional LSF AFS distribution. This LSF AFS distribution is named depending on the LSF version and host type, for example lsf3.0_sunos4_afs.tar.Z.

Installing the LSF AFS Distribution

Step 1.

Get the additional LSF AFS tar distribution file from tape or from FTP. Uncompress the compressed tar distribution file.

Step 2.

Copy the following executables from the LSF AFS distribution directory to the LSF_SERVERDIR directory:

res sbatchd
These executables are the same as the ones in the main distribution except that they are linked with AFS libraries.

gettok puttok
gettok gets the AFS token(s) from the kernel and prints out the tokens in ASCII format to standard output. puttok reads the AFS token(s) in the format generated by gettok, from standard input and sets the token(s) into the kernel.

esub eexec
These are shell scripts invoked by LSF (see 'External Submission and Execution Executables') to support token forwarding from the submission host to the execution host, and for supporting token renewal. Sites can modify these scripts to further customize token processing (for example, using site-specific encryption software).

Step 3.

If LSB_SHAREDIR is defined in AFS, the master batch daemon, mbatchd, must be configured so that it has the AFS token to write to LSB_SHAREDIR. The mbatchd.sc wrapper script in the LSF AFS distribution directory provides two methods for renewing the AFS token for the master batch daemon.

1. Plaintext Password

This method involves storing the primary LSF administrator's plaintext AFS password in a local file on the hosts that potentially can become the master.

• Rename mbatchd in LSF_SERVERDIR to mbatchd.real.
• Edit mbatchd.sc shell script in the AFS distribution directory:
• Set LSF_ADMIN to the name of LSF primary administrator.
• Set RTYPE=1
• Set PWFILE to the absolute path of the file containing the plaintext password. This file should be accessible only by root.
• Copy mbatchd.sc to LSF_SERVERDIR as mbatchd.

2. rtok Daemon

This method involves setting up the token renewal daemon on the AFS server.

• Set up token renewal kit as described in 'AFS Token Renewal Kit'.
• Edit the mbatchd.sc shell script in the AFS distribution directory:
• Set LSF_ADMIN to the name of LSF primary administrator.
• Set RTYPE=2
• Set RTOKD_HOST to the AFS server host name running rtokd.
• Set RTOK_PORT to rtokd's port number.
• If PGP is used, follow the procedure described in 'AFS Token Encryption' to set up PGP for root on the potential master hosts, and on the AFS server host.
• Copy mbatchd.sc to LSF_SERVERDIR as mbatchd.

Step 4.

If privileged port authentication is used (for example, LSF_AUTH is not defined in your lsf.conf file when you run lsfsetup; see 'Authentication using Privileged Ports') and LSF_BINDIR is defined in AFS, you will need to change the ownership of the setuid executables in LSF_BINDIR to root. First, find all the binaries in LSF_BINDIR that are installed with the setuid bit on:

% ls -l | grep rws

Then klog to a user ID with AFS administrator privileges, and run:

% chown root setuid_binaries

Alternatively, you can simply chown all the LSF binaries under LSF_BINDIR to root if the directory contains only LSF binaries:

% chown root *

AFS Token Encryption

By default, the AFS esub and eexec scripts do not use encryption when transferring the AFS tokens between the submission and execution hosts. A site can modify these scripts to add site-specific encryption. The esub and eexec scripts in the LSF AFS distribution give an example of how to use PGP for encryption. To configure LSF to use PGP:

Step 1.

Install the PGP package on all LSF hosts.

Step 2.

Define LSF_EEXEC_USER=root in /etc/lsf.sudoers on all LSF server hosts. See 'The lsf.sudoers File' for details of the lsf.sudoers file.

Step 3.

Create the root account's PGP directory on all the LSF server hosts. This root_pgp_dir (for example, /local/etc/.pgp) should be a local directory and only be accessible by root.

Step 4.

On an LSF server host, create root's public key and private keys by running (using Bourne shell syntax):

# PGPPATH=root_pgp_dir
# export PGPPATH
# pgp -kg lsf_pgp_name

where lsf_pgp_name can be any name you choose; for example,

# PGPPATH=/local/etc/.pgp
% export PGPPATH
% pgp -kg lsf

Step 5.

Store the plain text pass phrase into $PGPPATH/.p. Make sure this file is owned by root and accessibly only by root.

Step 6.

Extract the public key to a share file so users from any LSF host can access the file on encryption:

# pgp -kx lsf_pgp_name lsf_public_key_file

For example:

# pgp -kx lsf /usr/local/lsf/conf/lsfpublic.pgp

Step 7.

Securely replicate the PGPPATH contents onto all the other LSF server hosts.

Step 8.

Edit the eexec script, and

• Re-define ROOT_PGPPATH to your root_pgp_dir directory if necessary.
• Define PGP_EXEC_PATH to point to the directory containing the pgp executable.
• Remove the line: PGPPATH=""

Step 9.

Edit the esub script, and re-define LSF_PGP_NAME to your lsf_pgp_name definition.

Step 10.

Each LSF user who wants to use PGP encryption must do the following setup:

• Set up PGP by running pgp -kg. Make sure the PGPPATH environment variable is set.
• Add lsf_pgp_name's public key to his/her public key ring by running:

% pgp -ka user_name lsf_public_key_file

For example, the user John would run,

% pgp -ka john /usr/local/lsf/conf/lsfpublic.pgp

AFS Token Renewal Kit

The AFS token renewal kit in the LSF AFS distribution assumes that root is trusted on all the LSF server hosts. Since the token renewal kit uses the esub/eexec mechanism (see 'External Submission and Execution Executables'), a site can write its own token renewal system if a higher level of security is required.

The token renewal kit consists of a client program, rtok, and a server program, rtokd. rtok is used to request the rtokd daemon running on the AFS server host to renew the token for a user. rtok/rtokd also use the eexec, esub, gettok, and puttok executables from the AFS distribution.

Setup on the AFS server host

If the AFS server host is of a host type that is not in your LSF cluster then you will need to get the LSF AFS distribution for that platform.

The assumption here is that the AFS server host is not part of the LSF cluster, and that none of the LSF binaries (in particular LSF_SERVERDIR) are accessible.

Define a directory to store the rtokd, gettok, puttok, eexec, and esub executables from the AFS distribution. If PGP is used, be sure to make the necessary modification to the esub script as described in 'AFS Token Encryption'.

Set up a client_hostsfile file containing the list of machines that are authorized to renew tokens. This file is in the same format as /etc/hosts.

As root, start the rtokd server:

# absolute_path/rtokd -l /tmp -p portno client_hostsfile &

where

-l /tmp indicates that the messages are logged to /tmp/rtokd.log.hostname. If -l is not given, the messages are printed to standard error. If -l syslog is given, the messages are logged to syslog.

-p portno indicates the port number to which the daemon will listen for client requests.

client_hostfile is the path name of the file containing the addresses/names of the hosts, which are authorized to renew tokens.

By default, rtokd reads /usr/afs/db/kaserver.DB0 for the user's DES keys. If kaserver.DB0 is in another location, the full path can be specified using the -f option.

Add rtokd to the system start-up file (for example, rc.local).

Setup on LSF Server Hosts

Copy the rtokd, gettok, esub, puttok, eexec, and rtok executables into the LSF_SERVERDIR directory as defined in your lsf.conf file.

Set the owner of rtok to root, and its permissions to 0700.

Define LSF_EEXEC_USER=root in the /etc/lsf.sudoers file. See 'The lsf.sudoers File' for details of the lsf.sudoers file.

If PGP is used, follow the instructions in 'AFS Token Encryption' on how to modify the esub and eexec scripts to support encryption.

Edit the eexec script to set RTOK_PORT to the rtokd's port number, and set RTOKD_HOST to the name of the AFS server host running rtokd.

Installing on DCE/DFS

Installing LSF in DCE/DFS involves running lsfsetup from the main LSF distribution, and then installing the additional LSF DCE distribution. Before installing, you need to choose the primary LSF administrator, and decide where to store the LSF configuration and executable files:

• If the LSF configuration files are to be stored in DFS, the primary LSF administrator must be defined in DCE; in this case, root cannot be used as the primary LSF administrator.
• The master batch daemon needs read/write access to the working directories under LSB_SHAREDIR, which contain the LSF Batch log files. Since the daemon is not authenticated to DCE, you must not define LSB_SHAREDIR to be in DFS when running lsfsetup. The other configuration files are accessed read-only by the LSF daemons and thus can be defined in DFS if the ACL for these directories contain any_other:r-----. Similarly, the LSF executables can be stored in DFS if the ACL contains any_other:r-x---.
• You must not define LSF_RES_ACCTDIR and LSF_LOGDIR to be in DFS as the files in this directory are always written by the root user ID.

Follow the instructions in 'Installing LSF with lsfsetup' to install the main LSF distribution. If some of your directories are defined in DFS, you must dce_login as the primary LSF administrator before running lsfsetup.

At this point, you can create @sys symbolic links so that LSF_BINDIR, LSF_LIBDIR, and LSF_SERVERDIR access the corresponding architecture directories.

The next step involves installing the additional LSF DCE distribution. This distribution is named depending on the LSF version and host type, for example lsf3.0_sunos4_dce.tar.Z.

Installing the LSF DCE Distribution

Step 1.

Get the LSF DCE tar distribution file from tape or from FTP. Uncompress the compressed distribution file.

Step 2.

Copy the following executables from the LSF DCE distribution directory to the LSF_SERVERDIR directory:

daemons.wrap (res sbatchd)
These executables are compiled with DCE/DFS support. After copying them to the LSF_SERVERDIR directory, rename the original files and make the following links:

# mv res res.real
# mv sbatchd sbatchd.real
# ln -s daemons.wrap res
# ln -s daemons.wrap sbatchd

getcrd putcrd
getcrd gets the DCE credentials from the credential cache and outputs the tokens to standard output. putcrd reads from the standard input the AFS token(s) in the format generated by getcrd, and sets the credentials for the invoker.

esub eexec
These are shell scripts invoked by LSF (see 'External Submission and Execution Executables') to support credential forwarding from the submission host to the execution host. Sites can modify these scripts to further customize credential processing (for example, using site-specific encryption software).

Step 3.

If privileged port authentication is used (for example, LSF_AUTH is not defined in your lsf.conf file when you run lsfsetup; see 'Authentication using Privileged Ports'), and LSF_BINDIR is defined in DFS, you will need to change the ownership of the setuid executables in LSF_BINDIR to root. First, find all the binaries in LSF_BINDIR that are installed with the setuid bit on:

% ls -l | grep rws

Then dce_login to the primary LSF administrator, and use the command cm setsetuid:

% cm setsetuid -path setuid_binaries -state on

Credential Encryption

By default, the DCE esub and eexec scripts do not use encryption when transferring the DCE credentials between the submission and execution hosts. A site can modify these scripts to add site-specific encryption. The esub and eexec scripts in the LSF DCE distribution give an example of how to use PGP for encryption. To configure LSF to use PGP, follow the instructions in 'AFS Token Encryption'.

Upgrading From a Previous Version

This section describes the procedure for installing LSF when you already have a previous version of LSF installed on your system.

The upgrade procedure replaces the installed binaries and the running daemons, and automatically updates your configuration files to support the new LSF version, if necessary.

CAUTION!
All interactive jobs running under LSF will be killed. If you are upgrading from LSF version 1, all pending and running batch jobs will be lost. Make sure that the system is completely idle before upgrading LSF.

You should do a complete backup of your LSF binaries and configuration files before upgrading LSF.

Step 1.

Copy the LSF configuration file from the previous version to the distribution directory. If you are upgrading from LSF version 1, copy the local.config file from the LSF version 1 installation directory. If you are upgrading from LSF version 2, copy the /etc/lsf.conf file created by the previous installation.

Step 2.

Log in to an LSF server host as root, and change directory to the distribution directory. Run the ./lsfsetup command.

Step 3.

Choose option 3, 'Upgrade from a previous version of LSF'. Specify one or more of the following components to install: 'Batch', 'JobScheduler', 'MultiCluster', or 'Base-only'.

Step 4.

Choose option 1, 'Upgrade From LSF 1.2a or Earlier', or option 2, 'Upgrade From a Version of LSF 2.0 or later', depending on the version of LSF from which you are upgrading.

Step 5.

Select the configuration file describing the old installation.

Step 6.

The upgrade procedure now follows the standard lsfsetup installation procedure as described in 'Installing LSF with lsfsetup'. You should review the installation settings and modify them, if necessary, before installing the software.

Perform the upgrade procedure once for each host type. The lsfsetup command automatically upgrades the necessary portions of LSF for each host type.

The following two steps are needed only if you are going to configure LSF to inter-operate with an NQS system. If you are not sure whether you need this feature, read 'Configuring NQS Interoperation' first. If you do not need to inter-operate with an NQS system, skip to step 9.

Step 7.

Copy ./etc/nqsi to LSF_SERVERDIR as defined in the lsf.conf file. Make sure the LSF_SERVERDIR/nqsi file has read and execute permission for all users. Since this executable is platform dependent, you must do this step for each platform.

Step 8.

Copy the NQS map file ./conf/configdir/lsb.nqsmaps to LSB_CONFDIR/cluster/configdir, where LSB_CONFDIR is the LSF Batch configuration root directory as defined in the lsf.conf file and cluster is the name of your LSF cluster. You need to change the file mode to make sure that this file is readable by all users and writable only by the LSF administrator.

Step 9.

Restart the LSF daemons on all hosts.

Registering LSF Service Ports

LSF uses UDP and TCP ports for communication. All hosts in the cluster must use the same port numbers so that each host can connect to the servers on other hosts. There are three alternative places to configure the port numbers for the LSF services:

• The /etc/services file.
• The services NIS (Network Information Service or Yellow Pages) or NIS+ database.
• Configuration parameters in the /etc/lsf.conf file.

To determine which is used in your system, run the command ypwhich -m services. If this command displays a host name, your network is using NIS. On Solaris 2.3 systems, run the command:

% nismatch name=login services.org_dir

If this command returns a service entry for the login service, your network is using NIS+.

The Host Setup option in the lsfsetup command tries to find out where the services should be registered. If the services database is in the /etc/services file, lsfsetup adds the LSF services to that file.

If your services database is in an NIS or NIS+ database, you must add the entries to your database by hand. Figure 3 shows the contents of the example.services file provided in the distribution directory. This file contains examples of the entries you must add to the services database.

CAUTION!
Some NIS implementations fail if the NIS source file contains blank lines, causing many system services to become unavailable. Make sure that all the lines you add either contain valid service entries or begin with a comment character '#'.

Figure 3. The example.services File

#/etc/services entries for LSF daemons. # res 3878/tcp # remote execution server lim 3879/udp # load information manager mbatchd 3881/tcp # master lsbatch daemon sbatchd 3882/tcp # slave lsbatch daemon # # Add this if ident is not already defined in your /etc/services file ident 113/tcp auth tap #identd

If any other service listed in your services database has the same port number as one of the LSF services, you can change the port number for the LSF service. You must use the same port numbers on every LSF host.

NIS Services Database

If you are running NIS, you only need to modify the services database once per NIS master. On some hosts the NIS database and commands are in the /var/yp directory; on others NIS is found in /etc/yp. Follow these steps:

Step 1.

Run the ypwhich -m services command to find the name of the NIS master host.

Step 2.

Log in to the NIS master host as root.

Step 3.

Edit the /var/yp/src/services or /etc/yp/src/services file on the NIS master host and add the contents of the example.services file.

Step 4.

Change directory to /var/yp or /etc/yp.

Step 5.

Run the command:

# ypmake services

On some hosts the master copy of the services database is stored in a different location; refer to your system documentation for more information.

On systems running NIS+ the procedure is similar; again, please refer to your system documentation.

Configuring Services in lsf.conf

If you do not want to change the /etc/services file or the NIS database, you can configure the service port numbers in the lsf.conf file (typically installed in /etc). Edit the lsf.conf file and add the following lines:

LSF_RES_PORT=3878
LSF_LIM_PORT=3879
LSB_MBD_PORT=3881
LSB_SBD_PORT=3882
LSF_ID_PORT=113

You must make sure that the same entries are added to the /etc/lsf.conf file on every host.

Registering NQS Service

You need to register NQS service only if you want LSF to inter-operate with an NQS system. To enable LSF Batch to inter-operate with remote NQS servers, you need to register the NQS services in the service database such as /etc/services or NIS. The NQS uses TCP port number 607. If you do not know how to add a service entry to the services database, read 'Registering LSF Service Ports'.

Starting LSF Servers at Boot Time

The lsfsetup Host Setup procedure normally configures each LSF server host to start the LSF daemons when the host boots. This section describes the changes lsfsetup makes to your system, and describes how to perform this setup by hand.

The LSF daemons must be run by root on every server host in the cluster. The steps required to set up daemons are different under different versions of UNIX. In any case, the LSF daemons should be started after all other networking and NFS daemons, and after the file systems containing the LSF executables and configuration files are available.

On BSD-based UNIX systems such as ULTRIX, SunOS 4.x, and ConvexOS, the start-up commands should be placed at the end of the /etc/rc.local script. lsfsetup adds the following text to the /etc/rc.local script to start the daemons:

# %LSF_START% Start LSF daemons
/usr/local/lsf/etc/lsf_daemons start
# %LSF_END%

On HP-UX 9.x, you should add the above command to the localrc function in the /etc/rc file. If your site has created a local start-up file such as /etc/rc.local, you should put the start-up command into that file instead.

On System V- and POSIX-based systems such as Digital UNIX, Solaris, SGI IRIX, and HP-UX 10.x, daemons are started and stopped by scripts in the /etc/init.d and /etc/rc*.d, or /sbin/init.d and /sbin/rc*.d, directories. lsfsetup links the LSF_SERVERDIR/lsf_daemons script file from the distribution into the appropriate place depending on the run state defined in /etc/inittab. If the /etc/init.d directory exists, lsfsetup creates symbolic links in the /etc directories; if /sbin/init.d exists, the links are created in /sbin. As an example, lsfsetup will create the following links if the run state in /etc/inittab is defined as 3:

# ln -s /usr/local/lsf/etc/lsf_daemons /etc/init.d/lsf
# ln -s /etc/init.d/lsf /etc/rc3.d/S95lsf

Note
The LSF daemons must be started on every server host in the LSF cluster. One method is shown in the section 'Remote Startup of LIM and RES'.

Licensing the Different LSF Components

LSF Suite V3.0 includes the following components: LSF Base, LSF Batch, LSF JobScheduler (formerly LSF-PJS), and LSF MultiCluster.

LSF Base is a prerequisite for all other LSF components. All components are packaged in the same distribution file. The installation program lsfsetup requires you to specify which components are to be installed. By default LSF Batch together with LSF Base are installed.

The changes to enable a particular component in a cluster is handled automatically by lsfsetup based on your input during the installation process. You can always subsequently modify the environment to reflect a new component license. See 'Parameters' for details about the lsf.cluster.cluster file.

Note
An LSF client host is independent of the components that run on the LSF server hosts. That is, there is no difference, for example, between a client for LSF Batch and LSF JobScheduler.

Each of these components are licensed independently. Individual hosts can be configured to run as LSF Batch servers or LSF JobScheduler servers within the same cluster. LSF MultiCluster is licensed on a cluster-wide basis, that is, the entire cluster is either enabled or disabled for multicluster operation.

The license file used to serve the cluster must have the corresponding features. A host will show as unlicensed if the license for the component it was configured to run is unavailable. For example, if a cluster is configured to run LSF JobScheduler on all hosts, and the license file does not contain the LSF JobScheduler feature, than the hosts will be unlicensed, even if there are licenses for LSF Base or LSF Batch.

Getting License Key Information

This section gives a detailed description of the procedure for getting a license key. You do not need to read this section unless you have difficulty getting the information needed for a license key using the lsfsetup command. If you are installing a DEMO license you do not need to read this section.

LSF uses the FLEXlm license management software from Globetrotter Software. FLEXlm supports limited time DEMO licenses and network-wide permanent licenses.

You must have a license key to run LSF. If you are installing LSF for a limited time evaluation, you should have received a DEMO key from your software vendor. If you are installing LSF for permanent use, you must get a permanent license key from your vendor. You can use a DEMO key to install LSF and get it running, and switch to the permanent license later.

Permanent licenses use a license server daemon running on one or more hosts in your network. The license server counts the number of licenses in use. For more information on how FLEXlm works and for examples of license keys, see 'LSF License Management'.

The FLEXlm license key and license server are independent of LSF clusters and LSF server hosts. You can organize your hosts into clusters any way you choose. The license server counts only the total number of hosts running LSF; these hosts can belong to any cluster in your network. As long as all your hosts can contact each other on the network, you should request a single license key that covers all the hosts on which you plan to run LSF.

If you are already running FLEXlm to support other software licenses, you can add your LSF license key to the existing FLEXlm license file. If you are not already using FLEXlm, you must choose a host or hosts to run the license server daemon.

FLEXlm normally runs the license server daemon on one host. If you are concerned about reliability, you can run the license server daemon on three or five hosts. Software licenses are available as long as a majority of the license servers are available.

You should run the license server on the host that is the NFS server for the LSF software. That way the licenses are available whenever the software is.

To create a permanent license key, your software vendor needs a hardware host identifier for each license server host. LSF comes with a script to help collect this information.

Step 1.

Change directory to the distribution directory. Run the ./lsfsetup command.

Step 2.

Choose option 4, 'License Management'. From the next menu, choose option 1, 'Get Information For a Permanent License'. If you already have FLEXlm installed, lsfsetup asks whether you want to use the same license server hosts. If you answer yes, lsfsetup uses the server host IDs from your existing FLEXlm license file. Otherwise, lsfsetup asks for a host name and tries to get the host ID for that host.

If lsfsetup is unable to get the host ID, it prompts you to run the lmhostid command on each license server host and enter the host IDs for those hosts.

lsfsetup creates a file named license.info. Follow the instructions provided in your software release notes to send the contents of the license.info file to your LSF vendor.

If you receive your license key by electronic mail or FTP, copy the file you receive into the distribution directory and name the file license.dat. If you receive your license key by paper mail or FAX, use a text editor to create a license.dat file containing your key.

'Getting License Key Information' shows an example of using lsfsetup to get license key information.

Setting Up the License Key

This section contains detailed descriptions of the procedures for setting up LSF software license keys. If you have already set up your license key, you do not need to read this section.

Before performing this step you must get a license key. If you do not have a license key, see 'Getting License Key Information'. If you plan to install a permanent license and are waiting for your permanent license key, you can install a DEMO license and switch to the permanent license later.

Both the license server daemons and the LIM on every host need to read the license key, so it must be stored in a file available on all LSF hosts. This file can be shared using NFS, or you can install a copy on each host.

If you are installing a DEMO license, follow the procedure in 'Installing a DEMO License'.

If you are installing a permanent license or switching from a DEMO license to a permanent license, and you are not running FLEXlm license server daemons for any other software licenses, follow the procedure in 'Installing a New Permanent License'.

If you are installing a new LSF permanent license and you already have license servers running for other software licenses, or if you are upgrading your LSF license, follow the procedure in 'Adding a Permanent License'.

Installing a DEMO License

If you are installing LSF with a DEMO license, you do not need to run the license server daemons. Each LSF host reads the license file directly, and LSF runs, without trying to contact the server, until the license expires.

For the DEMO license, you should install the license key in a file named license.dat in the LSF configuration directory LSF_CONFDIR, as defined in the lsf.conf file. If the configuration directory is normally shared by all hosts in the LSF cluster, you do not need to copy the license.dat file to every host.

The installation log in 'Install for the First Time' includes an example of using lsfsetup to install a DEMO license.

Step 1.

In the distribution directory, run the ./lsfsetup command.

Step 2.

Choose option 4, 'License management'. Next choose option 2, 'Install a New License From the LSF Vendor'.

Step 3.

From the next menu choose option 1, 'Set up DEMO license'.

The command looks for your vendor-supplied license key in the license.dat file in the current directory and the parent directory. If the license.dat file is not found, lsfsetup asks you to enter the full path name of the license.dat file containing your DEMO license key.

Step 4.

For the location of the installed license file, choose option 2, 'Use $LSF_CONFDIR/license.dat'.

The license manager checks your license.dat file to confirm the licensed components. It then prompts you for permission to enter appropriate features in the 'FEATURES=...' line in the lsf.cluster.cluster file.

Step 5.

You have a chance to change your mind before permanently installing the license file. Enter 'y' to commit the changes. At the next prompt, choose option q, 'Quit'. You are now done setting up the LSF DEMO software license.

The lsfsetup script installs your key in the FLEXlm license file, or creates the file if necessary. If the license file is not installed in /usr/local/flexlm/licenses/license.dat, lsfsetup updates the lsf.conf file to include the full path name of the license file.

Note
If you change the location of the installed license key file, you must make sure that the lsf.conf file is updated for all hosts in the cluster.

Installing a New Permanent License

Follow this procedure if you are installing an LSF permanent license in a network with no FLEXlm servers, switching from a DEMO license to a permanent license, or setting up a separate FLEXlm server for the LSF license. If you are adding an LSF license to a FLEXlm license key file that contains other licenses or upgrading an existing LSF permanent license, follow the procedure in 'Adding a Permanent License'.

The installation log in 'Installing a Permanent License' gives an example of using lsfsetup to install a permanent license for LSF.

The permanent license must be installed on the license server host. If you are using multiple FLEXlm servers, follow this procedure on any one of the license server hosts to set up the license key file, and then start the license server daemons by hand on the other license server hosts.

Step 1.

Log in to the license server host as root and change directory to the LSF distribution directory. Copy the license file from your vendor into the distribution directory and name the file license.dat.

Step 2.

Run the ./lsfsetup command. Choose option 4, 'License Management'. Next choose option 2, 'Install a New License'. From the next menu choose option 2, 'Set up permanent (floating) license'. The command looks for the LSF license.dat file provided by your vendor. If the license.dat file is not found in the current directory or the parent directory, the command prompts you to enter the file name.

Step 3.

Next lsfsetup asks whether you are installing a permanent license key for the first time. This procedure is for setting up a new license, so select option 1, 'First installation of a permanent license'.

Step 4.

To use the default location for the FLEXlm license key file select option 1, 'use /usr/local/flexlm/licenses/license.dat'. If you want to store your license.dat file in the LSF configuration directory, choose option 2. Otherwise, choose option 3, and enter the full path name where you want the license file to be installed.

Step 5.

If the license file already exists, you can merge the license files or replace the existing file. If your installed license file contains only LSF licenses, choose option 2, 'replace license file'. Otherwise, choose option 1, 'merge license files'.

A copy of the old license file is left in license.dat.old in the same directory as your installed license.dat file.

Step 6.

The FLEXlm license server daemons log status and error messages into a file. If you set the LSF_LOGDIR parameter in the installation procedure, the license setup puts the FLEXlm log in the file LSF_LOGDIR/license.log. Otherwise, you must enter the full path name of a log file to store the FLEXlm log messages. Put the FLEXlm log in the same directory as your other system logs, or in the /tmp directory.

Step 7.

The lsfsetup script asks if you want to start the license server daemons now. Enter 'y'. The daemons are automatically started on the host where lsfsetup is running. If you are using more than one license server host, start the license server daemons by hand on the other hosts.

To start the daemons by hand, log in as root, change directory to the distribution directory, and run the start-up script lsf_license:

# ./lsf_license start

Starting the License Server Daemons at Boot Time

You must add the lsf_license startup script to the appropriate place on the license server hosts.

For BSD-based systems, add the path of lsf_license to the end of the /etc/rc.local file.

For HP-UX 9.x systems, you may have a BSD-style /etc/rc.local file, or you may need to add lsf_license to the /etc/rc file.

For IBM AIX systems, you may have a BSD-style /etc/rc.local, or you may need to copy the lsf_license script to the LSF_SERVERDIR directory and use smit to add $LSF_SERVERDIR/lsf_license to the list of commands run at startup time.

For System V-based systems including Sun Solaris 2 and SGI IRIX, move the lsf_license file to /etc/init.d/lsf_license and add links from the /etc/rc2.d and /etc/rc1.d directories:

# cp lsf_license /etc/init.d/lsf_license
# ln /etc/init.d/lsf_license /etc/rc2.d/S90lsf_license

On Digital UNIX and HP-UX 10.x, the instructions are similar to those for System V, but the directory names are different:

# cp lsf_license /sbin/init.d/lsf_license
# ln /sbin/init.d/lsf_license /sbin/rc3.d/S90lsf_license

CAUTION!
You should ensure that the lsf_license script runs after any NFS server scripts but before the lsf_daemons script in the system boot procedure.

If you are running multiple license server hosts, configure the system startup routines to start the license server daemons on each host, and then start the daemons by hand on the backup server hosts.

Adding a Permanent License

Follow this procedure if you are adding LSF licenses to an existing FLEXlm license key file. This procedure applies if you have already configured FLEXlm to manage licenses for a different product, or if you have already installed FLEXlm to manage an LSF permanent license and you have received a new license key, for example to support a larger number of hosts.

If you are switching from a DEMO license to a permanent license, follow the instructions in 'Installing a New Permanent License'.

Step 1.

Log in to the license server host as root and change directory to the distribution directory. Copy the new license information into the file license.dat.

Step 2.

Run the command LSF_SERVERDIR/lsfsetup. Select option 4, 'License Setup', and then option 2, 'Install a New License'. If your new license information is not in the file ./license.dat or ../license.dat, enter the full path name when prompted.

Step 3.

Choose option 2, 'Set up permanent license'. At the next prompt, choose option 2, 'Upgrade an existing permanent license'.

Step 4.

Specify the location of your installed FLEXlm license key file. If your license key file is installed in /usr/local/flexlm/licenses/license.dat, choose option 1. If your license key file is LSF_CONFDIR/license.dat, choose option 2. Otherwise, choose option 3 and enter the full path name of the license file. lsfsetup adds your new license keys to the existing license file.

Step 5.

Commit the changes to the license file. lsfsetup tells the license server daemons to reread the license file, and checks to make sure your LSF license is available.

Copyright © 1994-1997 Platform Computing Corporation.
All rights reserved.