LeasePak Server

Preparation and Installation

The procedures in this document cover:

• Preparing Application hosts and DBMS hosts for the installation of LeasePak and its associated database system software.
• Organizing the information needed to successfully install LeasePak version 7.6a on the Application host.
• Execution of the LeasePak SETUP program

If there is already a LeasePak installation on the Application host, the installation procedure is as described here; if the database system is already installed on the DBMS host, it is recommended that the administrator review the preparation sections of this document to insure that all required items are in order.

Once LeasePak and the database system are installed, the administrator should consult LeasePak Server Configuration and Maintenance to complete the tasks to bring LeasePak to a usable level.

If there is an existing LeasePak installation on the same or different hosts, the document LeasePak Server Upgrade and Conversion should be consulted for the procedures for transferring the data and settings from the existing installation into the new installation of LeasePak v76a.

Table of Contents

Preparation

System Requirements

Procedure Overview

Application host Preparation

OS Verification

Groups, Users, Devices, and Filesystems

LeasePak and Queue Manager Installation Directories

LeasePak Uses Vanilla "C" locale

Temporary License file

DBMS Host Preparation

DBMS Installation Overview

SAP ASE 16.0 on Linux RHEL7

Additional Preparation

Linux Preparation Changes Required in RHEL7

Preparation Checklist

Installation

LeasePak License File

LeasePak SETUP Program

SETUP Options

• SETUP case
• Disabling db_add_srvadm
• SETUP command-line options

SETUP Questions

• Instance Name
• Server Name
• Queue Manager
• DBMS configuration
• Oracle configuration
• Sybase configuration
• Required Leasepak & DBMS roles
• Leasepakd daemon configuration
• mPowerd daemon configuration

Running SETUP: Screen Output and Annotations

• Installation start
• Clean Up Previous Install - Queue Manager
• Clean Up Previous Install - System Areas
• Clean Up Previous Install - Top Directory
• Perform the Interview
• Installation of the Queue Manager
• Installation of the Build
• Auto deployment of LeasePak on server
• Installation of the license file(s)
• Securing the LeasePak Instance
• Spooler and Temporary Directories
• The Configuration Generator cfg_gen
• Registering the Release Instance
• Creating the init and internet services
• Creating the $SRVADM user
• Creating adm_syb and/or adm_ora
• Securing the LeasePak Instance (Final)

Post-SETUP Tasks

• Obtaining the Permanent License
• Completing Queue Manager Setup
• Oracle – Complete /etc/netsol_dbms_instances

Preparation

System Requirements

The administrator should review the System Requirements before beginning the installation process to ensure that the platform meets the minimum requirements for LeasePak 7.6a.

Procedure Overview

1. This is the procedure for installing LeasePak 7.6a on an application host.
2. Make the necessary OS kernel adjustments and other OS preparations for LeasePak installation.
3. Create the required OS groups, administrative users, and server directories for database system and LeasePak installation.
4. Prepare the DBMS host using the document specific to your DBMS or database system.

   LeasePak DBMS Server

5. Copy the LeasePak license file(s) to the /tmp directory.
6. Run the LeasePak SETUP program.
7. Following installation, the administrator should consult LeasePak Server Configuration and Maintenance for post-installation tasks. If there is a previous installation of LeasePak on any server, the procedures for transferring the data into LeasePak v76a are as outlined in LeasePak Server Upgrade and Conversion.

Application host Preparation

OS Verification

Groups, Users, Devices, and Filesystems

Refer to the document User Accounts for a complete discussion of LeasePak Users, Groups, and related topics. The following tables only enumerate the accounts required for installation without much discussion, which instead may be found at the above link.

Required OS Groups

Parameter or Environment Variable – this refers to names by which some entities are referred to within the LeasePak environment, in this documentation and often by NETSOL staff and users, and in which the name of the entity is stored. Not every entity has an environment variable; in these cases this item is left blank.

Linux administrators: The primary group of all LeasePak users must be the $NSTGROUP group. By default, Red Hat will create an individual group for each user; the administrator must either turn this feature off before creating users or turn it off for each LeasePak user account created, or later change the primary group of the LeasePak users to $NSTGROUP.

The OS file /etc/group stores the names of the OS groups. In the case of secondary groups, sometimes called supplemental groups, the membership of a user in a group as a secondary group is determined by the user's name being listed after the group name in /etc/group. However, this is not so for primary groups; primary group membership is determined by placing the GID in the group field of the user's entry in the /etc/passwd file.

Required OS Users

$NSTADMIN and $NSTDBA: These are highly specialized accounts. Their environment variables should always point to the administrative environment (adm_ora or adm_syb) where SETUP initially placed them. Do not change the environment for either of these accounts manually or by using change_env or set either of them up as LeasePak users.

Because these accounts must remain as configured by SETUP, NETSOL strongly recommends that separate $NSTADMIN and $NSTDBA users be set up for each LeasePak release, and that they follow a naming convention that embeds the LeasePak release version in the user names.

Devices and Filesystems

CD-ROM Device

NETSOL recommends that the CD-ROM device be attached directly to the application host (not over a network) to avoid problems where the directory paths might undergo unexpected case translation.

If the administrator prefers, the contents of the distribution CD or of the distribution archive downloaded from NETSOL may be copied into an application host directory, and that directory then used in lieu of using an actual CD, as a virtual CD or pseudo-CD, as it were.

OS	Typical Path
Linux	/mnt/cdrom
Virtual CD: Each platform requires about 300MB of space	/shipcd mkdir /opt/shipcd ln -s /opt/shipcd /shipcd

Filesystem Sizes

The following filesystems should already exist on the Application host or on the DBMS host:

Home directory – standard part of all supported operating systems. Each LeasePak user has a directory under /home on the application host.

Parameter	Comments	Values (Path values not optional)
Path		/home
Size	Calculate from numbers and sizes of user-generated reports plus an allowance for leasepak_error.log	200 MB minimum; 4 GB normal

Temporary directories – standard parts of all supported operating systems.

Parameter	Comments	Values (Path values not optional)
Path	Used extensively by the NETSOL Utility Scripts, and by some LeasePak reports, and the Queue Manager.	/tmp
Size		1.2 GB minimum; 2 GB normal
Path	Potential extensive use by the Queue Manager on Linux, and by some LeasePak processes. Part of the /var filesystem	/var/tmp
Path	Potentially used by the Queue Manager on Linux. Part of the /var filesystem	/var/spool
Size	/var filesystem	1.2 GB minimum; 2 GB normal

Swap partition – this is part of the standard OS install. Not optional.

Parameter	Comments	Values (Path values not optional)
Size		3 times physical memory is typical; 40MB per concurrent LeasePak connection

LeasePak and Queue Manager Installation Directories

LeasePak Directory Layouts

Beginning with v76a on Linux, NETSOL consolidated some of the directory structures used to install LeasePak and its Queue Manager. Where before two directories—indeed two filesystems—were recommended, NETSOL now recommends one.

The diagram below depicts this new structure. Bold items are shell environment variable references to the various directories or directory components. Dotted lines ... and / connect each reference to the component or directory it names:

                       /
                       |
                      opt.......................$EFSDIR
                       |
                      nst.......................$NSTDIR
                       |
        +--------------+--------+------+
        |              |        |      |
        |     .........|........|......|........$QMPPATH
        |    /         |        |      |
        |   /          | .......|......|........$TOPDIR
        |  /           |/       |      |
qm_${INST_ID}76a      v76a     log    cst.......$CSTDIR
        |                              |
        | .............................|........$QMDIR
        |/                             |
     qm_3_32                     +-----+-----+
                                 |           |
                             7.60.8765   7.60.7654

The rules for the layout are:

• $NSTDIR is central. NetSol suggests naming it nst but that is optional.
• $NSTDIR's parent directory is $EFSDIR, the External File System (meaning external to LeasePak)
• $EFSDIR cannot be / (root).
• $TOPDIR's parent directory is $NSTDIR. $TOPDIR must still be the LeasePak release version, as it has always been.
• $QMPURPOSE
  • Linux:
    $QMPURPOSE is qm_${INST_ID}76a, for example qm_prod76a
    Parallel to $TOPDIR is $QMPPATH, the Queue Manager Parent Path. $QMPPATH consists of $NSTDIR/$QMPURPOSE.
• $QMRELS is used frequently in this document and in the LeasePak administration scripts, and is equal to qm_+$QM_VERSION. In v64a and above, then, $QMRELS will be qm_3_17 or qm_3_32. See LeasePak Server and Queue Manager Directories
• Finally below $QMPPATH is $QMDIR, which is $QMPPATH/$QMRELS.
• Parallel to $TOPDIR is $CSTDIR, which has a child directory for each build attached to any of the $TOPDIRs release instances under $NSTDIR.
• All of the directories below $NSTDIR must follow the Queue Manager naming restrictions: lower case alpha, digits, and underscore only are allowed. No directories with . (period) or - (hyphen) in their names are allowed.

Changes to the Queue Manager in v62a and Before: Beginning in Version 5.3a, Queue Manager self configures, leaving only the establishment of queues, printers, and print queues for the administrator.

The most immediate difference is that in the more recent releases, the SETUP program, once the Queue Manager software is installed, calls a special version of the Queue Manager Config file, which obtains parameters from the execution environment and fully parameterizes a clone of itself. There is no editing of the Config file required to set parameters such as Config:SYSTEM and Config:MAXDEV, etc.

Beginning with Version 6.2a on Linux, the Queue Manager temporary directory and the Queue Manager spool directory are site-configurable; the administrator can select between two filesystem locations for each of these directories. The choices for location of the temporary directory are /var/tmp (recommended) and /tmp. The choices for location of the spool directory are /var/spool (recommended) and $QMDIR/spool. The final component after /var/tmp, /tmp, and /var/spool is $QMPURPOSE, or qm_${INST_ID}76a.

LeasePak Server and LeasePak Queue Manager Directories

Being hierarchical, the $NSTDIR directory structures have many parent/child relationships, which complicate the documentation of the layout. The following tables attempt to explain the relationships and terminology of the directories. Six tables follow:

• Parameters and Paths – gives the parameter names for the directories and directory components as used in the NetSol Utility Scripts
• Queue Manager Versions by Platform – gives the supported Queue Manager version for each supported platform
• Standard Filesystems – gives the filesystem types to use for LeasePak for each supported platform
• Filesystem Layouts – provides guidance on how to map the $NSTDIR directory structures to several different-sized sets of filesystems
• Creating and Provisioning – provides details on how to set up the various directories, who is responsible for doing so, and whether the information needed is provided directly by the operator running the SETUP program
• Init and Internet Services – provides a summary of the services potentially installed by SETUP, their names, locations and purpose

Parameters and Paths

Parameter	Purpose	Suggested Name(s)	Notes
$EFSDIR	A file system that holds non-OS-provided software packages	/opt	Cannot be /
$NSTDIR	Holds NetSol Technologies products	$EFSDIR/nst	nst is recommended
$NSTDIR/log	Holds log files associated with LeasePak's init services	$NSTDIR/log	Used by all releases in $NSTDIR
$TOPDIR	Holds the Server instance of a LeasePak release	$NSTDIR/v76a	v76a is required
$CSTDIR	Holds the End-User Customized Code Objects	$NSTDIR/cst	cst is recommended
$QMPURPOSE	A component in names describing the Queue Manager and connecting it to a LeasePak instance	Linux: qm_${INST_ID}76a	Component value formation is fixed
$QMRELS	A component in path names for Queue Manager instances connected to LeasePak; specifically the final component of the path where the Queue Manager software and configuration is stored. Provides a clearly delineated division between different versions of the Queue Manager software	qm_$QM_VERSION	Component value formation is fixed
$QMPPATH	This is the path at which the $QMRELS (see above) is located holding the Queue Manager software	Linux: $NSTDIR/$QMPURPOSE	May be overridden by operator
$QMDIR	Holds the Queue Manager software and configuration	$QMPPATH/$QMRELS	Path formation is fixed
$SYSTMPDIR	System directory that holds temporary files for many applications	Linux: /var/tmp or /tmp	Linux: Choice between two system temporary directories
$QMTMPDIR	Directory used by the Queue Manager to hold its many temporary files	$SYSTMPDIR/$QMPURPOSE	path formation is fixed
$QMSPOOLDIR	Directory used by the Queue Manager to contain the filesystem components of the queues themselves, as well as the files that represent or contain jobs waiting for execution	Linux: /var/spool/$QMPURPOSE or $QMDIR/spool	Linux: Choice between two approaches – under the system spooler directory or traditional under $QMDIR

Supported Queue Manager Versions

About $QM_VERSION: $QM_VERSION is the supported version of the Queue Manager on the installation platform. $QMRELS is qm_ plus $QM_VERSION. The following table shows the currently supported versions of the Queue Manager software:

Platform	Queue Manager Version $QM_VERSION	Queue Manager Release $QMRELS
Linux RHEL7	3_32	qm_3_32

Standard Filesystems

In the ensuing discussions, when the term standard filesystem (or "Std FS") is used, it is intended to mean the recommended type of filesystem for each platform as set forth below:

OS	Standard Filesystem
Linux RHEL7	ext3

Filesystem Layouts

NetSol recommends that $NSTDIR be on one filesystem. If the administrator prefers to use separate filesystems, then the following table should be consulted to guide the layout of the $NSTDIR structure on different combinations of filesystems:

Number of Filesystems	Filesystem 1: Directories Min Space Req Filesystem Type	Filesystem 2: Directories Min Space Req Filesystem Type	Filesystem 3: Directories Min Space Req Filesystem Type	Filesystem 4: Directories Min Space Req Filesystem Type
1	$NSTDIR $QMDIR $TOPDIR $CSTDIR 1.8 GB Std FS
2	$NSTDIR $TOPDIR $CSTDIR 1.5 GB Std FS	$QMDIR 300 MB Std FS
2	$NSTDIR $QMDIR $CSTDIR 400 MB Std FS	$TOPDIR 1.4 GB Std FS
3	$NSTDIR $CSTDIR 100 MB Std FS	$QMDIR 300 MB Std FS	$TOPDIR 1.4GB Std FS
4	$NSTDIR 10 MB Std FS	$QMDIR 300 MB Std FS	$TOPDIR 1.4 GB Std FS	$CSTDIR 100 MB Std FS

Installing LeasePak v76a across more than 4 separate filesystems is not recommended. The administrator should not relocate arbitrary parts of $QMDIR or $TOPDIR to other filesystems without guidance from NetSol.

Creating and Provisioning

Parameter	Path	Owner:Group	Access Mode	Made By	Cfg Input
$EFSDIR	/opt	OS values	OS values	OS or admin	No
$NSTDIR	$EFSDIR/nst	root:${NSTGROUP}	0750	SETUP	No
(none)	$NSTDIR/log	root:sys	0755	SETUP	No
$TOPDIR	$NSTDIR/v76a	${NSTADMIN}:${NSTGROUP}	0755	SETUP	Yes
$CSTDIR	$NSTDIR/cst	root:${NSTGROUP}	0775	SETUP	Yes
$QMPPATH	$NSTDIR/$QMPURPOSE or $EFSDIR/$QMPURPOSE	root:sys	0777	SETUP	Yes
$QMDIR	$QMPPATH/$QMRELS	${NSTADMIN}:${NSTGROUP}	0750	SETUP	No
$SYSTMPDIR	Linux: /var/tmp or /tmp	OS values	OS values	OS	Yes
$QMTMPDIR	$SYSTMPDIR/$QMPURPOSE	root:root	0777	SETUP	No
Config:LNMDIR Config:SORTDIR Config:MBXDIR Config:TRACE	$QMTMPDIR/lnm $QMTMPDIR/sor $QMTMPDIR/mbx $QMTMPDIR/log	root:root	0777	SETUP	No
$QMSPOOLDIR	Linux: /var/spool/$QMPURPOSE or $QMDIR/spool	${NSTADMIN}:${NSTGROUP}	0777	SETUP	Yes

• Parameter – the LeasePak environment variable that contains the path
• Path – absolute pathname of the directory
• Ower:Group – the owner and group of the directory; OS value means whatever value is the norm for the OS and the site
• Access Modes – the directory's access modes; OS values means whatever value is the norm for the OS and the site
• Made By – who is responsible for creating the directory; the OS, the System Administrator, or SETUP
• Cfg Input – whether or not the path is the subject of a prompt in the Setup Interview

Internet and Init Services Installed by LeasePak

Parameter	Service Location	Service Name	SETUP Prompt	Comments
$QMINITFNAME	$INITDIR	nst_qm_${INST_ID}76a	Install Queue Mgr startup/shutdown in rc1.d/rc3.d?	Handles starting and stopping the Queues
(none)	$INITDIR	nst_dbora	Install Oracle startup/shutdown in rc1.d/rc3.d?	Handles starting and stopping the Oracle instances listed in $DBMS_INSTANCES_LIST
(none)	$INITDIR	nst_dbsyb	Install Sybase startup/shutdown in rc1.d/rc3.d?	Handles starting and stopping the Sybase dataservers and possibly the backup server
All of the above init services log their important activities to log files in the $NSTDIR/log directory.
The nst_dbora and nst_dbsyb services should be installed only on a Combined Host. Since SETUP runs on the Application host, that is where these services will be installed. If the DBMS Host is separate under a Split System, then the services will be in the wrong place.
$LPKD_SVC_ID	/etc/services	nst_lp76a${INST_ID}_$LEASEPAKD_PORT	Install LeasePak TCP port in inet configuration?	Handles dispatch of connection requests to leasepakd
$MPWD_SVC_ID	/etc/services	nst_mp76a${INST_ID}_$MPOWERD_PORT	Install mPower TCP port in inet configuration?	Handles dispatch of connection requests to mPowerd

LeasePak Uses Vanilla "C" Locale

The LeasePak server runs exclusively under the C locale. This is enforced through the LeasePak startup files. This locale is available on all supported platforms. The character set of this locale is ASCII with 8-bit extensions. Unicode, UTF8, and UTF16 are not compatible with LeasePak. See also below in the Interview, Oracle character set selection (this is discussed here because configuring LeasePak for Oracle requires providing the value of $NLS_LANG. Sybase is not discussed here as there is nothing that is obtained during the Interview in regards to this issue).

Temporary Queue Manager License file

The Queue Manager used by LeasePak has a separate license file. This file is a text file obtained through the NetSol Help Desk. When the administrator is ready to install LeasePak for the very first time on the application host, they should contact the NetSol Help Desk, who will send a temporary license via email. The administrator should copy the file onto the application host as /etc/S7.license and set its access modes to root:root 444.

If a temporary license is issued, it must be replaced before expiration with a permenant license.

Obtaining the permanent license is not possible until the Queue Manager is installed with the rest of the LeasePak release. See below Obtaining the Permanent License.

DBMS Host Preparation

DBMS Installation Overview

The LLDBs of the LeasePak environments are supported and controlled by database systems, or DBMSes. LeasePak v76a supports two database systems, Oracle and Sybase; a site can run both database systems simultaneously if the client has purchased the proper licenses from the DBMS vendor and from NetSol. Or the site can run just one database system.

The following tables document directories connected in some way to both the database system(s) and the LeasePak server. They are by no means exhaustive or complete. See the Oracle Server SAG or the Sybase Server SAG for detailed information on the installation and configuration of the respective database systems and the hosts that support them.

The software for the two database systems should be segragated in separate directories. They do not necessarily need to be on separate filesystems, though of course they can be. The location of the database system software as appropriate does not have any bearing on the location of the disk storage segments used by either system to store the contents of databases. That is a matter for the Oracle and Sybase chapters of this Guide.

If the Application Host is separate from the DBMS Host, utilizing what is called the Split System, the recommended method for setting this up is to install LeasePak v76a and the database client software on the Application host and the database server software on the DBMS host. This is because the LeasePak server software acts as a client to the database servers and so requires the client libraries and other data that are part of the database system install. Contact the NetSol Help Desk for more information on setting up the Split System.

Oracle 19c on Linux RHEL7

Oracle 19c on Linux RHEL7

About the Oracle 19c directory structure: Oracle 19c requires there to be an ORACLE_BASE directory where various Oracle products may be installed. The default LeasePak name for this directory is /opt/oracle. Products such as server or client database software are then installed in ORACLE_BASE.

Oracle provides two versions of the 19c database system on RHEL7: a 64-bit and a 32-bit product. An Oracle instance runs only on the 64-bit server product. A 32-bit application such as LeasePak requires the 32-bit client product in order to interface with the Oracle instance.

Depending on the system topology chosen (that is, a Unified System or a Split System), the two products may occur in any of the following combinations:

Oracle Locale Settings (NLS_LANG): Oracle's NLS_LANG environment variable contains locale information for the Oracle client processes. The Oracle server also has its locale information (see Oracle Server SAG). Locale information includes character set and language. If the client and server character sets do not match, then all data that passes between them (data and SQL) must be translated from one character set to the other. This is expensive and sometimes characters in one character set may have no equivalent in the other character set, leading to data corruption.

The LeasePak server supports only 7 and 8 bit character sets; in Oracle terms this means that Oracle NLS_LANG is quite limited in its possible values. In LeasePak v76a, there are only three character sets that qualify available in Oracle: WE8ISO8859P1, WE8ISO8859P15, and US7ASCII. The SETUP interview program will require the operator to select one of these character sets. This will result in NLS_LANG being set to American_America.$charset. Contact the NetSol Help Desk for assistance on locale issues outside of this scope.

SAP ASE 16.0 on Linux RHEL6

See the SAP ASE 16.0 SAG for complete details on the installation and configuration of the Sybase database system on the supported platforms.

About the SAP ASE 16.0 Directory Structure: For many releases, Sybase has used the Sybase major/minor version number in a ##_# format to name many of the directories within $SYBASE. For example, the Open Client software was found in OCS-12_5 on 12.5, in OCS-12_0 on 12.0, etc.

This was true up through at least Sybase 12.5.4. Despite Sybase's own version numbering, they have chosen to install the software in *-15_0 directories for all minor release versions of Sybase 15.

This being the case, LeasePak in v76a is behaving as if the Sybase version ($SYB_VERSION) is 15.0, so that the customary naming conventions will lead to the correct directories.

Nevertheless, the compatible version of SAP for Linux RHEL6 is SAP ASE 16.0.

Additional Preparation

Linux Preparation Changes Required in RHEL7

Kernel Parameters

Edit the /etc/sysctl.conf file on both the Application host and the DBMS host, add a definition for the kernel parameter listed below, and reboot the hosts.

There may be kernel parameter changes related to the database systems. See the Sybase Server SAG and the Oracle Server SAG for more information.

isql: MySql or Sybase?

RedHat installs the MySql database system by default, including the executable /usr/bin/isql. Being in the default PATH value before LeasePak directories are added, /usr/bin usually comes before any DBMS or LeasePak additions, so /usr/bin/isql tends to be found before the Sybase isql. This will cause errors in any LeasePak shell script using isql.

Allowing a default installation of MySql on a LeasePak host is inherently incompatible with the operation of Sybase. NetSol strongly recommmends not installing MySql on the LeasePak host. Where MySql is installed alongside Sybase, the administrator must remove, rename, or relocate /usr/bin/isql so that LeasePak shell scripts will not find the MySql version when searching for the Sybase isql.

Additions to the sudoers File

Do not directly edit the /etc/sudoers file. Instead, create a new file under /etc/sudoers.d

NETSOL-specific SUDO permissions for install:

NST ALL=NOPASSWD:/bin/chown,/bin/chgrp
User_Alias NST=test76a,dba76a

Linux Software Packages

The RedHat xinetd package must be installed on the Application host in order for leasepakd or mpowerd to properly function.

Use the RedHat yum package manager to install the xinetd package. The operator needs to log onto the Application host as root and execute:

# yum install xinetd

Preparation Checklist

The below table attempts to summarize all of the tasks that the Administrator must tend to before running SETUP to install LeasePak. This list does not and is not intended to replace careful reading and consideration of the information given in this Guide.

This table does not include some important implementation decisions that must be made prior to installation; please read the Setup Questions section carefully as well, and fill out the worksheet located there; there is some overlap between this worksheet and that one, but they are not equivalent.

Installation

LeasePak License File

Setting Up the LeasePak License File(s)

Each licensee of LeasePak receives a license file for each database system that they have purchased a license to use. The license file(s) are named:

• @@lplicense.ora – for Oracle
• @@lplicense.syb – for Sybase

Where @@ is replaced by the licensee's two-letter client code. For example, My Leasing Company might have an Oracle license named MLlicense.ora.

Normally these files are obtained from NetSol's ftp site, in coordination with the NetSol Help Desk.

It is possible for licenses to be provided on a standard double-density MS-DOS FAT12 format 3.5" diskette.

The goal of this step is to copy the license file(s) to the application host's /tmp directory and ensure that the files are named (renamed) lplicense.ora or lplicense.syb before SETUP is run.

If ftp is used at any point to obtain the license file or to copy it onto the application host, the operator must make sure that the file is transferred in Binary mode each and every time.

Transferring the license file in Text mode thoroughly corrupts the file. This will not be detected until the first time someone attempts to run a LeasePak driver with it, when it will cause the driver to abort.

LeasePak SETUP Program

Install as root: It is critical that the installation be performed by root (the system administrator).

It is equally critical that the shell session have NO LeasePak variables defined. If using the su command, the administrator must use

su -

to prevent the shell session from being contaminated.

SETUP Options

SETUP Case

Executing SETUP is case-sensitive. The program executable SETUP may occur as upper or lowercase, depending on circumstances. If installing directly from the CD, it will typically be lowercase setup. If installing from a CD copy on local disk, it will typically be uppercase SETUP.

If unsure, list the files to determine the correct case from the filename.

Disabling db_add_srvadm

What is db_add_srvadm?

db_add_srvadm is a NetSol Utility Script that is used to create or update the $SRVADM DBMS user account under each installed DBMS. This account is granted privileges sufficient to administer all LeasePak-required aspects of the database system supporting LeasePak. It was designed to provide the system administrator a user account that can handle the administrative needs of LeasePak, but without divulging the database system root user (sysdba or sa) password.

However, creating this user involves someone wielding the database system root user (sysdba or sa) password during SETUP. Also, some sites do not want the $SRVADM to be able to create user accounts nor a number of other abilities that are assigned to $SRVADM.

Therefore NetSol is providing a means by which the database system root user password is NOT prompted for, and the $SRVADM user is not created. When the administrator choses to exercise this option, they then become responsible for the creation of $SRVADM according to NetSol specifications, less any objectionable grants of privilege, and for the execution of any of $SRVADM's functions according to NetSol specifications that they have not given privilege to $SRVADM to do.

To engage this option, the administrator must use the -S option of SETUP; see SETUP Command-Line Options.

The Administrator must read the sections below describing the responsibilities that they assume by engaging this option.

The method from v62a, using NSTOPT_CREATE_SRVADM=N, is also still supported and is described below:

The interaction between using the environment variable method and the command line option method of disabling db_add_srvadm

Where the results are Y (Yes, db_add_srvadm will run) or N (No, db_add_srvadm will not run).

Choosing to not run db_add_srvadm

If the administrator chooses to not run db_add_srvadm, they must instead separately fulfill a number of requirements. These are summarized as:

• Requirements for creating $SRVADM
• Requirements for creating LeasePak Logical Databases, Logical Database Owners, and $uetc/physdb.msirc
• Requirements for creating non-administrative users
• Requirements for creating tablespaces and datafiles

Requirements for Creating the $SRVADM user

$SRVADM must be created by the DBMS administrator before SETUP is run. The requirements for $SRVADM vary by database system. See also Database Server Administrator.

SQL>  CREATE USER $SRVADM             IDENTIFIED BY $PWD_SRVADM; 
SQL>  GRANT CREATE SESSION            TO $SRVADM WITH ADMIN OPTION; 
SQL>  GRANT ALTER SESSION             TO $SRVADM WITH ADMIN OPTION; 
SQL>  GRANT CREATE USER               TO $SRVADM; 
SQL>  GRANT ALTER USER                TO $SRVADM; 
SQL>  GRANT DROP USER                 TO $SRVADM; 
SQL>  GRANT CREATE ROLE               TO $SRVADM; 
SQL>  GRANT DROP ANY ROLE             TO $SRVADM; 
SQL>  GRANT CREATE TABLE              TO $SRVADM WITH ADMIN OPTION; 
SQL>  GRANT CREATE VIEW               TO $SRVADM WITH ADMIN OPTION; 
SQL>  GRANT CREATE TRIGGER            TO $SRVADM WITH ADMIN OPTION; 
SQL>  GRANT CREATE PROCEDURE          TO $SRVADM WITH ADMIN OPTION; 
SQL>  GRANT CREATE TABLESPACE         TO $SRVADM; 
SQL>  GRANT ALTER TABLESPACE          TO $SRVADM; 
SQL>  GRANT SELECT_CATALOG_ROLE       TO $SRVADM; 
SQL>  GRANT ANALYZE ANY DICTIONARY,    ANALYZE ANY TO $SRVADM; 
SQL>  ALTER USER $SRVADM              DEFAULT ROLE SELECT_CATALOG_ROLE; 
SQL>  ALTER USER $SRVADM              DEFAULT TABLESPACE $ORA_DFLTSEG; 
						

1>  use master
2>  go
1>  exec sp_addlogin $SRVADM, $PWD_SRVADM
2>  grant role sa_role to $SRVADM
3>  grant role sso_role to $SRVADM
4>  go						
						

Requirements for creating LeasePak Logical Databases, Logical Database Owners, and $uetc/physdb.msirc

If the LLDB and its owner are created by the DBMS administrator, it should be done according to the information below, which varies according to the database system. See also Creating LeasePak Logical Databases.

Oracle Requirements for Creating LLDBs and DBOs

• The Oracle LLDB and its owner are the same entity. These are the requirements for creating the owner/LLDB:
  

  SQL>  CREATE USER $MSIDB_DBNAME        IDENTIFIED BY $PWD_MSIDB_DBNAME; 
  SQL>  CREATE ROLE msi_$MSIDB_DBNAME    NOT IDENTIFIED; 
  SQL>  CREATE ROLE msir_$MSIDB_DBNAME   NOT IDENTIFIED; 
  SQL>  GRANT CREATE SESSION             TO $MSIDB_DBNAME; 
  SQL>  GRANT CREATE TABLE               TO $MSIDB_DBNAME; 
  SQL>  GRANT CREATE VIEW                TO $MSIDB_DBNAME; 
  SQL>  GRANT CREATE TRIGGER             TO $MSIDB_DBNAME; 
  SQL>  GRANT CREATE PROCEDURE           TO $MSIDB_DBNAME; 
  SQL>  GRANT ALTER SESSION              TO $MSIDB_DBNAME; 
  SQL>  GRANT msi_$MSIDB_DBNAME          TO $MSIDB_DBNAME WITH ADMIN OPTION; 
  SQL>  GRANT msir_$MSIDB_DBNAME         TO $MSIDB_DBNAME WITH ADMIN OPTION; 
  SQL>  ALTER USER $MSIDB_DBNAME         DEFAULT ROLE msi_$MSIDB_DBNAME, msir_$MSIDB_DBNAME; 
  SQL>  ALTER USER $MSIDB_DBNAME         DEFAULT TABLESPACE $ORA_DFLTSEG 
  SQL>                                   QUOTA quota ON tablespace;						
  						

  
  where where quota is either numberM if using a common storage segment (tablespace), or UNLIMITED if using a dedicated storage segment, and tablespace is the name of the storage segment.
• The file $uetc/physdb.msirc must be updated, with ownership given to $NSTDBA, and the contents:
  setenv MSIDB_SEG01 "tablespace,quota"
  where tablespace and quota must match the values used in creating the LLDB above.

Sybase Requirements for Creating LLDBs and DBOs

• The Sybase LLDB is created as an actual Sybase database; its owner is created separately. Following are the requirements for creating the database:
  

  1>  use master 
  2>  go 
  1>  create database $MSIDB_DBNAME on datadev = datasize 
  2>       log on logdev = logsize 
  3>  go 
  1>  exec sp_dboption $MSIDB_DBNAME 'trunc log on chkpt',true 
  2>  go 
  1>  use $MSIDB_DBNAME 
  2>  go 
  1>  checkpoint 
  2>  go 
  1>  exec sp_addgroup msi 
  2>  exec sp_addgroup msir 
  3>  go  
  						

• The 'trunc log on chkpt' option is NOT valid for production LLDBs and must be replaced with an option that will allow for proper database recovery in the event of failure or error. Click here for the Critical Note pertaining to 'trunc log on chkpt'.
• The file $uetc/physdb.msirc must be updated, with ownership given to $NSTDBA, and the contents:
  setenv MSIDB_SEG01 "datadev,datasize,DATA"
  setenv MSIDB_SEG02 "logdev,logsize,LOG"
  where the devices and sizes must match the values used in creating the LLDB above.
• The Sybase database owner is created as shown below. If the $SYB_AUTODBO SETUP option is set to Y, then the database owner's name should be the same as the LLDB name ($MSIDB_DBNAME):
  

  1>  use master 
  2>  go 
  1>  exec sp_addlogin $DBO, $PWD_DBO 
  2>  exec sp_locklogin $DBO, 'lock' 
  3>  exec sp_modifylogin $DBO, defdb, master 
  4>  exec sp_locklogin $DBO, 'unlock' 
  5>  go 
  1>  use $MSIDB_DBNAME 
  2>  go 
  1>  exec sp_changedbowner $DBO 
  2>  go 						
  						

LLDB and DBO Requirements for both Oracle and Sybase

• The NetSol Utility Script db_setup_phys may be run to update the physdb.msirc file. This interactive script requires the $SRVADM account password, but does not modify the database system master tables.
• Under this arrangement, the DBMS administrator will perform the functions handled by the -b and possibly the -p options of db_create; the $NSTDBA may thereafter execute db_create -ocs. db_create will still require the $SRVADM password; this, however, is not actually used for the -o, -c, and -s options, so a dummy may be used. These three options are equivalent to using:
  db_load_obj
  db_load_code
  db_set_security

Requirements for creating non-Administrative Users

If the $SRVADM is not to create users, then the DBMS administrator will need to create all user accounts in the database system. A distinction is made between users who are to be LLDB owners and users who are not. The creation of all database system users except $SRVADM may be deferred until after SETUP has been run. See also LeasePak non-Administrative User Accounts. The NetSol Utility Script db_add_user is used by the $NSTDBA to enable a user to access a particular LLDB. See also Granting Access to LLDB to user.

SQL>  CREATE USER $DBMS_USER IDENTIFIED BY $PWD_DBMS_USER;
SQL>  GRANT CREATE SESSION   TO $DBMS_USER;
SQL>  ALTER USER $DBMS_USER  DEFAULT ROLE NONE;
SQL>  ALTER USER $DBMS_USER  DEFAULT TABLESPACE $ORA_DFLTSEG;
						

1>  use master
2>  go
1>  exec sp_addlogin $DBMS_USER, $PWD_DBMS_USER
2>  exec sp_locklogin $DBMS_USER, 'lock'
3>  exec sp_modifylogin $DBMS_USER, defdb, master
4>  exec sp_locklogin $DBMS_USER, 'unlock'
5>  go  
						

Oracle only: Requirements for tablespaces and datafiles

If the $SRVADM is not to create or alter tablespaces, then the DBMS Administrator must manage these functions. Tablespaces and their datafiles used by LeasePak must be made with the following characteristics:

To create a tablespace:

To add a datafile:

Redefining the SYSDBA account name

Sometimes there is a need to redefine the sysdba account name for Oracle. To accomplish this, the administrator would define the environment variable NSTOPT_REDEFINE_SYSDBA prior to running SETUP.

SETUP command-line options

Plain SETUP starts out with an interview, a series of questions tailored to the platform that allows the administrator to specify values for the site and hosts involved. Before running SETUP, the administrator should review the section below on SETUP Questions and have the answers prepared for the actual installation.

Only the output of SETUP -h is shown here. See the following sections for examples of installation:

# /shipcd/SETUP -h
Usage: SETUP [-bhlS] LeasePak-top-directory
options should be combined into single -... parameter;
  order is not important; duplicates are ignored.
With no options, all install sections are performed:
  Basic, Config, QM, Build, and License
Options that include 'h' display this help screen
  and then quit.
With any options 'b' or 'l' present, Basic, Config, QM, Build and License
  are all turned off; the options b/l then each turn a
  particular section on again.
Options that include 'b' turn on Build
Options that include 'l' turn on License(s)
Options that include 'S' turn off creation of SRVADM
			

SETUP Questions

How To Interact With the Setup Interview

The interview is conducted via simple Bourne-shell scripting. As such, it does not have line editing capabilities built in. Basically, when it needs a response from the operator, it suspends all other activities and waits until the operator (1) types zero or more characters and presses ENTER or (2) presses CTRL-C or some other key combination that interrupts the script, terminating the interview program, and possibly the SETUP program.

The only way to go "backwards" in the interview is to stop the interview with CTRL-C and starting SETUP over. Each time the interview is completed the input gathered is printed to the screen, allowing the operator to scroll back through the displayed responses to verify that they are as intended. Then the operator is given the opportunity to re-run the interview or to accept the input as it stands.

When each question is presented, it is printed such that the right margin is aligned in the same column throughout the interview. There is a colon and a space at the end of the question, where the operator is to type their response. Immediately before the colon is a pair of square brackets [ ], sometimes with a value in between such as [this]. This value is the default value. That is, this value represents the answer to the question that is used if the operator does not make any input of their own.

The operator cannot modify the default value, they can only accept it in its entirety, or can type a different value. Even if the operator wants to use 99% of the default value, they must type the entire input value in, or accept the default unchanged. To accept the displayed default value, the operator makes no input, not even a space, but simply presses ENTER. There is no attempt to display the accepted default in a way that looks as if it were typed in by the operator.

There are questions that have no default answers; these have either empty brackets [ ] or no brackets at all.

Some questions are multiple choice and will mention in their prompts what the choices are and what they signify. After the question, and before the default value in brackets, the possible choices are usually presented inside of parentheses in a /-separated list of values like this: (Y/N) or (AB/CD/EF). These values are never case sensitive. In other words, the response to (Y/N) may be Y, y, N, or n.

A few questions allow the operator to include the default value as part of their response, where the program will replace a plus (+) in their response with the default value. So, if the question were asked:

If the operator then types: orange grapefruit + blueberry, the results will be orange grapefruit banana blueberry as if the word banana had been typed as part of the response. This capability is accessible only when and as described in the prompts.

A few questions present default values, but also will accept a blank response as valid, as well as values typed in by the operator, and the default value if accepted by the operator. To distinguish between a blank response intended to accept the default value and a blank response intended to be blank, the operator is allowed to enter an asterisk (*) to indicate a blank response. So the prompt:

Can be responded to by:

1. Pressing ENTER (value then is love)
2. Typing in a response then pressing ENTER: friendliness (value then is friendliness)
3. Typing * then pressing ENTER (value then is blank)

This capability is accessible only when and as described in the prompts.

In the following discussion of the interview questions, the prompts that contain variable values as their defaults are presented as:

And in the discussion of the defaults, possible defaults are likewise marked with the two asterisks (**) to indicate that they may appear in the default brackets in the question.

Questions pertaining to Instance Name

(Items 1a – 1e)

Questions pertaining to Server Name

(Items 2a – 2b)

Questions pertaining to Queue Manager

(Items 3a – 3i)

Questions pertaining to DBMS configuration

(Items 4a – 4c)

Questions pertaining to Oracle configuration

(Items 5a – 5g)

Questions pertaining to Sybase configuration

(Items 6a – 6f)

The numbering of the remaining sections of the interview depend on how many DBMSs were chosen for configuration. If only one was chosen, then the following is section 6; if two were chosen, then the following is section 7.

Questions pertaining to Required Leasepak and DBMS roles

These roles are discussed in detail in User Accounts.

(Items 7a – 7d)

The numbering of the remaining sections of the interview depend on how many DBMSs were chosen for configuration. If only one was chosen, then the following is section 7; if two were chosen, then the following is section 8.

Questions pertaining to Leasepakd daemon configuration

(Items 8a – 8c)

The numbering of the remaining sections of the interview depend on how many DBMSs were chosen for configuration. If only one was chosen, then the following is section 8; if two were chosen, then the following is section 9.

Questions pertaining to mPowerd daemon configuration

(Items 9a – 9d)

Running SETUP: Screen Output and Annotations

The following is the screen output from a sample run of SETUP, broken down into sections with annotation for each section.

Sample input command to run SETUP: /shipcd/SETUP -S /opt/nst/v76a

Installation start

	2011-11-03 14:38:48 SETUP /opt/nst/v76a: SRVADM creation turned off by presence of S option
	2011-11-03 14:38:48 SETUP /opt/nst/v76a: This is a re-installation of this release in this location
		   A previous installation of LeasePak (v76a.prod) exists at this location; overwrite? (Y/N) [N]: y
	2011-11-03 14:38:57 SETUP /opt/nst/v76a: Loading setup VERSION file ...
	2011-11-03 14:38:58 SETUP /opt/nst/v76a: Setting up top dir ...
			

• SETUP begins with loading the VERSION file. This file is part of the CD image shipped by NetSol, and contains information that is universal to all LeasePak installations in v76a and information that is particular to the hardware platform for which the CD image is intended.
• Additional variables based on the location of SETUP and $TOPDIR are set.
• The registry and $TOPDIR are searched for any previous installations of v76a on the Application host.

• If there is a previous installation of LeasePak v76a in $TOPDIR, then:
  • If that previous installation has a clean-script that as already been run, then the clean-up step is skipped.
  • If that previous installation has no clean-script, then the entire $TOPDIR is deleted.
  • If that previous installation has a clean-script that has not already been run, then clean_rels is called to run the clean-script to clean-up the entire previous installation.

The following 3 sections detail the actions of the clean-up processes.

Clean Up Previous Install - Queue Manager

	2011-11-03 14:38:58 SETUP /opt/nst/v76a: Clearing /opt/nst/v76a ...
	2011-11-03 14:38:58 SETUP /opt/nst/v76a: Checking for clean_v76a_prod.txt ...
	2011-11-03 14:38:58 SETUP /opt/nst/v76a: Executing clean_v76a_prod.txt to clear /opt/nst/v76a ...
	2011-11-03 14:38:58 clean_rels: Start - cleanscript is /opt/nst/v76a/etc/clean_v76a_prod.txt, NSTDBG_EX is N
	2011-11-03 14:38:58 clean_rels: INFO SCRIPT:/opt/nst/v76a/etc/clean_v76a_prod.txt
	2011-11-03 14:38:58 clean_rels: INFO HOST:darmok DATE:2011-10-25/17:50:36 TOPDIR:/opt/nst/v76a	2011-11-03 14:38:58 clean_rels: clean_v76a_prod.txt: SVCSTOP SVC:nst_qm_prod76a WAIT:15

	Stopping v76a qm_prod76a Queue Manager ...
	Sector7 VX/DCL V3.3.2 (May 25 2011 21:06:43)
	Copyright (C) 1985-2011 Sector 7 USA Inc.
	All Rights Reserved
	Removing /var/lock/subsys/nst_qm_prod76a ...

	2011-11-03 14:39:23 clean_rels: clean_v76a_prod.txt: completed: SVCSTOP SVC:nst_qm_prod76a WAIT:15
	2011-11-03 14:39:23 clean_rels: clean_v76a_prod.txt: INITCLEAN INITF:nst_qm_prod76a	2011-11-03 14:39:23 clean_rels: clean_v76a_prod.txt: completed: INITCLEAN INITF:nst_qm_prod76a	2011-11-03 14:39:23 clean_rels: clean_v76a_prod.txt: CFGSAVE QMDIR:ATT QMCOM:start_queues.com 
		QMLIB:DEVINIT QMLIB:Config~LP
	2011-11-03 14:39:23 clean_rels: clean_v76a_prod.txt: completed: CFGSAVE QMDIR:ATT QMCOM:start_queues.com 
		QMLIB:DEVINIT QMLIB:Config~LP: ; /opt/nst/qm_prod76a/qm_3_32/ATT: saved to 
		$CFGDIR; /opt/nst/qm_prod76a/qm_3_32/com/start_queues.com: saved to $CFGDIR; 
		/opt/nst/qm_prod76a/qm_3_32/library/DEVINIT: saved to $CFGDIR; 
		/opt/nst/qm_prod76a/qm_3_32/library/Config:LP saved to $CFGDIR
	2011-11-03 14:39:23 clean_rels: clean_v76a_prod.txt: IPCCLEAN KEY:76010
	2011-11-03 14:39:23 clean_rels: clean_v76a_prod.txt: completed: IPCCLEAN KEY:76010
	2011-11-03 14:39:23 clean_rels: clean_v76a_prod.txt: QMCLEAN QMTMP:/var/tmp/qm_prod76a 
		QMSPOOL:/var/spool/qm_prod76a QMPPATH:/opt/nst/qm_prod76a	2011-11-03 14:39:23 clean_rels: clean_v76a_prod.txt: completed: QMCLEAN QMTMP:/var/tmp/qm_prod76a 
		QMSPOOL:/var/spool/qm_prod76a QMPPATH:/opt/nst/qm_prod76a			

During Queue Manager clean-up, the program:

• Stops the pertinent Queue Manager
• Removes the pertinent Queue Manager init service
• Preserves the pertinent configuration data from the Queue Manager
• Removes the pertinent Queue Manager shared memory segment
• Removes the remainder of the Queue Manager instance

Clean Up Previous Install - System Areas

	2011-11-03 14:39:23 clean_rels: clean_v76a_prod.txt: INETCLEAN LPKD:nst_lp76aprod_7601 
		MPWD:nst_mp76aprod_7607
	2011-11-03 14:39:23 clean_rels: Removing nst_lp76aprod_7601 nst_mp76aprod_7607 from (x)inetd configuration ...
	2011-11-03 14:39:23 clean_rels: Restarting (x)inetd ...
	Stopping xinetd: [  OK  ]
	Starting xinetd: [  OK  ]
	Reloading configuration: [  OK  ]
	2011-11-03 14:39:24 clean_rels: clean_v76a_prod.txt: completed: INETCLEAN LPKD:nst_lp76aprod_7601 
		MPWD:nst_mp76aprod_7607
	2011-11-03 14:39:24 clean_rels: clean_v76a_prod.txt: REGCLEAN LP:v76a ID:prod
	2011-11-03 14:39:24: reg_rels: Start: -ti /etc/netsol.conf v76a prod
	2011-11-03 14:39:24: reg_rels: End
	2011-11-03 14:39:24: reg_rels: Start: -d /etc/netsol.conf 31 
	2011-11-03 14:39:24: reg_rels: End
	2011-11-03 14:39:24 clean_rels: clean_v76a_prod.txt: completed: REGCLEAN LP:v76a ID:prod
			

During system areas clean-up, the program:

• Removes any pertinent internet services from the internet configuration
• Removes the pertinent entries from the NetSol registry

Clean Up Previous Install - Top Directory

	2011-11-03 14:39:24 clean_rels: clean_v76a_prod.txt: TOPCLEAN TOP:/opt/nst/v76a EXTENT:partial
	2011-11-03 14:39:24 clean_rels: clean_v76a_prod.txt: TOPCLEAN TOP:/opt/nst/v76a EXTENT:partial - 
		partial cleanup
	2011-11-03 14:39:24 clean_rels: clean_v76a_prod.txt: TOPCLEAN TOP:/opt/nst/v76a EXTENT:partial -
		clearing bld
	2011-11-03 14:39:25 clean_rels: clean_v76a_prod.txt: TOPCLEAN TOP:/opt/nst/v76a EXTENT:partial -
		preserving user config data
	2011-11-03 14:39:25 clean_rels: clean_v76a_prod.txt: TOPCLEAN TOP:/opt/nst/v76a EXTENT:partial -
		preserving user datasets
	2011-11-03 14:39:25 clean_rels: clean_v76a_prod.txt: TOPCLEAN TOP:/opt/nst/v76a EXTENT:partial -
		preserving user environments
	2011-11-03 14:39:25 clean_rels: clean_v76a_prod.txt: TOPCLEAN TOP:/opt/nst/v76a EXTENT:partial -
		removing adm env adm_ora
	2011-11-03 14:39:25 clean_rels: clean_v76a_prod.txt: TOPCLEAN TOP:/opt/nst/v76a EXTENT:partial -
		preserving user config data
	2011-11-03 14:39:25 clean_rels: clean_v76a_prod.txt: TOPCLEAN TOP:/opt/nst/v76a EXTENT:partial -
		clearing live
	2011-11-03 14:39:25 clean_rels: clean_v76a_prod.txt: TOPCLEAN TOP:/opt/nst/v76a EXTENT:partial -
		preserving job.log
	2011-11-03 14:39:25 clean_rels: clean_v76a_prod.txt: TOPCLEAN TOP:/opt/nst/v76a EXTENT:partial -
		preserving vertex data
	2011-11-03 14:39:25 clean_rels: clean_v76a_prod.txt: completed: TOPCLEAN TOP:/opt/nst/v76a EXTENT:partial
	2011-11-03 14:39:25 clean_rels: End cleanscript /opt/nst/v76a/etc/clean_v76a_prod.txt
			

Top directory is cleared out. Certain data is preserved from the previous LeasePak instance:

• The $TOPDIR/env directories, except for adm_*
• User data sets in $datasets
• The previous installation's relscfg.msirc
• The previous installation's vertex and boot directories
• The previous installation's job.log

Perform the Interview

    2011-11-03 14:39:25 SETUP /opt/nst/v76a: Loading in base system image ...
    2011-11-03 14:39:25 SETUP /opt/nst/v76a: Extending /shipcd/VERSION ...
    2011-11-03 14:39:25 SETUP /opt/nst/v76a: Loading Queue Manager script library ...
    2011-11-03 14:39:25 SETUP /opt/nst/v76a: Reading in extended version file ...
    2011-11-03 14:39:25 SETUP /opt/nst/v76a: Running 'Configure Release' utility ...
    
    Configure Release -- Type Ctrl-C at any time to abort operation
    
    ==> 1.  Instance Name <==
                     The previous installation of v76a in this location has been cleared
                      Keep the identifier of the previous installation (prod)? (Y/N) [Y]:  
    ==> 2.  Server Name <==
                                          Name of the LeasePak Application Host [darmok]: 
                               Path of End User Customized Code directory [/opt/nst/cst]: 
    ==> 3.  Queue Manager <==
                                                         No existing Queue Manager found
                                           Accept default Queue Manager paths? (Y/N) [Y]: 
                            Install Queue Mgr startup/shutdown in rc1.d/rc3.d? (Y/N) [Y]: 
                                             Shared memory key for Queue Mgr IPC [76010]: 
                         Number of Queue Mgr devices to configure in shared memory [150]: 
                            Number of Queue Mgr jobs to configure in shared memory [512]: 
                                  Number of simultaneous jobs to allow for per queue[10]: 
    ==> 4.  DBMS configuration <==
                           DBMS's to support in this release (O=Oracle S=Sybase OS=both): o
                         Naming convention (S=strict, L=Loose, N=New strict) (S/L/N) [S]: 
    ==> 5.  Oracle configuration <==
                                          Oracle installation base path [/opt/oracle/11]: 
                                                      Oracle server product subdirectory;
             enter "*" to indicate this is an Application Host [product/11.2.0/dbhome_1]: 
                                                      Oracle client product subdirectory;
                     enter "*" to indicate this is a DBMS Host [product/11.2.0/client_1]: 
                               Install Oracle startup/shutdown in rc1.d/rc3.d? (Y/N) [N]: 
                 Enter a plus sign (+) to include the default DARMOK in your response ...
                                                     Oracle net service name(s) [DARMOK]: 
                        Oracle default no-allocate tablespace for LeasePak users [users]: 
Select Oracle character set: (a) WE8ISO8859P1 (b) WE8ISO8859P15 (c) US7ASCII (a/b/c) [a]: 
    ==> 6.  Required Leasepak & DBMS roles <==
                                             Database server administrator name [srvadm]: 
                                                          NST Admin login name [nsadm76a]: 
                                                            NST DBA login name [nsdba76a]: 
                                                                  NST group name [users]: 
    ==> 7.  Leasepakd daemon configuration <==
                                    TCP port assignment for leasepakd inet daemon [7601]: 
                                          Max bad logins before lockout (0=disabled) [0]: 
                              Install LeasePak TCP port in inet configuration? (Y/N) [Y]: 
    ==> 8.  mPowerd daemon configuration <==
                                                        Install mPowerd daemon (Y/N) [N]: y
                                      TCP port assignment for mPowerd inet daemon [7607]: 
                                          Max bad logins before lockout (0=disabled) [0]: 
                                Install mPower TCP port in inet configuration? (Y/N) [Y]: 
    
    ==> 1.  Instance Name <==
     Release Inst Mode: SAME
           Instance Id: prod
      Instance Id Cmnt: prod test
         Top Directory: /opt/nst/v76a         NST Directory: /opt/nst
     External File Sys: /opt
                  LPID: v76a.prod
    ==> 2.  Server Name <==
          Unix OS type: Linux
           Server name: darmok
          Release path: /opt/nst/v76a      Release sequence: 760
      Custom code path: /opt/nst/cst
        Init directory: /etc/init.d
    ==> 3.  Queue Manager <==
          Install type: clean
      Accept std paths? Y
        Queue Mgr path: /opt/nst/qm_prod76a/qm_3_32
                  QMID: 3_32.prod
       Queue Mgr in Rc? Y
    Queue Mgr shmemkey: 76010
     Max Queue devices: 150
        Max Queue jobs: 512
      Queue Mgr systmp: 2
     Queue Mgr tmp dir: /var/tmp/qm_prod76a       Queue Mgr spool: 2
    QueueMgr spool dir: /var/spool/qm_prod76a     Queue Mgr purpose: qm_prod76a       Queue job limit: 10
    Queue job lim file: /opt/nst/qm_prod76a/qm_3_32/library/qjob_limit
      Calc QMgr params? N
    ==> 4.  DBMS configuration <==
         DBMS's in use: ora
          Primary DBMS: ora
     Naming convention: S
    ==> 5.  Oracle configuration <==
      Oracle major rev: 11
           Oracle base: /opt/oracle/11
          Unified host:
    Oracle srv product: product/11.2.0/dbhome_1
    Oracle clt product: product/11.2.0/client_1
           Oracle home: /opt/oracle/11/product/11.2.0/dbhome_1
        Oracle library: /opt/oracle/11/product/11.2.0/client_1/lib
    Oracle utility pth: /opt/oracle/11/product/11.2.0/dbhome_1/bin
          Oracle in Rc? N
       Oracle services: DARMOK
     Oracle service nm: DARMOK
     Oracle def tblspc: users
       Oracle NLS_LANG: American_America.WE8ISO8859P1
    ==> 6.  Required Leasepak & DBMS roles <==
     DBMS server admin: srvadm
       NST Admin login: nsadm76a         NST DBA login: nsdba76a             NST group: users
    ==> 7.  Leasepakd daemon configuration <==
        Leasepakd Port: 7601
         Lockout Count: 0
          Install Port? Y
      Port installtype: ni
       Port to replace: 
                 LPKID: 7601.prod
    ==> 8.  mPowerd daemon configuration <==
          Mpowerd Port: 7607
         Lockout Count: 0
          Install Port? Y
      Port installtype: ni
       Port to replace: 
                 MPWID: 7607.prod
    
    Configuration complete
    2011-11-03 14:41:03 SETUP /opt/nst/v76a: 'Configure Release' terminated normally
    Do you wish to [R]erun 'Configure Release' or to [C]ontinue with installation? (R/C): c
    2011-11-03 14:42:31 SETUP /opt/nst/v76a: Response=c; continuing with installation ...
			

• The basic system image (top directory tree) is laid down from CD.
• The Configure Release interview is run starting with question 1b, 1c or 1d. Refer to SETUP Questions for important information about responding to the interview. The operator is given the opportunity to re-run the interview until satisfied with the results, which are displayed after each run.

Installation of the Queue Manager

	2011-11-03 14:42:31 SETUP /opt/nst/v76a: Loading the release configuration created by 'Configure Release' ...
	2011-11-03 14:42:31 SETUP /opt/nst/v76a: Queue Manager installation type is clean
	2011-11-03 14:42:31 SETUP /opt/nst/v76a: Setting up Queue Manager dir ...
	2011-11-03 14:42:31 SETUP /opt/nst/v76a: Installing Queue Manager ...
	2011-11-03 14:42:32 SETUP /opt/nst/v76a: Attaching to Dedicated Queue Manager instance ...
	2011-11-03 14:42:32 SETUP /opt/nst/v76a: Setting up basic Queue Manager configuration; 
		Administrator must handle print and batch queue setup
	2011-11-03 14:42:32 SETUP /opt/nst/v76a: Setting Queue Manager job limit ...
	2011-11-03 14:42:32 SETUP /opt/nst/v76a: Queue Manager configuration complete
	2011-11-03 14:42:32 SETUP /opt/nst/v76a: Restoring previously preserved Queue Manager data ...
	2011-11-03 14:42:32 SETUP /opt/nst/v76a: start_queues.com restored
	2011-11-03 14:42:32 SETUP /opt/nst/v76a: DEVINIT restored
	2011-11-03 14:42:32 SETUP /opt/nst/v76a: Printer configuration from prior installation's 
		Config file preserved in /opt/nst/qm_prod76a/qm_3_32/library/PRIOR.QMLP
	2011-11-03 14:42:32 SETUP /opt/nst/v76a: Administrator must add this printer configuration to 
		/opt/nst/qm_prod76a/qm_3_32/library/Config
	2011-11-03 14:42:32 SETUP /opt/nst/v76a: Queue Manager installed
			

After the operator types C to continue following the interview, the Queue Manager installation begins in the directory designated in the interview.

• If the Queue Manager was already installed in that location, certain data is preserved; this data may have been preserved by the clean-script run earlier; if not, it is preserved now:
  • Printer and Queue definitions: start_queues.com, the printer mapping commands from Config, and DEVINIT
  • The previous installation's ATT attachment file
  • The $QMDIR directory is cleared out and the image from the CD is laid down. A new ATT attachment file is written
• The Config file is now self-customizing. The self-modifying file is run and customizes itself to create the new Config. However, the administrator must still enter the printer mapping commands.
• The queue job limit file is set up.
• The preserved data from the previous installation, if any, is restored. The preserved printer mapping commands are left in the file $QMDIR/library/PRIOR.QMLP. DEVINIT is restored, as is start_queues.com.

Installation of the Build

    2011-11-03 14:42:32 SETUP /opt/nst/v76a: Setting up Customized Software directory 
        /opt/nst/cst ...
    2011-11-03 14:42:32 SETUP /opt/nst/v76a: Installing build 7.60.3034 ...
    2011-11-03 14:42:40 SETUP /opt/nst/v76a: Build 7.60.3034 installed
    
    2011-11-03 14:42:40 SETUP /opt/nst/v76a: syb not installed; removing components ...
    2011-11-03 14:42:40 SETUP /opt/nst/v76a: Attaching build 7.60.3034 to live ...
    2011-11-03 14:42:40 SETUP /opt/nst/v76a: Build attached
			

• If this is the first installation under the given $NSTDIR, then the $CSTDIR is set up.
• The build is installed from CD. It is linked to $TOPDIR/live to become the live build. A subtree for the build is created in $CSTDIR.
• If the platform supports multiple database systems, and if the operator indicated in the interview that fewer than all are to be installed, then any others are removed from the newly-installed build. This means the $live/exe/$DBTYPE and $live/sql/$DBTYPE directories for each uninstalled database system are removed.

Auto deployment of LeasePak on server

Users can auto deploy/redeploy LeasePak on server. Following are the steps to deploy/re-deploy LeasePak on server:

1. Login Unix as a root user
2. Place the .sh and .cfg files at preferred location on server
3. Set the preferred values in .cfg file as required
4. Run .sh script

The variables/parameters defined in .cfg file have been explained in the above sections of Questions pertaining to Instance Name. Click here for sample .cfg and .sh files. This is only applicable for Oracle platform. Sybase is not supported for auto deployment of LeasePak on server.

Installation of the license file(s)

    2011-11-03 14:42:40 SETUP /opt/nst/v76a: Fetch license(s) ...
    2011-11-03 14:42:40 SETUP /opt/nst/v76a: Copying /tmp/lplicense.ora ...
    
    2011-11-03 14:42:40 SETUP /opt/nst/v76a: Install license(s) ...
			

• The license file(s) for any remaining database systems should have been copied to the /tmp directory before running SETUP. If SETUP cannot find them, it stops and prompts for the operator to get the file(s) in place. SETUP will not proceed until a license for each installed database system has been found and retrieved.
• The license file(s) are copied into $CFGDIR, and also to their respective $live/exe/${DBTYPE} directories, where each is renamed to lplicense.dat.

Securing the LeasePak Instance

    2011-11-03 14:42:40 SETUP /opt/nst/v76a: Setting file protections on v76a    2011-11-03 14:42:40 set_access: Start: /opt/nst/v76a/boot/base_sys.prot
    2011-11-03 14:42:40 set_access: End: /opt/nst/v76a/boot/base_sys.prot
    2011-11-03 14:42:40 set_access: /opt/nst/v76a/boot/base_sys.prot: 46 Item(s); 0 Error(s)
    2011-11-03 14:42:40 SETUP /opt/nst/v76a: Setting file protections on Build
    2011-11-03 14:42:40 set_access: Start: /opt/nst/v76a/live/lib/bld.prot
    2011-11-03 14:43:07 set_access: End: /opt/nst/v76a/live/lib/bld.prot
    2011-11-03 14:43:07 set_access: /opt/nst/v76a/live/lib/bld.prot: 1803 Item(s); 0 Error(s)
    2011-11-03 14:43:07 SETUP /opt/nst/v76a: Setting file protections on Queue Manager ...
    2011-11-03 14:43:07 set_access: Start: /opt/nst/qm_prod76a/qm_3_32/library/qm_3_32_rt.prot
    2011-11-03 14:43:08 set_access: End: /opt/nst/qm_prod76a/qm_3_32/library/qm_3_32_rt.prot
    2011-11-03 14:43:08 set_access: /opt/nst/qm_prod76a/qm_3_32/library/qm_3_32_rt.prot: 116 Item(s); 0 Error(s)
    
    2011-11-03 14:43:08 SETUP /opt/nst/v76a: Setting protections on /opt/nst/cst ...
			

• The set_access command is run 3 times, once each for basic system, for the build, and for the Queue Manager.
• set_access sets the owner, group and access modes of the files and directories in the list given to it.
• set_access is designed to tolerate a certain number of errors, usually 50, before aborting in error. The errors are reported to the screen, but only if they exceed the limit in quantity do these errors cause SETUP to abort.
• There should be zero errors reported. If there are a few, but not enough to cause SETUP to abort, then it is possible that the installation was still successful. However, check with the NetSol Help Desk if any errors are reported during SETUP.

Spooler and Temporary Directories

    2011-11-03 14:43:08 SETUP /opt/nst/v76a: Loading basic shell function libraries ...
    2011-11-03 14:43:08 SETUP /opt/nst/v76a: Creating Queue Manager release tmp directory ...
    2011-11-03 14:43:08 SETUP /opt/nst/v76a: Setting up bottom-most Queue Manager tmp directory ...
    2011-11-03 14:43:08 SETUP /opt/nst/v76a: Marking Queue Manager install complete ...
    2011-11-03 14:43:08 SETUP /opt/nst/v76a: Creating Queue Manager release spool directory ...
			

• SETUP creates the Queue Manager temporary directories, $QMTMPDIR/*.
• The Queue Manager spooler directory, $QMSPOOLDIR, is also created at this time.

The Configuration Generator cfg_gen

    2011-11-03 14:43:09 SETUP /opt/nst/v76a: Generating common configuration scripts ...
    Writing runtime msirc file...
        USEPKG boot vi.20
        USEPKG unix rhes5
        USEPKG ora 11g
        USEPKG dbms vi.20
        USEPKG s7 3_32
        USEPKG lprt vi.20
        USEPKG vms vi.20
        USEPKG msi vi.20
    Writing lpkd file...
        USEPKG boot vi.20
        USEPKG unix rhes5
        USEPKG ora 11g
        USEPKG dbms vi.20
        USEPKG s7 3_32
        USEPKG lprt vi.20
        USEPKG vms vi.20
        USEPKG msi vi.20
    Writing com file...
        USEPKG boot vi.20
        USEPKG unix rhes5
        USEPKG ora 11g
        USEPKG dbms vi.20
        USEPKG s7 3_32
        USEPKG lprt vi.20
        USEPKG vms vi.20
        USEPKG msi vi.20
    File generation complete; installing new config files...
    Installation of config files is complete
    2011-11-03 14:43:19 SETUP /opt/nst/v76a: Configuration generation is complete
    2011-11-03 14:43:19 SETUP /opt/nst/v76a: Loading generated settings via boot environment ...
			

• The program cfg_gen is then run. This program takes the relscfg.msirc created by the SETUP interview, the extended VERSION file now in $BOOTDIR/version.msirc, plus the templates in $live/lib/*.mtx and creates 3 files. These files define essentially the entire LeasePak release instance.
• The first file is ${HOST}_v76a_rt.msirc, and it contains setenv commands to build up the environment. When a LeasePak user logs into the Application host, this file is executed via the user's .lplogin or .lpprofile start-up file, and then that session is fully LeasePak enabled.
• The second file is ${HOST}_v76a_rt.lpkd, and it contains simple assignments that can be interpreted by leasepakd and mPowerd. When a LeasePak user logs into the Application host through the LeasePak Windows Client, this file is executed to ensure that the user environent is fully set up.
• The third file is ${HOST}_v76a_rt.com and it contains assignments to the environment in the Queue Manager DCL scripting language. It is executed at the beginning of every EOP batch job to ensure that the environment is fully configured before running the EOP driver.

Registering the Release Instance

    2011-11-03 14:43:19: reg_rels: Start: -r /etc/netsol.conf /opt/nst/v76a 
    2011-11-03 14:43:19: reg_rels: End
			

With the completion of the configuration generation, the release instance can now be registered in the /etc/netsol.conf registry. At this time, this file only associates the instance ID of the LeasePak instance with the top directory and thus also the release version of LeasePak.

Creating the init and internet services

    2011-11-03 14:43:19 SETUP /opt/nst/v76a: Performing LeasePak System installation ...
    2011-11-03 14:43:19 lp_sys_install: Start - YNNNYY
    2011-11-03 14:43:19 lp_sys_install: Install Queue Manager in rc? Y
    2011-11-03 14:43:19 lp_sys_install: Installing Queue Manager ...
    2011-11-03 14:43:19 lp_sys_install: Creating /etc/rc.d/init.d/nst_qm_prod76a ...
    2011-11-03 14:43:19 lp_sys_install: Queue Manager complete
    2011-11-03 14:43:20 lp_sys_install: Install Oracle 11g startups in rc? N
    2011-11-03 14:43:20 lp_sys_install: Install leasepakd port in xinetd configuration? Y
    2011-11-03 14:43:20 lp_sys_install: Installing leasepakd xinetd config ...
    2011-11-03 14:43:20 lp_sys_install: Installing service nst_lp76aprod_7601...
    2011-11-03 14:43:20 lp_sys_install: Deleting any existing nst_lp76aprod_7601 or leasepakd_v76a_7601 from 
        /etc/services and /etc/xinetd.d/nst_lp76aprod_7601 ...
    2011-11-03 14:43:20 lp_sys_install: Removing nst_lp76aprod_7601 leasepakd_v76a_7601 from (x)inetd configuration ...
    2011-11-03 14:43:20 lp_sys_install: Adding nst_lp76aprod_7601 to /etc/services ...
    2011-11-03 14:43:20 lp_sys_install: Adding nst_lp76aprod_7601 to /etc/xinetd.d/nst_lp76aprod_7601 ...
    2011-11-03 14:43:20 lp_sys_install: Restarting (x)inetd ...
    Stopping xinetd:                                           [  OK  ]
    Starting xinetd:                                           [  OK  ]
    Reloading configuration:                                   [  OK  ]
    2011-11-03 14:43:20 lp_sys_install: leasepakd xinetd config complete
    2011-11-03 14:43:20 lp_sys_install: Install mPowerd port in xinetd configuration? Y
    2011-11-03 14:43:20 lp_sys_install: Installing mPowerd xinetd config ...
    2011-11-03 14:43:20 lp_sys_install: Installing service nst_mp76aprod_7607...
    2011-11-03 14:43:20 lp_sys_install: Deleting any existing nst_mp76aprod_7607 or mPowerd_v76a_7607 from 
        /etc/services and /etc/xinetd.d/nst_mp76aprod_7607 ...
    2011-11-03 14:43:20 lp_sys_install: Removing nst_mp76aprod_7607 mPowerd_v76a_7607 from (x)inetd configuration ...
    2011-11-03 14:43:20 lp_sys_install: Adding nst_mp76aprod_7607 to /etc/services ...
    2011-11-03 14:43:20 lp_sys_install: Adding nst_mp76aprod_7607 to /etc/xinetd.d/nst_mp76aprod_7607 ...
    2011-11-03 14:43:20 lp_sys_install: Restarting (x)inetd ...
    Stopping xinetd:                                           [  OK  ]
    Starting xinetd:                                           [  OK  ]
    Reloading configuration:                                   [  OK  ]
    2011-11-03 14:43:20 lp_sys_install: mPowerd xinetd config complete
    2011-11-03 14:43:20 lp_sys_install: End
			

Next the program lp_sys_install is run. It is in charge of setting up the services requested by the operator via the interview. lp_sys_install does not start any of the init services; it only installs them.

• It sets up the Queue Manager init service, nst_qm_${INST_ID}76a, if requested.
• It sets up the Sybase init service, nst_dbsyb, if requested.
• It sets up the Oracle init service, nst_dbora, if requested.
• It sets up the leasepakd internet service nst_lp76a${INST_ID}_$LEASEPAKD_PORT on the $LEASEPAKD_PORT port, if requested.
• It sets up the mpowerd internet service nst_mp76a${INST_ID}_$MPOWERD_PORT on the $MPOWERD_PORT port, if requested.

Creating the $SRVADM user

Because SETUP was called with -S, $SRVADM was not recreated in this example.

• If db_add_srvadm has not been disabled (see Disabling db_add_srvadm), then for each installed database system:
  • Oracle – deletes any existing $SRVADM, recreates
  • Sybase – creates $SRVADM if it does not exist
• Note that in this example, the creation of $SRVADM was disabled by using the -S option of SETUP.

Failed Login/Bad Password Message for Oracle srvadm: If SETUP created the $SRVADM account successfully, yet attempts to use the account receive failed login/bad password messages, the administrator should check for the following Oracle initialization parameter:

Creating adm_syb and/or adm_ora

    2011-11-03 14:43:20 SETUP /opt/nst/v76a: Locating nsadm76a and nsdba76a home directories ...
    2011-11-03 14:43:20 SETUP /opt/nst/v76a: Performing DBMS-specific setup tasks ...
    2011-11-03 14:43:20 SETUP /opt/nst/v76a: Creating admin environment for ora DBMS ...
    2011-11-03 14:43:20 setup_new_env: -tnfc TEST adm_ora ora DARMOK non_admora_76a live; Start
    2011-11-03 14:43:20 setup_new_env: Creating environment directory structure...
    2011-11-03 14:43:20 setup_new_env: Creating logdb.*...
    2011-11-03 14:43:21 setup_new_env: Creating envdb.msirc...
    2011-11-03 14:43:21 setup_new_env: Creating msidba placeholder ...
    2011-11-03 14:43:21 setup_new_env: Creating .lp*...
    2011-11-03 14:43:21 setup_new_env: Setting environment security...
    2011-11-03 14:43:21 setup_new_env: End
			

• Finds home directories of $NSTADMIN and $NSTDBA
• For each installed database system:
  • Creates adm_${DBTYPE} administrative environment
  • If primary database system, copies .lp* from the newly created environment to the $NSTADMIN and $NSTDBA home directories

Securing the LeasePak Instance (Final)

    2011-11-03 14:43:21 SETUP /opt/nst/v76a: Setting file protections on bootstrap files ...
    2011-11-03 14:43:21 set_boot_prot: Start
    2011-11-03 14:43:21 set_boot_prot: Setting protections on miscellaneous boot files ...
    2011-11-03 14:43:21 set_boot_prot: End
    2011-11-03 14:43:21 build_clean_script: Cleanscript for v76a.prod written to /opt/nst/v76a/etc
    2011-11-03 14:43:21 SETUP /opt/nst/v76a: setup is finished
    #               
			

• Performs final owner/group/access mode changes
• Builds clean-script to clean up this LeasePak instance at some point in the future

Post-SETUP Tasks

Obtaining the Permanent License

Once LeasePak is installed, the administrator should log onto the application host as $NSTADMIN, and execute:

This produces output similar to the example below. This output should be emailed to the NetSol Help Desk, who will shortly email back the permanent license. The permenent license file should then replace the temporary license (see Temporary License File) in /etc/S7.license.

%  gid
       
  VX/RT     00 01 53 48 46 21  00 00 0000 0  
  VX/BASRT  00 01 53 48 46 21  00 00 0000 0  
  VX/SMG    00 01 53 48 46 21  00 00 0000 0  
  VX/DCL    00 01 53 48 46 21  00 00 0000 0  
  VX/BASIC  00 01 53 48 46 21  00 00 0000 0  
  VX/RMS    00 01 53 48 46 21  00 00 0000 0  
  VX/JSP    00 01 53 48 46 21  00 00 0000 0  
  VX/SOR    00 01 53 48 46 21  00 00 0000 0  
  VX/FMS    00 01 53 48 46 21  00 00 0000 0  
  VX/FLT    00 01 53 48 46 21  00 00 0000 0  
  VX/DATAX  00 01 53 48 46 21  00 00 0000 0  
  VX/VTWIN  00 01 53 48 46 21  00 00 0000 0  
  VX/FPP    00 01 53 48 46 21  00 00 0000 0  
  VX/QSORT  00 01 53 48 46 21  00 00 0000 0  
  
  B2/RMS    00 01 53 48 46 21  00 00 0000 0  
  B2/RT     00 01 53 48 46 21  00 00 0000 0  
  BP/RT     00 01 53 48 46 21  00 00 0000 0  
  B2/DATAX  00 01 53 48 46 21  00 00 0000 0  
  B2/QSORT  00 01 53 48 46 21  00 00 0000 0  
  
  BTRAN/BP  00 01 53 48 46 21  00 00 0000 0  
  B2/BTRAN  00 01 53 48 46 21  00 00 0000 0  
  BTRAN/QB  00 01 53 48 46 21  00 00 0000 0  
  BTRAN/CB  00 01 53 48 46 21  00 00 0000 0  
  
  QB/RT     00 01 53 48 46 21  00 00 0000 0  
  CB/RT     00 01 53 48 46 21  00 00 0000 0 
			

Completing Queue Manager Setup

After running SETUP, the administrator must complete the Queue Manager setup by defining site batch queues, printers and print queues, and associated devices. See Queue Manager.

Oracle – Complete /etc/netsol_dbms_instances

After running SETUP to install LeasePak/Oracle, if the administrator chose to have the Oracle init service nst_dbora installed, the file /etc/netsol_dbms_instances may need to be maintained.

/etc/netsol_dbms_instances contains an assignment to the variable ORA_INSTANCES. The value assigned to ORA_INSTANCES should be a quoted, space-separated list of the names of Oracle instances to be started or stopped on the Combined Host when the run level changes. These values are used by the service nst_dbora to help manage these instances.