Autoinstall.sh utility script redp4296

Redpaper

Autoinstall.sh Utility Script

This IBM® Redpaper explains the functions of the autoinstall.sh utility script, its requirements, operation, implementation, and procedures, to facilitate UNIX® FTA fixpack installations that are initiated from the Tivoli® Workload Scheduler master workstation. We provide two scenarios along with discussions about the various menus and options.

� Initial first time execution� Subsequent executions� Utility menus

Utility overview

The autoinstall.sh utility script is designed to run from the Tivoli Workload Scheduler Version 8.2.0, or greater, master workstation to install fixpacks on UNIX FTA (fault-tolerant agent) workstations with the following UNIX operating systems:

� AIX®� HPUX� Linux_i386� Solaris™

The autoinstall.sh utility script, in conjunction with Tivoli Workload Scheduler (UNIX 8.2.0 or greater), reduces the amount of operations and hours required to

Pete SotoVasfi Gucer

© Copyright IBM Corp. 2007. All rights reserved. ibm.com/redbooks 1

http://www.redbooks.ibm.com/


maintain FTA workstations that are current on maintenance fixpacks. This is accomplished by automating and monitoring UNIX FTA fixpack installations from a central location.

The script uses existing UNIX tools, “ssh” and “scp”, to perform tasks between UNIX master and UNIX FTA workstations. The ssh protocol is used to provide a secure protocol between the master and FTA. SSH certificates may be created to eliminate the need to provide a password when connecting to a remote system. Refer to “Configuring OPENSSH” on page 77 for more details. Some operating systems may require that these tools be configured or installed, if they were not part of the initial operating system installation. Please consult with your UNIX administrator for configuration or installation assistance.

The script is designed to work on AIX, HPUX, Linux_i386 and Solaris platforms. It must reside on the UNIX master and may only patch UNIX FTA workstations. The script must be run as “root” user, because the Tivoli Workload Scheduler fixpack installations require that “root” user execute the patch installation.

Although written for Tivoli Workload Scheduler fixpack installation, the script may be customized to schedule and install or patch any application that has a UNIX command line installation option. Note: Any customizing is the responsibility of the user and will not be supported by Tivoli Level 2 support.

The script may be placed in any directory. It will create temporary files in the /tmp directory. Any created temporary files will have an extension .#####, where ##### is the process ID for the script when executed. The temporary files will be removed when exiting the script normally.

Features

The following are the features of autoinstall.sh utility:

� The script runs on the server, and:

– Gathers and stores client installation information for patch installations or new product installations.

– Transfers installation scripts from the server to the client.

– Can be customized by the user to patch or install any product with a command line interface.

Note: Lowercase should be used for all inputs, except for passwords, because they are case sensitive.

2 Autoinstall.sh Utility Script

� Uses Tivoli Workload Scheduler to:

– Schedule, launch and monitor the Tivoli Workload Scheduler patch installation or a new installation of any product with a command line interface from a central location.

Requirements

Here are the requirements of the solution.

System requirements

The autoinstall.sh utility script is designed to run from the Tivoli Workload Scheduler Version 8.2, or greater, master workstation on the following UNIX platforms and may only install fixpacks on UNIX FTA workstations.

� AIX� HPUX� Linux_i386� Solaris

The .profile for the twsuser must have the TWSHome and TWSHome/bin directory in PATH variable for the master and FTA.

You should be able to invoke Tivoli Workload Scheduler commands without having to specify the path. The FTA must be able to issue ssh and scp commands.

The ssh protocol is used to provide a secure protocol between the master and FTA. Some operating systems may require that these tools be configured or installed, if they were not part of the initial operating system install.

Please consult with your UNIX administrator for ssh and ssl configuration or installation assistance.

Autoinstall.sh script information and requirements

The autoinstall.sh script must run on a AIX, HPUX, Linux_i386 or Solaris master to patch AIX, HPUX, Linux_i386 or Solaris FTA workstations. The script may be run by multiple users to create or update files. Temporary files will be generated in the /tmp directory each time the script is run and will be removed when exiting normally from the script.

Autoinstall.sh Utility Script 3

A master domain manager (MDM) definition directory will be created when the script is executed using information from the Tivoli Workload Scheduler master user. This directory will be used to store information for applying fixpacks on FTA workstations that it manages.

The /etc/TWS/APPL.tws directory, which will be the repository for utility scripts, will be created on the master the first time the script is run. The utility scripts for the FTA workstations will exist locally on the FTA in the /etc/TWS directory. The utility script can be used to copy (via scp) the utility scripts from the master to the FTA. The Tivoli Workload Scheduler utility scripts, patch_install.sh, and patch must be placed in the /etc/TWS/APPL.tws directory for the master workstation.

The Tivoli Workload Scheduler fixpack installation scripts, patch_install.sh and patch_lau.sh, must be copied from the repository on the master (/etc/TWS/APPS.tws directory) to the /etc/TWS directory on FTA and should be executable by the Tivoli Workload Scheduler user, specified during the initial FTA Tivoli Workload Scheduler installation. If the master and FTA workstation exist on same node then the utility scripts must exist in both directories.

Other applications directories, /etc/TWS/APPL.xxxx, may be created with the autoinstall.sh script to serve as a utility repository for other application scripts but the autoinstall.sh script must be customized by the user. The directory for these must be APPL.name where name is the name of the application in lowercase. Customizing will be the user’s responsibility and will not be supported by Tivoli Workload Scheduler level 2 support. Contact IBM Services for assistance with customizing.

The autoinstall.sh script requires basic FTA information that is stored for future fixpack installations. The script extracts the node/ip, Tivoli Workload Scheduler version and operating system for FTA, provided FTA exists, in the current Symphony file and is linked. The user will need to provide the Tivoli Workload Scheduler user, specified at FTA installation and base path directory for fixpack repository. The FTA specific base path should include the Tivoli Workload Scheduler version and operating system in the path to facilitate user fixpack maintenance. Ideally the fixpack path should be an NFS mounted file system which is mounted on all FTA workstations using the following naming convention.

The fixpack directory should have a common base path followed by TWSversion/OS (/patchesbasepath/twsversion/os). Refer to Example 1.

Attention: There is a known issue with the autoinstall.sh when it is run on Liniux_i386. The carriage return, which is not visible in AIX, HPUX and Solaris, appear as “/c” on Linux_i386 when running the autoinstall.sh script. The script functionality is not affected.


Example 1 Fixpack base naming convention

Example: Base path directory for AIX FTA currently on TWS 8.3/images/patches/8.3.0/aix

Where:patchesbasepath = /images/patchestwsverison = is 8.3.0 (use 3 digit format)os = aix (aix, hpux,linux_i386 or solaris)

The FTA workstation information will be written to FTA.ftaname file, where FTA text is in uppercase and ftaname is the FTA workstation name in lowercase, as shown in Example 2.

Example 2 FTA.workstation file

Example: Information on FTA Borg will exist in a file called:FTA.borg

The FTA file will exist in a sub-directory of its workstation master. The name of the directory is /etc/TWS/MDM.masteruser.mastername, where text MDM is in uppercase, masteruser is the Tivoli Workload Scheduler user for the master and the mastername is the workstation name of the master (lowercase). Refer to Example 3.

Example 3 MDM.masteruser.mastername definition directory

Example: TWS user m821 for master workstation Data will have the following directory for FTA’s that it manages:MDM.m821.data

The autoinstall.sh script will request specific patch information when patching an FTA. The patches must be in a sub directory named fp##. Refer to Example 4.

Example 4 Fixpack directory convention

The patches must be in a sub directory named fp##, where fp is in lowercase and ## is the two digit patch number for fixpack (fp01, fp02, fp10, fp11 etc...).

Example: The following path must exist for patching a TWS 8.3 AIX FTA with fixpack FP01./images/patches/8.3.0/aix/fp01

The autoinstall.sh script will verify that untarred fixpack files exist in the fp## sub directory. If only the fixpack tar file exists, it will suggest that it be untarred prior to


running the autoinstall script. It will also verify that the Tivoli Workload Scheduler version and patch level, specified in the menu, match the Tivoli Workload Scheduler version and patch level of the fixpack files.

Patching will only be permitted if the specified fixpack is the same level or greater than the current fixpack level on the FTA workstation. After the information has been gathered and verified, a job definition will be created and added to the patch_job_def file in the /etc/TWS/MDM.masteruser.mastername directory. The job created will be unique to the FTA, because it will be for a specific fixpack.

Concurrent autoinstall.sh scripts can be executed to add to the patch_job_def file. Duplicate job definitions in the patch_job_def file will be ignored when the job stream is created.

The autoinstall.sh script will create the patch_lau_sch_def and patch_succ_sch_def files in the /etc/TWS/MDM.masteruser.mastername directory. These files will contain the definitions for the TWSPATCH_LAUNCH and TWSPATCH_SUCC job streams. These definitions will run on the master once added to the Tivoli Workload Scheduler database.

Unique job definitions created by the autoinstall.sh that exist in patch_job_def file in the /etc/TWS/MDM.masteruser.mastername directory will be added to the TWSPATCH_LAUNCH job stream. Multiple job definitions with the exact same name that exist in the patch_job_def file will exist only once in the TWSPATCH_LAUNCH job stream.

The creation of the job stream operation may be run several times, because it will overwrite the previous job stream files. The autoinstall.sh script will be used to add the completed job and job stream definition files to the Tivoli Workload Scheduler database.

After adding the job and job stream definitions files to Tivoli Workload Scheduler database, remove the patch_job_def file in the /etc/TWS/MDM.masteruser.mastername directory. This file may be removed using the autoinstall.sh script.

Note: Because each fixpack includes all fixes for previous fixpacks, entering multiple fixpacks for the same FTA workstation is not required.

Caution: Adding the job stream definitions to the Tivoli Workload Scheduler database will replace the existing job stream definition for TWSPATCH_LAUNCH and TWSPATCH_SUCC.


The TWSPATCH_SUCC job stream will not have defined jobs, but will contain ad-hoc submitted jobs from FTA workstations when FTA fixpack jobs have completed successfully. The ad-hoc job will be submitted from the FTA when the fixpack installation completes successfully. Example 5 shows the naming convention for the job name of a successful fixpack installation.

Example 5 TWSPACTH_SUCC jobs

ftaname_twsver_FP_xx_jobnum_SUCC where:ftaname is the FTA workstation patchedtwsver is the TWS versionxx is fixpack number (2 digit format)jobnum is the job number of FTA fixpack install jobExample: Fixpack install job for TWS version 8.2 Fixpack 10, job number 5767 installed on FTA M82A successfully will have the this jobname in the TWSPATCH_SUCC job stream on master workstation:M82A_820_FP_10_5767_SUCC

The provided scripts use variables for specific information. The debug option is the only customizable option in the autoinstall.sh script. DO NOT edit or modify any variables.

Changes to the variables will cause script and installation problems and will not be supported by Tivoli Workload Scheduler Level 2 support. The patch_install.sh script executes the patch_lau.sh script after verifying that the information provided by the job is valid. The patch_lau.sh will inherit the values for variables that were defined in the patch_install.sh script.

The patch_install.sh script executes patch_lau.sh, which initiates the fixpack install. This script, which requires four options: -uname, -patchdir, -version and –patch, makes up the job definition created by the autoinstall.sh script. We recommend that autoinstall.sh script is used to create and add the job and job stream definitions.

The patch_lau.sh script will create the ftaname_fp_fp##_jobnum.stdlog file in the /tmp directory. This will log procedures prior to executing the twspatch install. Once the twspatch installation launches, the fixpack installation will write to the log specified the fixpack readme file.

Attention: The fixpack job definitions should be removed from the Tivoli Workload Scheduler jobs database after the fixpack job has installed the fixpack. This is suggested to limit the number of jobs that will no longer be used, because the fixpack jobs are unique to the FTA and fixpack.


Tivoli Workload Scheduler requirements

The autoinstall.sh script must be run from Tivoli Workload Scheduler 8.2.0, or greater, UNIX master. The script may be placed in any directory. It will create temporary files in the /tmp directory. Any created temporary files will have a extension .#####, where ##### is the process ID for script when executed. The temporary files will be removed when exiting the script normally.

The TWSRegistry.dat file must be correct and up to date, because the script extracts Tivoli Workload Scheduler FTA instance information, including fixpacks currently installed, from the file.

Root user on the master must have access to Tivoli Workload Scheduler files and databases and must exist in the Tivoli Workload Scheduler Security file, because fixpack installations must be run as root. The root user on FTA must be able to submit ad-hoc jobs that logon as the root user on the master.

The master must have a current Symphony file and be linked to FTA workstations that will be patched, because information will be extracted when the script is executed. The script uses the cpuinfo command to validate master and FTA workstations.

The “thiscpu=” field in TWSHome/localopts and the “master=” field in TWSHome/mozart/globalopts file must be valid and correct on both master and FTA workstations, or Tivoli Workload Scheduler user validation issues may occur when the script is run.

The autoinstall.sh script is used to add the job and job stream definitions to the Tivoli Workload Scheduler database. The definitions should be reviewed prior to adding them to the database.

Duplicate job definitions will not be included in the job stream but will be added to the jobs database. If duplicate job definitions exist, the last one added to the jobs database will be used.

Multiple fixpack installation jobs that install different fixpacks on the same FTA workstation should be avoided, because installing the latest fixpack includes all previous fixes. The script does not prevent this action.

Patching procedures

The autoinstall.sh script may be used to provide information for a fixpack install or create FTA.workstation definitions files for future fixpack installs.


Creating FTA.workstation definition files for future fixpack installations will speed up the process when applying a fixpack to an FTA. This option is useful if the master manages a large number of FTA workstations and is part of the utilities menu options.

To perform either of these options requires the creation of specific files or directories which is accomplished by the initial execution of the autoinstall.sh script.

This section discusses the first time execution and subsequent patching procedures using the patch option of the autoinstall.sh script.

Patching procedures - First time execution

The initial execution of the autoinstall.sh script will create files and directories with FTA specific information that will be used in future executions of the autoinstall.sh script. Certain tasks must be performed before executing the script.

1. Create patch repository for each FTA (refer to Autoinstall.sh Script Information and Requirements section). This is necessary, because this information will be requested when creating a FTA.workstation definition file (discussed later).

2. Verify that the localopts and globalopts on FTA and Master are correct. Incorrect information will cause problems in extracting or validating information.

3. Verify that the .profile for FTA TWSuser includes the TWSHome and TWSHome/bin directory in the PATH variable. The script issues remote Tivoli Workload Scheduler commands from the master to the FTA workstation, and errors might occur if the TWSuser .profile does not include the Tivoli Workload Scheduler path in the PATH variable.

4. Verify that all FTA workstations that will be patched are linked, active and have current Symphony file. FTA information is gathered from the Symphony file, this requires that the master be linked to the FTA workstation. The script may not be able to extract or validate information if they are not linked and have a current Symphony file.

5. Logon to the master workstation as root user. This is required, because gathering information and applying the fixpack must be executed as the root user.

6. Execute the autoinstall.sh script as the root user. The script will display message about location of temporary files and their extension, information about the master workstation, current master instance(s) that exist and ask that a master user name be provided to create the MDM definition directory for FTA workstations that it will manage. Refer to Figure 1.


Figure 1 MDM definition directory

7. Provide the Tivoli Workload Scheduler user for the MDM that will be used to manage FTA workstations that will be patched.

The script will determine if the provided user is valid and display information about the provided user.

Current system OS is HPUX

The current process id is 18671, Temporary created files willbe created in the /tmp directory and have a .18671 extension.

No existing MDM definition file existsYou will need to create a mdm definition file. This is a list of defined MDM users in the TWSRegistry.dat filefor this workstation. m821am83rtm Enter TWS User for master cpu or press enter to obtain a list ofMDM users listed in the TWSRegistry.dat file ->


Figure 2 Create TWS MDM and application definition directories

The application will create the directory MDM.masteruser.mastername which will serve as the repository for FTA.workstationname files that contain specific FTA information. It will also create the APPL.tws directory, if it does not exist. The APPL.tws directory will serve as the repository for utility scripts that will be sent to FTA workstations.

Enter TWS User for master cpu or press enter to obtain a list ofMDM users listed in the TWSRegistry.dat file -> m821a

Agent type for user m821a is MDM. m821a is a valid TWS user for a master cpu.

TWSPATH for m821a user is:/tws/m821a TWS Master workstation m821a for TWS master user m821aon this workstation will be used to schedule installs. Will create MDM definition file for TWS user -> m821a on TWS master workstation -> m821a. /etc/TWS/MDM.m821a.m821a

No existing APPL definition file existsWill need to create a APPL definition file. Will create the tws APPL definition directory /etc/TWS/APPL.tws Application tws will be used.

The current process id is 18671, Temporary created files willbe created in the /tmp directory and have a .18671 extension. Main Menu To patch a workstation enter (p). To access FTA or job and job stream utilities enter (u). To exit utility enter (e). Enter p, u or e ->


8. Reply to the prompt that asks the type of task to perform. Enter p to proceed to patch installation tasks. Refer to Figure 3.

The following prompt, as shown in Figure 3, will appear asking you to provide a valid FTA to patch. Pressing <Enter> will list all workstations that exist in the Symphony file. Only UNIX FTA workstations may be patched.

Figure 3 FTA patch installation prompt

Pressing <Enter> will display all workstations that exist on the current master. Refer to Figure 4.

Figure 4 FTA Listing

9. Provide an FTA to patch. The script will determine if workstation is a UNIX FTA, and then gather some basic FTA workstation information from the Symphony file and display as shown in Figure 5.

Enter p, u or e -> p

Enter a valid FTA workstation name to patch. Press enterto display a list of valid workstations in current Symphony fileon master cpu. ->

Note: Only UNIX FTA workstations may be patched.

Enter a valid FTA workstation name to patch. Press enterto display a list of valid workstations in current Symphony fileon master cpu. -> <enter>

Below is a list of valid FTA’s for m821a master user:

M821A M821A AF T 38211 taosHORBLM82 HORBLM82 A AT 31822 testmasterM82A M82A AFAT 31822 taosXA-FUEGO M82A A AT 31822 fuego.tivlab.austin.ibm.com

Enter a valid FTA workstation name to patch. Press enterto display a list of valid workstations in current Symphony file on master cpu. ->


Figure 5 Extracted FTA workstation information

10.Provide the TWSuser specified when the FTA was installed. The application will attempt to verify the specified user. If an SSH certificate file does not exist between the master and FTA, the user will be prompted for root password for the FTA workstation. Refer to Figure 6.

Figure 6 Validate TWS FTA user

If <Enter> is depressed, it will ask if you want to extract list of users on node/ip for FTA. Replying “y” will then prompt for root password for the node/ip of FTA. Refer to Figure 7.

Enter a valid FTA workstation name to patch. Press enterto display a list of valid workstations in current Symphony fileon master cpu. -> m82a

Input value is M82A TWS workstation M82A on node/ip taosis a UNIX FT-AGENT ie.. an FTA.

TWS workstation M82A on node taos is valid,will patch. Will determine if basic information for FTA m82a onmaster m821a exists. Will need to create information file for m82a:/etc/TWS/MDM.m821a.m821a/FTA.m82asince the above file does not exist. Additional information is required for TWS workstation m82a. Enter the TWS user for workstation m82a (node/ip taos) orpress enter to obtain list of TWS users on node/ip taos. ->

Will try to validate TWS user m82a and that it manages TWS workstation m82a.

You may need to provide root password for node/ip taos more than once.

Password:


Figure 7 Prompt to extract Tivoli Workload Scheduler users for FTA workstation

Replying “y” to “extract list of TWS users” will then prompt for the password for the FTA workstation.

A list of Tivoli Workload Scheduler users for instances on FTA will be displayed. Refer to Figure 8.

Figure 8 Extracted list of TWS users for FTA workstation

Provide TWSuser specified when the FTA was installed. The application will attempt to verify the specified user. If a SSH certificate file does not exist

Enter the TWS user for workstation m82a (node/ip taos) orpress enter to obtain list of TWS users on node/ip taos. -> <enter>

Do you want to extract list of TWS users on node/ip taos?(Enter y or n) ->

Do you want to extract list of TWS users on node/ip taos?(Enter y or n) -> y

Will attempt to connect to node/ip taos and extract list of TWS users. You may need to provide root password for node/ip taos. Password: fta2nd83fta83rtmm82am82bmae001 The above is a list of TWS users for FTA workstationslisted in the TWSRegistry.dat file on node/ip taos.You will need to specify the correct TWS user for TWSworkstation m82a.

Enter the TWS user for workstation m82a (node/ip taos) orpress enter to obtain list of TWS users on node/ip taos.->


between the master and FTA, the user will be prompted for root password for the FTA workstation. Refer to Figure 6.

If the script is unable to validate the user, it will ask if you want to still use the specified user. Refer to Figure 9. This warning could be caused by:

– An invalid user– FTA workstation “this cpu” field in the localopts file is incorrect – Master workstation is unable to connect to FTA workstation

Figure 9 Unable to validate TWS FTA user

Once the TWSuser for FTA has been validated, information about the FTA will be extracted. Extracted FTA workstation information is obtained from the master Symphony file, FTA localopts, and TWSregistryt.dat files. The extracted information will be displayed and will prompt for the local base path for fixpack files. Refer to Figure 10.

Enter the TWS user for workstation m82a (node/ip taos) orpress enter to obtain list of TWS users on node/ip taos.-> pete

/localopts: No such file or directoryThe extracted value in the "thiscpu" field of localopts for user pete is:<empty> or localopts file does not exist.

Warning: Unable to validate user. Enter y to use user peteor n to specify another user ->


Figure 10 Validate user and prompt for fixpack base path

11.Provide the fixpack base path for FTA (see base path requirements shown in Example 6).

Example 6

Suggested naming convention.The fixpack directory should have a common base path followed by TWSversion/OS (/patchesbasepath/twsversion/os).

Example: Base path directory for AIX FTA currently on TWS 8.3/images/patches/8.3.0/aix

Where:patchesbasepath = /images/patchestwsverison = is 8.3.0 (use 3 digit format)os = aix (aix, hpux,linux_i386 or solaris

The extracted value in the "thiscpu" field of localopts for user m82a is:m82a Logon user m82a exists. The TWS user m82a will be used for TWS workstation m82a. Will try to determine OS and current TWS version for FTA m82a.FTA m82a should be linked, this may take a few seconds. Extracted TWS version for m82a is 8.2Will use TWS version 8.2.0. Extracted OS for m82a is HP-UX. OS HPUX will be used for m82a. Provide base path for patches for FTA m82a on taos on current TWS version.Path should start with slash / ->

Note: The base path provided must be valid, because it will be used to determine the fixpack directory path.


Figure 11 Password prompt

12.Provide the root password for FTA; it may prompt for root password if an SSH certificate does not exist. Refer to Figure 11. Once the path has been validated it will ask if you want to use specified path. Refer to Figure 12.

Figure 12 Fixpack path validation and prompt

Once the base path has been confirmed, the FTA definition file will be created for the FTA. Refer to Figure 13.

Figure 13 FTA.ftaworkstation file creation and fixpack prompt

13.You must then provide the fixpack number to install. The fixpack must be a two digit number. The fixpack number will be verified that it exists locally on the FTA, and that it is the same or greater than what is currently installed on the FTA before proceeding. Refer to Figure 14.

/images/patches/8.2.0/hpux

You may need to provide the root password for taos. Password:

Path /images/patches/8.2.0/hpux exists

Enter y, to use this path or enter n to specify another path.->

Enter y, to use this path or enter n to specify another path.-> y

Base patch path /images/patches/8.2.0/hpux will be used for m82a

User m82a, TWS current version 8.2.0, OS HPUX and base patch path/images/patches/8.2.0/hpux for FTA workstation m82a on node/IP taosbasic information will be used for TWS FTA and will be added to:

/etc/TWS/MDM.m821a.m821a/FTA.m82a

Provide TWS 8.2.0 patch level to install, in ## format ie.. 01, 02, 03 …

Enter TWS patch level->


Figure 14 Fixpack verification

14.Provide the root password for FTA if an SSH certificate does not exist.

Once the fixpack number has been entered it will determine if fixpack may be applied. The script will install fixpacks that are at same level or higher than current or the last fixpack applied to FTA workstation, or if FTA workstation has no previous fixpacks. It will ask if you want to use a specified fixpack if it meets the requirement. Refer to Figure 15.

Note: When fixpack path for fixpacks is created in the base patch path, it must be fp##, where “fp” text is in lowercase and “##” is fixpack number in two digit format. Provide the two digit fixpack number when replying to fixpack prompt.

Because each fixpack includes all fixes for previous fixpacks, entering multiple fixpacks for the same FTA workstation is not required.


Enter TWS patch level of patch -> 10

Level entered is 1010 TWS patch level 10 will be verified. Base patch path is /images/patches/8.2.0/hpux. Will verifythat patch files exist in /images/patches/8.2.0/hpux/fp10directory.

You may need to provide root password for node/ip taos Password:


Figure 15 Fixpack installation confirmation

15.Reply to prompt asking if the specified fixpack number should be used. If the reply is “n”, you will need to provide another fixpack number. If it is “y”, a job definition will be created in the patch_job_def file in the /etc/TWS/MDM.masteruser.mastername directory. This file will contain the information required to install the specified fixpack on the FTA workstation. Refer to Figure 16.

Figure 16 Apply fixpack to another FTA prompt

You may need to provide root password for node/ip taos Password:

Lasted installed version is 8.2.0, Lasted installed fixpack level is 10

Untarred patch files exist for patch 8.2.0-TIV-TWS-FP0010.TAR

WARNING: Specified patch level to install is same level as currentlyinstalled on workstation.

Do you want to use the specified information? (Enter y or n) ->

Do you want to use the specified information? (Enter y or n) -> y

WARNING: Current specified patch file will be used

Patch install job definition file patch_job_def will be createdin the /etc/TWS/MDM.m821a.m821a directory.

FTA Patch Menu

Do you want to enter another FTA to patch? To patch another FTA enter (p) To go back to Main Menu enter (b) To exit utility enter (e) Enter p, b or e) ->


16.Reply to above prompt to provide information to apply the fixpack to another FTA workstation, go back to Main Menu, or exit the autoinstall.sh script. Refer to Figure 17.

Temporary files generated by the script will be removed when exiting normally from the script.

Figure 17 Exit autoinstall.sh utility

Patching procedures- Subsequent executions

Executing the autoinstall.sh script later will bypass some of the initial operations and screens. If an MDM already exists it will display information for MDM and will ask if you want to use the existing MDM definition. Refer to Figure 18.

Figure 18 Use existing MDM definition

1. Reply to the prompt with “y” to use the existing MDM definition.

Replying “n” will prompt the user to provide information for the new MDM and will use the new MDM definition. Refer to Figure 19.

Enter p, b or e) -> e

Will exit patch FTA mode.

The current process id is 28525, removing all temporaryfiles with .28525 extension in the /tmp directory.

Exiting ./autoinstall.sh script.

Note: Using a different MDM definition is only possible if the current workstation has multiple master instances.



Found an existing MDM definition for m821a user on mastercpu m821a on this workstation, ok to use? (Enter y or n) ->


Figure 19 Prompt for new MDM definition

Replying “y” will display a message stating that the existing MDM definition for the TWS user on the master workstation will be used. The script will ask the user if they want to use the APPL.tws application definition. Refer to Figure 20.

Figure 20 Use APPL.tws definition prompt

2. Reply to the prompt asking to use the existing APPL.tws application.

Found an existing MDM definition for m821a user on mastercpu m821a on this workstation, ok to use? (Enter y or n) -> n

You will need to create a mdm definition file. This is a list of defined MDM users in the TWSRegistry.dat filefor this workstation. m821am83rtm Enter TWS User for master cpu or press enter to obtain a list ofMDM users listed in the TWSRegistry.dat file ->

Found an existing MDM definition for m821a user on mastercpu m821a on this workstation, ok to use? (Enter y or n) -> y

Existing TWS user m821a for mastercpu m821a on this workstation will be used. This is a list of defined MDM users in the TWSRegistry.dat filefor this workstation. m821am83rtm drwxrwxr-x 2 root sys 96 Feb 20 16:15 /etc/TWS/APPL.tws Found the tws application definition on thisworkstation, ok to use? (Enter y or n) ->


Reply “n” to use or provide another APPL.xxxx definition. This requires that the autoinstall.sh utility script be modified to include user defined functions for the new application. You will need to provide the name for the application directory. The script will precede the name with APPL., when creating the definition directory. Refer to “Create a new APPL.xxxx definition” on page 33 for more details. Refer to Figure 21.

Figure 21 Create new APPL.xxxx definition prompt

After replying “y” to use the APPL.tws definition, the master workstation definition will be used for managing information of FTA workstations.

3. Reply “p” to proceed, providing information about the FTA workstation to patch. Refer to Figure 22.

The utilities option is discussed later. Temporary files generated by the script will be removed when exiting normally from the script.

Found the tws application definition on thisworkstation, ok to use? (Enter y or n) -> n

You will need to create a APPL definition. Enter name for application ->


Figure 22 Prompt for patch or utilities operations

The following prompt as shown in Figure 23 will appear, asking that you provide a valid FTA to patch. Depressing “Enter” will list all of the workstations that exist in the Symphony file. Only UNIX FTA workstations may be patched.

Figure 23 FTA patch installation prompt

Pressing <Enter> will display all of the workstations that exist on the current master. Refer to Figure 24.

Found the tws application definition on thisworkstation, ok to use? (Enter y or n) -> y Application tws definition for master cpu m821aon this workstation will be used to schedule install. Application tws will be used.logout The current process id is 20511, Temporary created files willbe created in the /tmp directory and have a .20511 extension. Main Menu To patch a workstation enter (p). To access FTA or job and job stream utilities enter (u). To exit utility enter (e). Enter p, u or e ->

Caution: Pressing <Enter> will display all defined workstations. The displayed list will scroll on the screen as they are displayed.

Enter p, u or e -> p

Enter a valid FTA workstation name to patch. Press enter to display a list of valid workstations in current Symphony file on master cpu. ->


Figure 24 FTA Listing

4. Provide an FTA to patch. The script will determine if the workstation is a UNIX FTA then gather some basic FTA workstation information from the Symphony file and display. Refer to Figure 25.

Note: Only UNIX FTA workstations may be patched.

Enter a valid FTA workstation name to patch. Press enterto display a list of valid workstations in current Symphony fileon master cpu. -> <enter>

Below is a list of valid FTA’s for m821a master user:

M821A M821A AF T 38211 taosHORBLM82 HORBLM82 A AT 31822 testmasterM82A M82A AFAT 31822 taosXA-FUEGO M82A A AT 31822 fuego.tivlab.austin.ibm.com

Enter a valid FTA workstation name to patch. Press enterto display a list of valid workstations in current Symphony fileon master cpu. ->


Figure 25 Extracted FTA workstation information

5. Provide the TWSuser specified when the FTA was installed, or press <Enter> to extract a list of users for TWS instances on FTA. The application will attempt to verify the specified user. If a SSH certificate file does not exist between the master and FTA user will be prompted for root password for FTA workstation. Refer to Figure 26.

Enter a valid FTA workstation name to patch. Press enterto display a list of valid workstations in current Symphony fileon master cpu. -> m82a

Input value is M82A TWS workstation M82A on node/ip taosis a UNIX FT-AGENT ie.. an FTA.

TWS workstation M82A on node taos is valid,will patch. Will determine if basic information for FTA m82a onmaster m821a exists. Will need to create information file for m82a:/etc/TWS/MDM.m821a.m821a/FTA.m82asince the above file does not exist. Additional information is required for TWS workstation m82a. Enter the TWS user for workstation m82a (node/ip taos) orpress enter to obtain list of TWS users on node/ip taos.->


Figure 26 Validate TWS FTA user

If <Enter> is depressed it will prompt whether you want to extract list of users on node/ip for FTA. Replying “y” will then prompt of root password for node/ip of FTA. Refer to Figure 27.

Figure 27 Prompt to extract TWS users for FTA workstation

Replying “y” to “extract list of TWS users” will then prompt for password for the FTA workstation.

A list of TWS users for instances on FTA will be displayed. Refer to Figure 28.

Enter the TWS user for workstation m82a (node/ip taos) orpress enter to obtain list of TWS users on node/ip taos.-> m82a

Will try to validate TWS user m82a and that it manages TWS workstation m82a.

You may need to provide root password for node/ip taos more than once. Password:

Enter the TWS user for workstation m82a (node/ip taos) orpress enter to obtain list of TWS users on node/ip taos.-> enter

Do you want to extract list of TWS users on node/ip taos?(Enter y or n) ->


Figure 28 Extracted list of TWS users for FTA workstation

Provide TWSuser specified when the FTA was installed. The application will attempt to verify the specified user. If a SSH certificate file does not exist between the master and FTA, the user will be prompted for root password for the FTA workstation. Refer to Figure 26.

If the script is unable to validate the user, it will ask if you want to still use the specified user. Refer to Figure 29. This warning could be caused by:

� An invalid user� FTA workstation “this cpu” field in the localopts file is incorrect � Master workstation is unable to connect to FTA workstation

Do you want to extract list of TWS users on node/ip taos?(Enter y or n) -> y

Will attempt to connect to node/ip taos and extract list of TWS users. You may need to provide root password for node/ip taos. Password: fta2nd83fta83rtmm82am82bmae001 The above is a list of TWS users for FTA workstationslisted in the TWSRegistry.dat file on node/ip taos.You will need to specify the correct TWS user for TWSworkstation m82a.

Enter the TWS user for workstation m82a (node/ip taos) orpress enter to obtain list of TWS users on node/ip taos.->


Figure 29 Unable to validate TWS FTA user

Once the TWSuser for FTA has been validated, information about the FTA will be extracted. Extracted FTA workstation information is obtained from the master Symphony file, from the FTA localopts and TWSregistryt.dat files. The extracted information will be displayed and will prompt for the local base path for fixpack files. Refer to Figure 30.


Example 7 Fixpack base path requirements

The following naming convention.The fixpack directory should have a common base path followed by TWSversion/OS (/patchesbasepath/twsversion/os).Example: Base path directory for AIX FTA currently on TWS 8.3

Enter the TWS user for workstation m82a (node/ip taos) orpress enter to obtain list of TWS users on node/ip taos.-> test

Warning: Unable to validate user. Enter y to use user testor n to specify another user ->

The extracted value in the "thiscpu" field of localopts for user m82a is:m82a Logon user m82a exists. The TWS user m82a will be used for TWS workstation m82a. Will try to determine OS and current TWS version for FTA m82a.FTA m82a should be linked, this may take a few seconds. Extracted TWS version for m82a is 8.2Will use TWS version 8.2.0. Extracted OS for m82a is HP-UX. OS HPUX will be used for m82a. Provide base path for patches for FTA m82a on taos on current TWS version. Path should start with slash / ->


/images/patches/8.3.0/aixWhere:patchesbasepath = /images/patchestwsverison = is 8.3.0 (use 3 digit format)os = aix (aix, hpux,linux_i386 or solaris)

6. Provide the fixpack base path for FTA (see base path requirements in Example 7).


7. Provide the root password for FTA; it may prompt for root password if an SSH certificate does not exist. Refer to Figure 31. Once the path has been validated it will ask if you want to use the specified path. Refer to Figure 32.


Once the base path has been confirmed, the FTA definition file will be created for the FTA. Refer to Figure 33.

Provide base path for patches for FTA m82a on taos on current TWS version. Path should start with slash / -> /images/patches/8.2.0/hpux


You may need to provide the root password for taos. Password:Path /images/patches/8.2.0/hpux exists Enter y, to use this path or enter n to specify another path.->


Figure 33 FTA.ftaworkstation file creation and fixpack prompt

8. You must then provide the fixpack number to install. The fixpack must be in a two digit number. The fixpack number will be verified that it exists locally on the FTA, and that it is the same or greater than what is currently installed on the FTA before proceeding. Refer to Figure 34.


Base patch path /images/patches/8.2.0/hpux will be used for m82a User m82a, TWS current version 8.2.0, OS HPUX and base patch path/images/patches/8.2.0/hpux for FTA workstation m82a on node/IP taosbasic information will be used for TWS FTA and will be added to:

/etc/TWS/MDM.m821a.m821a/FTA.m82a Provide TWS 8.2.0 patch level to install, in ## format ie.. 01, 02, 03 …

Enter TWS patch level ->

Note: When the fixpack path for fixpacks is created in the base patch path, it must be fp##, where “fp” text is in lowercase and “##” is fixpack number in two digit format. Provide the two digit fixpack number when replying to the fixpack prompt.



Figure 34 Fixpack to apply and password prompt

9. Provide the root password for FTA if an SSH certificate does not exist.

Once the fixpack number has been entered it will determine if the fixpack may be applied. The script will install fixpacks that are at same level or higher than current or last fixpack applied to FTA workstation or if FTA workstation has no previous fixpacks. It will ask if you want to use specified fixpack if it meets the requirement. Refer to Figure 35.

Figure 35 Fixpack installation confirmation


Enter TWS patch level -> 10

Level entered is 1010 TWS patch level 10 will be verified. Base patch path is /images/patches/8.2.0/hpux. Will verifythat patch files exist in /images/patches/8.2.0/hpux/fp10directory. You may need to provide root password for node/ip taos Password:

Base patch path is /images/patches/8.2.0/hpux. Will verifythat patch files exist in /images/patches/8.2.0/hpux/fp10directory. You may need to provide root password for node/ip taos Password:

Lasted installed version is 8.2.0, Lasted installed fixpack level is 10

Untarred patch files exist for patch 8.2.0-TIV-TWS-FP0010.TAR WARNING: Specified patch level to install is same level as currentlyinstalled on workstation. Do you want to use the specified information? (Enter y or n) ->


10.Reply to the prompt asking if the specified fixpack number should be used. If the reply is “n” you will need to provide another fixpack number. If the reply is “y” a job definition will be created in the patch_job_def file in the /etc/TWS/MDM.masteruser.mastername directory. This file will contain the information required to install the specified fixpack on the FTA workstation. Refer to Figure 36.

Figure 36 Apply fixpack to another FTA prompt

11.Reply to the prompt to provide information to apply the fixpack to another FTA workstation or to exit the autoinstall.sh script.

Temporary files generated by the script will be removed when exiting normally from the script. Refer to Figure 37.

Figure 37 Exit autoinstall.sh script

Do you want to use the specified information? (Enter y or n) -> y

WARNING: Current specified patch file will be used Patch install job definition file patch_job_def will be createdin the /etc/TWS/MDM.m821a.m821a directory.

FTA Patch Menu

Do you want to enter another FTA to patch? To patch another FTA enter (p) To go back to Main Menu enter (b) To exit utility enter (e) Enter p, b or e) ->

Enter p, b or e) -> e

Will exit patch FTA mode. The current process id is 28525, removing all temporaryfiles with .28525 extension in the /tmp directory. Exiting ./autoinstall.sh script.


Create a new APPL.xxxx definition

The autoinstall.sh utility script may be used to patch or install any application that uses a UNIX command line installation. The script will require that additional functions/modules be added to support this functionality. It will be the user’s responsibility to edit and support the new functions. TWS level 2 support will not support these changes. Contact IBM Services to provide this service.

The APPL.xxxx definition is part of a MDM definition, because the master for the MDM is used to schedule the patch or installation of the APPL.xxx application. To define a new APPL.xxxx definition execute the autoinstall.sh utility script. A prompt will ask you if you want to use an existing MDM definition.

1. Reply “y” to the prompt asking to use the existing MDM definition. Refer to Figure 38.


2. Reply “n” to the prompt asking to use the APPL.tws application definition. Refer to Figure 39.

Current system OS is HPUX The current process id is 18671, Temporary created files willbe created in the /tmp directory and have a .18671 extension.




3. Provide the name for the new APPL.xxxx definition directory. The script will precede the name with APPL. prefix when creating the definition directory. Refer to Figure 40.

Figure 40 New APPL.xxxx definition directory prompt

After entering the name for the new APPL.xxxx definition you will be asked if you want to use the provided name.

4. Reply “y” to use this name or “n” to re-enter a new name. Refer to Figure 41.



Found the tws application definition on thisworkstation, ok to use? (Enter y or n) -> n

You will need to create a APPL definition. Enter name for application ->


Figure 41 Confirm new APPL.xxxx definition directory

5. Reply “y” to the prompt to use the new APPL.xxxx definition; the script will attempt to access the new functions or modules that should have been added to the autoinstall.sh script. If the script has not be edited for this, then it will exit after creating the new APPL.xxxx definition and displaying current the APPL.xxxx definition directories. Refer to Figure 42.

Figure 42 Creation of new APPL.xxxx definition

Utilities Operations

The utilities operations consist of FTA, or job and jobs stream, utility tasks. The FTA utilities are for FTA maintenance operations used to add, update, or delete an FTA.workstation file or to export fixpack installation utility scripts from the master to the FTA workstation.

Enter name for application -> test You specified test definition is this correct. (y or n) ->

You specified test definition is this correct. (y or n) -> y

APPL.test directory will be created on thisworkstation and will be available for future installs Will create APPL definition directory test on m821a /etc/TWS/APPL.test /etc/TWS/APPL.tws Application test will be used.

Application install is not TWS. The current process id is 12365, removing all temporaryfiles with .12365 extension in the /tmp directory. Exiting ./autoinstall.sh script.


The job and job stream utilities include a task that creates the job streams for fixpack installation jobs, a task to add job and job stream definitions to the TWS jobs and job stream database, or a task to rename the patch_job_def job definition file.

The renamed patch_job_def file will have an extension of _mmddyy_hhmmss, where mmddyy is the month, day, and year, and hhmmss is hour, minute, and second.

Utilities - FTA Utilities

FTA maintenance will be performed from the FTA Utilities Menu. You will need to proceed past some of the general menus or prompts to get to the FTA Utilities Menu.

If an MDM already exists it will display information for MDM and ask if you want to use the existing MDM definition. Refer to Figure 43.


1. Reply to prompt with “y” to use existing MDM definition.

Replying “y” will display a message stating that existing MDM definition for TWS user on the master workstation will be used. The script will ask the user if they want to use the APPL.tws application definition. Refer to Figure 44.

Note: Using a different MDM definition is only possible if the current workstation has multiple master instances.






2. Reply “y” to the prompt asking to use the existing APPL.tws application. Refer to Figure 45.

After replying “y” to use the APPL.tws definition, the master workstation definition will be used for managing information of FTA workstations.





3. Reply “u” to proceed to the Main Utilities Menu. Refer to Figure 46.

Figure 46 FTA utilities menus

4. For FTA maintenance tasks, reply f to perform FTA maintenance tasks.

Found the tws application definition on thisworkstation, ok to use? (Enter y or n) -> y Application tws definition for master cpu m821aon this workstation will be used to schedule install. Application tws will be used.logout


Main Menu To patch a workstation enter (p). To access FTA or job and job stream utilities enter (u). To exit utility enter (e). Enter p, u or e ->

Enter p, u or e -> u

Main Utilities Menu

To access FTA utilities enter (f).

To access job and job stream utilities enter (j).

To go back to Main Menu enter (b).

To exit utility enter (e).

Enter f, j, b or e ->


Figure 47 FTA utilities menu

Proceed to one of these sections:

– “Add or Update an FTA File” on page 39 – “Delete an FTA file” on page 51– “Export Utility Scripts to FTA” on page 53

Refer to Figure 47.

Add or Update an FTA Filei. At the FTA Utilities Menu screen, reply a to add or update an FTA

definition file. Refer to Figure 48.

Figure 48 List FTA definition prompt

Entering l will display a list of current FTA definitions that already exist in the MDM.mastername.mastername definition directory. This option should be selected it you want to see existing FTA.workstation definition files.

Enter f, j, b or e -> f

FTA Utilities Menu To add or update an FTA file enter (a). To delete an FTA file enter (d). To export the utility scripts to an FTA enter (x).

To go back to Main Utilities Menu enter (b). To exit utility enter (e). Enter a, d, x, b or e ->

Enter a, d, x, b or e -> a FTA to be added or updated must be exist in current Symphony fileand linked before executing utility. Press enter l to get a list of FTA files that may be updated orany other key to bypass list. ->


Pressing any other key will bypass this operation.

ii. Press either “l” or any key to continue. Refer to Figure 49.

Figure 49 Existing FTA.workstation list and FTA name to add or update prompt

The script will then prompt for FTA name to add or update; pressing <Enter> will display a list of workstations that exist in the current master Symphony file. Refer to Figure 50.

Figure 50 Workstation list from the master Symphony file

Press enter l to get a list of FTA files that may be updated orany other key to bypass list. -> l Below is a list of current FTA files managed by Master cpu m821a. MDM.m821a.m821a/FTA.m82a This is the FTA add or update module. Enter a valid FTA workstation name to add or update. Press enter to display a list of valid workstations in current Symphony file on master cpu. ->

Caution: Pressing <Enter> will display all defined Workstations. The displayed list will scroll on the screen as they are displayed.

Enter a valid FTA workstation name to add or update. Press enter to display a list of valid workstations in current Symphony file on master cpu.-> <enter> Below is a list of valid FTA's for m821a master user. M821A M821A AF T 38211 taosHORBLM82 HORBLM82 A AT 31822 testmasterM82A M82A AFAT 31822 taosXA-FUEGO M82A A AT 31822 fuego.tivlab.austin.ibm.com Enter a valid FTA workstation name to add or update. Press enter to display a list of valid workstations in current Symphony file on master cpu. ->


iii. Reply to prompt with FTA name. If FTA name exists as an FTA.workstation definition file it will update the existing file. If the file FTA.workstation definition file does not exist it will prompt for FTA specific information to add a new FTA definition.

Proceed to one of these sections: “Add New FTA Definition” on page 41, or “Update an Existing FTA.workstation File” on page 46.

Add New FTA DefinitionPress <Enter> to display a current list of workstations in the master Symphony file.

iv. Enter the name of the UNIX FTA workstation that exists in the master’s Symphony file. The script will extract specific information to generate the FTA.workstation file if FTA exists in the master’s Symphony file and is a UNIX FTA.

It will display the following and ask for the TWS user that was specified when FTA was installed. Refer to Figure 51.

Note: The FTA must exist in the Symphony file to be linked to the master, to extract the required information for the FTA.workstation file.


Figure 51 FTA verification and TWS user prompt

v. You may provide the TWSuser for the FTA specified or press <Enter> to obtain a list of Tivoli Workload Scheduler instance users that exist on the FTA workstation. The list of Tivoli Workload Scheduler instance users is extracted from the TWSRegistry.dat file.

Pressing <Enter> to produce a list of users for Tivoli Workload Scheduler instances that exist on the FTA workstation may require the root password if an SSH certificate does not exist on FTA. Refer to Figure 52.

Input value is HORBLM82. TWS workstation HORBLM82 on node/ip testmasteris a UNIX FT-AGENT ie.. an FTA.

TWS workstation HORBLM82 on node testmaster is valid,will add or update. Will determine if basic information for FTA horblm82 onmaster m821a exists. Will need to create information file for horblm82:/etc/TWS/MDM.m821a.m821a/FTA.horblm82since the above file does not exist. Additional information is required for TWS workstation horblm82. Enter the TWS user for workstation horblm82 (node/ip testmaster) orpress enter to obtain list of TWS users on node/ip testmaster.->

Note: The user list displayed, will consist of users for all Tivoli Workload Scheduler instances that exist, if multiple Tivoli Workload Scheduler instances exist on the FTA node. You must use the Tivoli Workload Scheduler user for the FTA that was specified in the previous step.


Figure 52 List of FTA node TWS instance users

Provide the Tivoli Workload Scheduler user for the specified FTA; you may be prompted for the root password for the FTA node. Refer to Figure 53.

Figure 53 FTA TWS user prompt and root password prompt

Enter the TWS user for workstation horblm82 (node/ip testmaster) orpress enter to obtain list of TWS users on node/ip testmaster.-> <enter> Do you want to extract list of TWS users on node/ip testmaster?(Enter y or n) -> y Will attempt to connect to node/ip testmaster and extract list of TWS users.

You may need to provide root password for node/ip testmaster. Password:e82pdmf821

The above is a list of TWS users for FTA workstationslisted in the TWSRegistry.dat file on node/ip testmaster.You will need to specify the correct TWS user for TWSworkstation horblm82. Enter the TWS user for workstation horblm82 (node/ip testmaster) orpress enter to obtain list of TWS users on node/ip testmaster.->

Enter the TWS user for workstation horblm82 (node/ip testmaster) orpress enter to obtain list of TWS users on node/ip testmaster.-> e82pdm Will try to validate TWS user e82pdm and that it manages TWS workstation horblm82.

You may need to provide root password for node/ip testmastermore than once. Password:


vi. Enter root password of the FTA node.

Once the TWSuser for FTA has been validated, information about the FTA will be extracted. Extracted FTA workstation information is obtained from the master Symphony file, from the FTA localopts, and TWSregistryt.dat files. The extracted information will be displayed and will prompt for the local base path for fixpack files. Refer to Figure 54.




/images/patches/8.3.0/aixWhere:patchesbasepath = /images/patchestwsverison = is 8.3.0 (use 3 digit format)os = aix (aix, hpux,linux_i386 or solaris)

vii. Provide the fixpack base path for FTA (see base path requirements in Example 8).

Logon user e82pdm exists. The TWS user e82pdm will be used for TWS workstation horblm82. Will try to determine OS and current TWS version for FTA horblm82.FTA horblm82 should be linked, this may take a few seconds. Extracted TWS version for horblm82 is 8.2Will use TWS version 8.2.0. Extracted OS for horblm82 is HP-UX. OS HPUX will be used for horblm82. Provide base path for patches for FTA horblm82 on testmaster on current TWS version. Path should start with slash / ->



viii.Provide the root password for FTA; it may prompt for root password if an SSH certificate does not exist. Once the path has been validated it will ask if you want to use the specified path. Refer to Figure 56.


ix. Reply “y” to use the specified path.

Once the base path has been confirmed, the FTA definition file will be created for the FTA. The script will ask to add or update another FTA or to exit the utility. Refer to Figure 57.

Provide base path for patches for FTA horblm82 on testmaster on current TWS version. Path should start with slash / -> /images/patches/8.2.0/hpux





Path /images/patches/8.2.0/hpux exists Enter y, to use this path or enter n to specify another path.->


Figure 57 Create FTA.workstation file

x. Reply to prompt; a will prompt FTA to add or update, “b” will return to the FTA Utilities Menu, and e will exit the utility script.

Temporary files generated by the script will be removed when exiting the script. Refer to Figure 58.

Figure 58 Exit script

Update an Existing FTA.workstation FilePress <Enter> to display a current list of workstations in the master Symphony file.


The extracted value in the "thiscpu" field of localopts for user e82pdm is:horblm82 User e82pdm, TWS current version 8.2.0, OS HPUX and base patch path/images/patches/8.2.0/hpux for FTA workstation horblm82 on node/IP testmaster basic information will be used for TWS FTA and will be added to:

/etc/TWS/MDM.m821a.m821a/FTA.horblm82 Do you want to add or update another FTA? To add or update another FTA enter (a) To go back to FTA Utilities Menu enter (b) To exit utility enter (e) Enter a, b or e to exit ->

Enter a, b or e to exit -> e

The current process id is 28800, removing all temporaryfiles with .28800 extension in the /tmp directory. Exiting ./autoinstall.sh script.


i. Enter the name of the UNIX FTA workstation, to update. The FTA must exist in the master’s Symphony file. The script will extract specific information to update the FTA.workstation file.

It will display existing information and ask if you want to use this information. Refer to Figure 59.

Figure 59 Display existing FTA.workstation definition file information

ii. Reply “n” to proceed. You will be prompted to provide the Tivoli Workload Scheduler user for the FTA workstation. Refer to Figure 60.

Note: The FTA must exist in the Symphony file to be linked to the master, to extract and update the required information for the FTA.workstation file.

Enter a valid FTA workstation name to add or update. Press enter to display a list of valid workstations in current Symphony file on master cpu. -> m82a Input value is M82A. TWS workstation M82A on node/ip taosis a UNIX FT-AGENT ie.. an FTA. TWS workstation M82A on node taos is valid,will add or update. Will determine if basic information for FTA m82a onmaster m821a exists. Information for m82a exists in file/etc/TWS/MDM.m821a.m821a/FTA.m82a

Basic information for FTA m82a:

CPUNAME=m82aNODENAME_IP=taosTWSUSER=m82aVERSION=8.2.0OS=HPUXBASEPATCHPATH=/images/patches/8.2.0/hpux Do you want to use above information? (Enter y or n) ->


Figure 60 Provide Tivoli Workload Scheduler user for FTA.workstation prompt

iii. Provide the Tivoli Workload Scheduler user for the FTA workstation.

Once the TWSuser for FTA has been validated, information about the FTA will be extracted. Extracted FTA workstation information is obtained from the master Symphony file, from the FTA localopts, and TWSregistryt.dat files. The extracted information will be displayed and will prompt for the local base path for fixpack files. Refer to Figure 61.

Do you want to use above information? (Enter y or n) -> n You will need to create an updated information file for TWS workstation m82a. Additional information is required for TWS workstation m82a. Enter the TWS user for workstation m82a (node/ip taos) orpress enter to obtain list of TWS users on node/ip taos.->



iv. Provide the fixpack base path for FTA (see base path requirements in Example 9).



/images/patches/8.3.0/aix

Enter the TWS user for workstation m82a (node/ip taos) orpress enter to obtain list of TWS users on node/ip taos.-> m82a Will try to validate TWS user m82a and that it manages TWS workstation m82a.

You may need to provide root password for node/ip taosmore than once. Password:

The extracted value in the "thiscpu" field of localopts for user m82a is:m82a Logon user m82a exists. The TWS user m82a will be used for TWS workstation m82a. Will try to determine OS and current TWS version for FTA m82a.FTA m82a should be linked, this may take a few seconds. Extracted TWS version for m82a is 8.2Will use TWS version 8.2.0. Extracted OS for m82a is HP-UX. OS HPUX will be used for m82a. Provide base path for patches for FTA m82a on taos on current TWSversion. Path should start with slash / ->


Where:patchesbasepath = /images/patchestwsverison = is 8.3.0 (use 3 digit format)os = aix (aix, hpux,linux_i386 or solaris)


v. Provide the root password for FTA, it may prompt for root password if an SSH certificate does not exist. Refer to Figure 62. Once the path has been validated it will ask if you want to use specified path. Refer to Figure 63.


Once the base path has been confirmed, the FTA definition file for the FTA will be updated. The script will ask to add or update another FTA, go back to FTA Utilities Menu, or to exit the utility. Refer to Figure 64.

Provide base path for patches for FTA m82a on taos on current TWSversion. Path should start with slash / -> /images/patches/8.2.0/hpux



Path /images/patches/8.2.0/hpux exists Enter y, to use this path or enter n to specify another path.->


Figure 64 Update FTA.workstation file

vi. Reply to the prompt; “y” will prompt FTA to add or update, “b” will return to FTA Utilities Menu, and “e” will exit the utility script.

Temporary files generated by the script will be removed when exiting the script. Refer to Figure 65.

Figure 65 Exit script

Delete an FTA filei. At the FTA Utilities Menu screen, enter d to delete an FTA.workstation

file. Refer to Figure 66.


Base patch path /images/patches/8.2.0/hpux will be used for m82a User m82a, TWS current version 8.2.0, OS HPUX and base patch path/images/patches/8.2.0/hpux for FTA workstation m82a on node/IP taosbasic information will be used for TWS FTA and will be added to:

/etc/TWS/MDM.m821a.m821a/FTA.m82a Do you want to add or update another FTA? To add or update another FTA enter (a) To go back to FTA Utilities Menu enter (b) To exit utility enter (e) Enter a, b or e to exit ->

Enter a, b or e to exit -> e

The current process id is 28800, removing all temporaryfiles with .28800 extension in the /tmp directory. Exiting ./autoinstall.sh script.


Figure 66 FTA Utilities menu

ii. Press <Enter> to get a list of the defined FTA.workstation files. Refer to Figure 67.

Figure 67 List of defined FTA.workstation definition files.

iii. Enter the name of the FTA to delete; there is no need to precede ftaname with “FTA.” text. Refer to Figure 68.

Figure 68 FTA name to delete

FTA Utilities Menu To add or update an FTA file enter (a). To delete an FTA file enter (d). To export the utility scripts to an FTA enter (x). To go back to Main Utilities Menu enter (b).

To exit utility enter (e). Enter a, d, x, b or e -> d Enter name of FTA file (do not use *) to delete, press enter to get a list of FTA files or e to exit utility. ->

Enter name of FTA file to delete, press enter to get a listof FTA files or e to exit utility. -> <enter> /etc/TWS/MDM.m821a.m821a/FTA.horblm82 /etc/TWS/MDM.m821a.m821a/FTA.m82a Enter name of FTA file to delete, press enter to get a listof FTA files or e to exit utility. ->

Enter name of FTA file (do not use *) to delete, press enter to get a list of FTA files or e to exit utility. -> horblm82 Do you want to delete the FTA file? (Enter y, n or e to exit) ->


iv. Reply “y” to delete the file; the script will remove FTA.workstation file. Next the prompt will ask to delete another FTA, return to the FTA Utilities Menu, or exit the utility. Refer to Figure 69.

Figure 69 FTA delete confirmation

v. Reply to the prompt.

Export Utility Scripts to FTAi. At the FTA Utilities Menu screen, enter x to export the utility scripts to

FTA. Refer to Figure 70.

Note: Do not use “*” asterisk in the FTA name.

Do you want to delete the FTA file? (Enter y, n or e to exit) -> y File /etc/TWS/MDM.m821a.m821a/FTA.horblm82exists and will be removed. Do you want to delete another FTA? To delete another FTA enter (d) To go back to FTA Utilities Menu enter (b) To exit utility enter (e) (Enter d, b or e to exit) ->


Figure 70 Export utilities FTA workstation prompt

ii. Enter the name of the FTA to receive the utility scripts (do not enter the node/ip), or press <Enter> to view a list of FTA workstations. Refer to Figure 70.

Pressing <Enter> will display list of all workstations that exist on the current master’s Symphony file. Refer to Figure 71.

FTA Utilities Menu To add or update an FTA file enter (a). To delete an FTA file enter (d). To export the utility scripts to an FTA enter (x).

To go back to Main Utilities Menu enter (b).

To exit utility enter (e). Enter a, d, x or e -> x This is the FTA export util scripts module. Enter a valid FTA workstation name to receive utility scripts. Press enter to display a list of valid workstations in current Symphony file on master cpu. ->

Note: Use the FTA workstation name not the node/ip for workstation. Utility scripts may be sent to an FTA prior to creating the FTA.workstation file. The export uses UNIX scp, providing the root password for the FTA workstation, which may be required if an SSH certificate does not exist.


Figure 71 List of workstations on the current master Symphony file

The script will verify that the provided name is an FTA workstation. Refer to Figure 72.

Figure 72 Invalid agent type for workstation specified

iii. Provide the name for a UNIX FTA workstation.

After confirming that the provided name is for a UNIX FTA, the script will prompt for root password for FTA node/ip, if an SSH certificate does not exist. Refer to Figure 73.

Enter a valid FTA workstation name to receive utility scripts. Press enter to display a list of valid workstations in current Symphony file on master cpu. -> <enter> Below is a list of workstations for m821a master user. M821A M821A AF T 38211 taosHORBLM82 HORBLM82 A AT 31822 testmasterM82A M82A AFAT 31822 taosXA-FUEGO M82A A AT 31822 fuego.tivlab.austin.ibm.com Enter a valid FTA workstation name to receive utility scripts. Press enter to display a list of valid workstations in current Symphony file on master cpu. ->

Enter a valid FTA workstation name to receive utility scripts. Press enter to display a list of valid workstations in current Symphony file on master cpu. -> xa-fuego Input value is XA-FUEGO. TWS workstation XA-FUEGO on node/ip fuego.tivlab.austin.ibm.comis an UNIX X-AGENT, NOT a UNIX FTA. This utility may only patch UNIX FTA's. Enter a valid FTA workstation name to receive utility scripts. Press enter to display a list of valid workstations in current Symphony file on master cpu. ->


Figure 73 Confirmed FTA workstation, prompt for root password

iv. Provide root password for the FTA node/ip. You may need to provide the password twice.

Review the transfer messages to verify that they completed successfully. Refer to Figure 74.

Enter a valid FTA workstation name to receive utility scripts. Press enter to display a list of valid workstations in current Symphony file on master cpu. -> m82a Input value is M82A. TWS workstation M82A on node/ip taosis a UNIX FT-AGENT ie.. an FTA. TWS workstation M82A on node taos is valid,will receive utility scripts. You may need to provide root password for node/ip taosmore that once. Will attempt to transfer files to FTA m82a on node/ip taos.

Password:


Figure 74 Utility script transfer confirmation

v. Reply to the prompt to continue or to exit.

Job Stream Utilities

Specific steps are required after creating the job definitions for the fixpacks and must be performed in a specific order. You must create the job stream definitions files, add the job and job stream definitions and finally rename the patch_job_def file. The renamed patch_job_def file will have an extension of _mmddyy_hhmmss, where mmddyy is the month, day, and year, and hhmmss is hour, minute, and second.

These maintenance operations may be performed from the Job Stream Utilities Menu. You will need proceed past some of the general menus or prompts to get to the Job Stream Utilities Menu.

If an MDM already exists it will display information for MDM and ask if you want to use the existing MDM definition.

1. Reply to the prompt with “y” to use the existing MDM definition. Refer to Figure 75.

Will attempt to transfer files to FTA m82a on node/ip taos.

Password: patch_lau.sh 100% 6243 0.0KB/s 00:00 Password: patch_install.sh 100% 19KB 0.0KB/s 00:00 Review the above scp messages and verify that secure copieswere successful before proceeding. Do you want to export utility scripts to another FTA? To export utility scripts to another FTA enter (x) To go back to FTA Utilities Menu enter (b) To exit utility enter (e) Enter x, b or e to exit ->



Replying “y” will display a message stating that the existing MDM definition for the Tivoli Workload Scheduler user on the master workstation will be used. The script will ask the user if they want to use the APPL.tws application definition.

2. Reply ”y” to the prompt asking to use existing APPL.tws application, as shown Figure 76.

Figure 76 Use existing APPL.tws definition prompt

After replying “y” to use the APPL.tws definition, the master workstation definition will be used for managing information of FTA workstations. The Main Menu will then be displayed. Refer to Figure 77.








3. Reply “u” to proceed to the Main Utilities Menu. Refer to Figure 77.

Found the tws application definition on thisworkstation, ok to use? (Enter y or n) -> y Application tws definition for master cpu m821aon this workstation will be used to schedule install. Application tws will be used.logout


Main Menu To patch a workstation enter (p). To access FTA or job and job stream utilities enter (u). To exit utility enter (e). Enter p, u or e ->


Figure 78 FTA utilities menus

You will need to access the job and job stream utilities tasks.

4. Reply “j” to access job and job stream utilities tasks. Refer to Figure 78.

The script will ask if you want to create job stream information or add job and job stream definitions to the database. Refer to Figure 79.

Figure 79 Job and Job Stream Utilities Menu

Enter p to patch a workstation, u for utilities to create patch jobstreams, add jobs and job streams to database or e to exit utility.(Enter p, u or e) -> u

Main Utilities Menu

To access FTA utilities enter (f).

To access job and job stream utilities enter (j).

To go back to Main Menu enter (b). To exit utility enter (e).

Enter f, j, b or e -> j

Enter f, j, b or e -> j

Job and Job Stream Utilities Menu To create job stream definitions enter (c). To add job and job stream definitions to the database enter (a).

To rename patch_job_def defintion file enter (r). To go back to Main Utilities Menu enter (b).

To exit utility enter (e). Enter c, a, r, b or e ->


Create Job Stream Definition FilesAt the Job and Job Stream Utilities Menu, enter c to create job stream definitions. Refer to Figure 80.

The script will create the patch_lau_sch_def and patch_succ_sch_def files in the /etc/TWS/MDM.masteruser.mastername directory. Refer to Figure 80.

These files will contain the definitions for the TWSPATCH_LAUNCH and TWSPATCH_SUCC job streams. These definitions will run on the master once added to the Tivoli Workload Scheduler database. Unique job definitions created by the autoinstall.sh that exist in the etc/TWS/MDM.masteruser.mastername/patch_job_def file will be added to the TWSPATCH_LAUNCH job stream.

The job stream definitions files patch_lau_sch_def and patch_succ_sch_def will be created in the etc/TWS/MDM.masteruser.mastername directory.

Note: Multiple job definitions with the exact same name that exists in the patch_job_def file will exist only once in the TWSPATCH_LAUNCH job stream. This operation may be performed multiple times, because each execution will create the job stream definition files overwriting the previous files.


Figure 80 Job stream files creation

Add Job and Job Stream definitions to Tivoli Workload Scheduler databaseWhen ready, proceed to adding the final job stream definitions and initiate the add procedure.

At the Job and Job Stream Utilities Menu, enter a to add job and job stream definition files to the Tivoli Workload Scheduler database. Refer to Figure .

Enter c, a, r, b or e -> c

The patch_succ_sch_def file in the /etc/TWS/MDM.m821a.m821adirectory will have the TWSPATCH_SUCC job stream definition. 1 unique TWS patch install job definition(s) have been extractedfrom the patch_job_def file in the /etc/TWS/MDM.m821a.m821a directory to create the patch_lau_sch_def file. The patch_lau_sch_def file in the /etc/TWS/MDM.m821a.m821adirectory will have the TWSPATCH_LAUNCH job stream definition.Review the file and verify the patch install jobs for the FTA's before adding definitions to database. Job and Job Stream Utilities Menu To create job stream definitions enter (c). To add job and job stream definitions to the database enter (a). To rename patch_job_def defintion file enter (r). To go back to Main Utilities Menu enter (b).


Attention: Adding the job stream definitions to the Tivoli Workload Scheduler database will replace the existing job stream definition for TWSPATCH_LAUNCH and TWSPATCH_SUCC.


Figure 81 Add job and job stream definitions to TWS database

Enter c, a, r, b or e -> a Will add the following definition files to database:/etc/TWS/MDM.m821a.m821a/patch_job_def/etc/TWS/MDM.m821a.m821a/patch_lau_sch_def/etc/TWS/MDM.m821a.m821a/patch_succ_sch_defTWS for UNIX (HPUX)/COMPOSER 8.2.1 (1.18.2.21) Licensed Materials Property of IBM5698-WKB(C) Copyright IBM Corp 1998, 2005US Government User Restricted RightsUse, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.Installed for user 'm821a'.Locale LANG set to "C"-replace /etc/TWS/MDM.m821a.m821a/patch_job_defAWSBIA090E Total errors in /etc/TWS/MDM.m821a.m821a/patch_job_def: 0, warnings 0.-replace /etc/TWS/MDM.m821a.m821a/patch_lau_sch_defAWSBIA019E For M821A#TWSPATCH_LAUNCH Errors 0, warnings 0.AWSBIA016I Schedule M821A#TWSPATCH_LAUNCH replaced.AWSBIA090E Total errors in /tws/m821a/tmp/TWSEAAa22415: 0, warnings 0.-replace /etc/TWS/MDM.m821a.m821a/patch_succ_sch_defAWSBIA019E For M821A#TWSPATCH_SUCC Errors 0, warnings 0.AWSBIA016I Schedule M821A#TWSPATCH_SUCC replaced.AWSBIA090E Total errors in /tws/m821a/tmp/TWSHAAa22415: 0, warnings 0.Verify that there were no errors in the above messageswhen definitions were added to the database. Job and Job Stream Utilities Menu To create job stream definitions enter (c). To add job and job stream definitions to the database enter (a). To rename patch_job_def defintion file enter (r). To go back to Main Utilities Menu enter (b).



Rename patch_job_def fileAfter the job and job stream files have been added to the Tivoli Workload Scheduler database, renaming the patch_job_def is required for future fixpack autoinstall.sh script runs.

At the Job and Job Stream Utilities Menu, enter r to rename the patch_job_def. Refer to Figure 82.

The renamed patch_job_def file will have an extension of _mmddyy_hhmmss, where mmddyy is the month, day, and year, and hhmmss is hour, minute, and second.

The file will be renamed and ready for the future execution of the autoinstall.sh script for FTA fixpack installations.

Important: The autoinstall.sh script must not be used to create and add new job and job stream definitions until the current job stream with fixpacks installation jobs have been submitted and launched.


Figure 82 Delete patch_job_def file

Implementing procedures

The fixpack implementation cycle consists of:

� Specifying FTA(s) that need a fixpack� Submitting and launching of the fixpack launch job� Installation of the fixpack on spcified FTA workstations

New FTA fixpack definitions (new fixpack cycle) may be added once the job and jobs stream definitions from the current fixpack cycle have been added to the

Enter c, a, r, b or e -> r Will check for existence of patch_job_def_file in the/etc/TWS/MDM.m821a.m821a directory. File patch_job_def_file exists in the/etc/TWS/MDM.m821a.m821a directory and will be renamed

to include extension with current date and time in hour, minute and seconds. + mv /etc/TWS/MDM.m821a.m821a/patch_job_def /etc/TWS/MDM.m821a.m821a/patch_job_def_051507_183939

Job and Job Stream Utilities Menu To create job stream definitions enter (c). To add job and job stream defintions to the database enter (a). To rename patch_job_def defintion file enter (r). To go back to Main Utilities Menu enter (b). To exit utility enter (e). Enter c, a, r, b or e ->


Tivoli Workload Scheduler database and the patch_job_def file has been renamed.

The existing fixpack cycle includes submitting the job stream that includes the fixpack installation jobs and the launching of the fixpack installation jobs.

The autoinstall.sh fixpack utility script may be located in any directory. The file should be owned by root and must have execute permissions. Temporary files will be created in the /tmp directory. The temporary files generated by the script will have a .##### extension, where ##### is the process ID. All temporary created files will be removed when exiting the script normally.

The following procedures must be performed to install an FTA fixpack:

1. Verify that all FTAs that will be patched are linked, active, and have a current Symphony file.

2. Logon to the master workstation as root user.

3. Run the autoinstall.sh script to define new FTA.workstation definition files FTA Utilities Menu. (Not required if existing FTA.workstation definition files exist.)

4. Run the autoinstall.sh script to create FTA patch installation job definition from the patch option.

5. Run the autoinstall.sh script to export fixpack utility scripts to FTA workstations from the FTA Utilities Menu. (Not required if existing FTA workstations already have the fixpacks utility scripts. This step may be performed anytime prior to the launching of the fixpack installation job.)

6. Run the autoinstall.sh script to create the FTA fixpack installation job stream definitions from the Job and Job Stream Utilities Menu.

7. Verify that the patch_lau_sch_def and patch_succ_sch_def files in the /etc/TWS/MDM.masteruser.mastername directory were created and that the patch_lau_sch_def file includes the fixpack installation jobs for FTA(s).

8. Run the autoinstall.sh script to add FTA patch installation job and job stream definitions to the database from the Job and Job Stream Utilities Menu.

9. Run the autoinstall.sh script to rename the patch_job_def file from the Job and Job Stream Utilities Menu. This step may be performed anytime before the next fixpack installation cycle begins. We suggest that it be done at this time to prevent the combining of fixpacks from two cycles; this will cause the re-application of an existing fixpack.

Important: Because fixpack cycles can overlap, great care must be taken to make sure that definitions are not overwritten by the next fixpack cycle.


10.Determine when to submit fixpack installation job streams.

11.Logon to the master workstation as TWSuser or connect to Job Scheduling Console.

12.Submit the TWSPATCH_LAUNCH and TWSPATCH_SUCC job streams. This job streams will be scheduled for the master CPU. Refer to Example 10.

Example 10 Submit TWSPATCH_LAUNCH and TWSPATCH_SUCC job streams

Example: conman command from master%sbs TWSPATCH_LAUNCH

%sbs TWSPATCH_SUCC

13.Raise job stream TWSPATCH_LAUNCH limit from 0 to a non-zero number using JSC or conman when you are ready to initiate launching of fixpack installations. Refer to Example 11.

Example 11 Raise TWSPATCH_LAUNCH job stream limit

Example: conman command from master

%ads TWSPATCH_LAUNCH;limit=40

14.Raise job stream TWSPATCH_LAUNCH priority from 0 to GO using JSC or conman. Refer to Example 12.

Example 12


%ads TWSPATCH_LAUNCH;priority=go

15.Determine when the FTA is ready to launch the patch installation.

– All Tivoli Workload Scheduler jobs must have completed on FTA.

– FTA must be linked and have the current Symphony file.

– FTA must be active; limit may be set to 0 to prevent additional jobs from launching.

16.Raise FTA patch installation job priority from 0 to GO for TWSPATCH_LAUNCH.ftaname_twsversion#_FP_patch# using JSC or conman. Refer to Example 13.

Example 13 Raise job priority



%adj twspatch_launch.m82a_820_fp_10;priority=go

17.The fixpack installation job will verify job information, and if all of the information is correct, it will launch the patch_lau.sh script in the background prior to exiting successfully.

The fixpack installation job should only take a few minutes to run.

18.When the fixpack installation job completes, the job will be SUCC. Refer to Figure 83.

Figure 83 TWSPATCH_LAUNCH job stream successful jobs

When the fixpack installation job completes, it launches the patch_lau.sh script in the background which executes the twspatch installation script. The patch_lau.sh script, which stops Tivoli Workload Scheduler processes before launching the twspatch installation script, may take several minutes to complete, because Tivoli Workload Scheduler processes on FTA must be stopped before launching the twspatch installation script to perform the fixpack installation.

19.Issue a ps -ef |grep patch from the UNIX prompt on FTA to determine that Tivoli Workload Scheduler patch installation script is running.

The listing in Figure 84 shows the patch_lau.sh and the twspatch scripts running.

Figure 84 ps -ef |grep patch list

%sj(Est) (Est)CPU Schedule Job State Pr Start Elapse Dependencies Return Code M821A #TWSPATCH_LAUNCH *LIM 40* STUCK GO 17:02 (00:01) [Carry] (HORBLM82#)HORBLM82_820_FP_07 HOLD 0 (M82A#)M82A_820_FP_10 SUCC GO 13:02 00:01 #J27860 0

ps -ef |grep patchroot 27904 1 0 13:02:48 ? 0:00 /bin/sh -x /etc/TWS/patch_lau.shroot 28264 27179 0 13:04:25 pts/28 0:00 grep patchroot 27961 27904 0 13:04:02 ? 0:00 /bin/sh ./twspatch -install -uname m82a


20.When the fixpack installation completes successfully, a job will exist in the TWSPATCH_SUCC job stream on the master.

FTA installation job name with a _jobnumber_SUCC extension as the job name will exist in the TWSPATCH_SUCC job stream on the master. Refer to Figure 85.

Figure 85 Successful fixpack installation jobs

The jobnumber_SUCC text for the FTA fixpack launch will be added to the job name for the fixpack job that runs on the master.

Figure 86 Job stream status

The job that runs on the master is used to generate FTA fixpack installation record entry in the mdm_mastername_fixpack.log file in the /etc/TWS directory, where the mastername is the name of the master that manages the FTA. Refer to Figure 87.

M821A #TWSPATCH_SUCC *************************** SUCC 10 13:05 00:01 [Carry]

M82A_820_FP_10_27860_SUCC SUCC 10 13:05 00:01 #J28449 0

%sj(Est) (Est)CPU Schedule Job State Pr Start Elapse Dependencies Return CodeM821A #TWSPATCH_LAUNCH *LIM 40* STUCK GO 17:02 (00:01) [Carry]

(M82A#)M82A_820_FP_10 SUCC GO 13:02 00:01 #J27860 0M821A #TWSPATCH_SUCC **************************************** SUCC 10 13:05 00:01 [Carry] M82A_820_FP_10_27860_SUCC SUCC 10 13:05 00:01 #J28449 0


Figure 87 The mdm.mastername_fixpack.log file

The mdm.mastername_fixpack.log file will have a record that shows FTA name, Tivoli Workload Scheduler version, fixpack number, fixpack installation job number, and date when the fixpack was installed on the FTA. Refer to Figure 88.

Figure 88 FTA fixpack installation log record

Additionally after a successful installation of the fixpack, the FTA will be restarted. It will be in a “BATCHMAN LIVES” state and have a job limit of “0”.

21.Raise the job limit to proceed to the normal Tivoli Workload Scheduler launching of jobs on FTA.

22.Review the Tivoli Workload Scheduler job stdlist for the fixpack installation job if the job abends.

The twspatch installation errors will be written to the normal fixpack log. The patch_lau.sh background script will log messages to the fp_fp##_jobnum.stdlog file in the /tmp directory. Refer to Example 14.

Example 14

Example: FTA fixpack install of fixpack 10 that had job number 27860 will create the log:

fp_10_27860.stdlog

$ pwd/etc/TWS$ lltotal 160drwxrwxr-x 2 root sys 96 May 14 20:03 APPL.twsdrwxrwxr-x 2 root sys 8192 May 15 18:39 MDM.m821a.m821a-rw-rw-r-- 1 root sys 5422 May 8 11:49 TWSRegistry.datdrwxrwxr-x 2 root sys 96 Feb 26 16:16 appl.tws-rw-rw-rw- 1 root sys 68 May 7 13:30 mdm_m821a_fixpack.log-rwxr-xr-x 1 root sys 20312 May 14 20:03 patch_install.sh-rwxr-xr-x 1 root sys 6459 May 14 20:03 patch_lau.shdrwxrwxr-x 2 root sys 8192 Jan 29 12:01 patchutils

$ more mdm_m821a_fixpack.log HORBLM82_820_FP_07_10479_SUCC completed Mon May 7 11:20:52 CDT 2007


23.You can rerun abended fixpack installation jobs after making changes.

Troubleshooting

The creation of the autoinstall.sh patch_install.sh and patch_lau.sh scripts included testing on AIX, HPUX, Linux_i386 and Solaris platforms, and using techniques that worked on these platforms and should not be customized or edited unless suggested by Tivoli Workload Scheduler Level 2 support.

Before proceeding to troubleshoot problems with the autoinstall.sh script, please review the following checklist to verify that suggested requirements have been implemented. Refer to Figure 89.

Note: Reruns of patch installation jobs will run immediately unless priority is lowered from GO to 0.


Figure 89 Pre-troubleshooting checklist

� The Autoinstall.sh script runs on the master only.

� The /etc/TWS/APPL.TWS directory must exist for the Tivoli Workload Scheduler patch or new installations.

� The utility scripts will be located on FTAs in the /etc/TWS directory.

� The utility scripts repository on the master will be located in the /etc/TWS/APPS.tws directory and be executable.

� The utility scripts patch_install.sh and patch_lau.sh must be copied from the repository on the master (/etc/TWS/APPS.tws directory) to the /etc/TWS directory on FTA.

� If the master and FTA exist on the same workstation/node then the utility scripts must exist in both directories.

� The root user on FTA must be able to submit ad-hoc jobs to the master as root.

� The TWSRegistry.dat must be correct and up to date.

� The .profile for the twsuser must have the TWSHome and TWSHome/bin directory in PATH variable for the master and FTA. You should be able to invoke TWS commands without having to specify the path.

� The Master and FTA workstation must have a valid Symphony file.

� The Master workstation must currently be linked to the FTA that will be patched.

� Root must be able to access Tivoli Workload Scheduler files and databases and exist in the Tivoli Workload Scheduler Security file.

� The patch utility script will only patch AIX, HPUX, Linux_i386 and Solaris UNIX FTAs.

� The patch utility script uses Tivoli Workload Scheduler cpuinfo to validate the master and FTA CPUs.

� The “master=” field in TWSHome/mozart/globalopts file must be valid and correct on the master workstation.

� The “thiscpu=” field in TWSHome/localopts file must be valid and correct on FTA workstation. User validation issues may occur if value is not correct.

� Ideally the patches path should be an NFS mounted filesystem which is mounted on all FTAs that will be patched using the above naming convention.

� The patch directory should have a common base path followed by TWSversion/OS (/patchesbasepath/twsversion/os).


Fixpack logsThe autoinstall.sh generates a few logs. The fixpack job execution which executes the patch_install.sh script will write output to the Tivoli Workload Scheduler job stdlist. The patch_lau.sh script includes tasks which are flagged when completed. The patch_lau.sh writes the ftaname_fp_fp##_jobnum.stdlog file in the /tmp directory. This file may be reviewed to determine the point of failure if the Tivoli Workload Scheduler job abends. These files/logs will be covered in more detail in the following sections.

When the fixpack installation completes successfully, a job will exist in the TWSPATCH_SUCC job stream on the master.

The job that runs on the master is used to generate FTA fixpack installation record entry in the mdm_mastername_fixpack.log file in the /etc/TWS directory, where mastername is the name of the master that manages the FTA. Refer to Figure 90.

Figure 90 The mdm.mastername_fixpack.log file

The mdm.mastername_fixpack.log file will have a record that shows FTA name, TWS version, fixpack number, fixpack installation job number, and date when the fixpack was installed on the FTA. Refer to Figure 91.

Figure 91 FTA fixpack installation log record

$ pwd/etc/TWS$ lltotal 160drwxrwxr-x 2 root sys 96 May 14 20:03 APPL.twsdrwxrwxr-x 2 root sys 8192 May 15 18:39 MDM.m821a.m821a-rw-rw-r-- 1 root sys 5422 May 8 11:49 TWSRegistry.datdrwxrwxr-x 2 root sys 96 Feb 26 16:16 appl.tws-rw-rw-rw- 1 root sys 68 May 7 13:30 mdm_m821a_fixpack.log-rwxr-xr-x 1 root sys 20312 May 14 20:03 patch_install.sh-rwxr-xr-x 1 root sys 6459 May 14 20:03 patch_lau.shdrwxrwxr-x 2 root sys 8192 Jan 29 12:01 patchutils

$ more mdm_m821a_fixpack.log HORBLM82_820_FP_07_10479_SUCC completed Mon May 7 11:20:52 CDT 2007


Autoinstall.sh script

The script may be edited by the user to troubleshoot errors. The autoinstall.sh script has an option that places it in a debug mode. This option should be implemented if problems occur with the script. Using the debug option will produce a more verbose mode execution. The output error should be sent to Tivoli Workload Scheduler Level 2 for analysis.

Implementing autoinstall.sh in debug modeTo place the autoinstall.sh script in a debug mode, edit the autoinstall.sh script and proceed to the “Debug Mode Option” section of the script and change DEBUG= ““ option to DEBUG=y.

1. Edit the autoinstall.sh script and change DEBUG= ““ to DEBUG=“y“. Refer to Figure 92.

Figure 92 Debug mode option

2. As root user, invoke the UNIX “script -a” command and redirect the output to a file called /tmp/autoinstall.log. Refer to Example 15.

Example 15 Script command syntax

Example:script -a /tmp/autoinstall.log

3. Repeat the steps that produced the error.

4. Enter <ctrl> d to terminate the “script” command.

5. Review and send the /tmp/autoinstall.log to Tivoli Workload Scheduler Level 2 support for analysis.

Patch_install.sh and patch_lau.sh scripts

The fixpack job executes the patch_install.sh script. The patch_install.sh script requires four options, -uname, -patchdir, -version, and –patch, to exist before executing the patch_lau.sh script, which initiates the twspatch fixpack installation script.

#Debug Mode Option#To place in debug mode set DEBUG to yDEBUG="";export DEBUGSETVAR="vx";export SETVAR


Because the fixpack job is launched by Tivoli Workload Scheduler, the job stdlist will log all output of the patch_install.sh script. Review the Tivoli Workload Scheduler job stdlist for the fixpack job if job abends. The patch_install.sh script will show which tasks have been completed. Review the job stdlist to determine the task that is having problems. Example 16 is the tail end of the fixpack job stdlist and shows the various tasks and their results. The script is written to display a status of all completed tasks. If the job abends, reviewing the job stdlist will assist in determining that last completed step.

Example 16

Fixpack install job stdlist

Logon as root [passed]Valid OS [passed]Options used [passed]-uname option exists [passed]-patchdir option exists [passed]-patch option exists [passed]-version option exists [passed]Two digit patch format x.x [passed]Three digit version format x.x.x [passed]Valid TWS versions 8.2.0 8.2.1 8.3.0 8.4.0 [passed]Valid user specified [passed]Valid patch path specified [passed]Twspatch file exists [passed]Patch tar file exists [N/A]Change to patch directory [passed]Existence of patch files [passed]Display TWS binaries being accessed [passed]Check for existence of patch launch script [passed]/etc/TWS/patch_lau.shCheck for existence of TWS patch log [passed]directory /tmpPatch install logs will default to:/tmp directoryF1le m82a_fp_10_27860.stdlog in /tmp directorywill have log information.Launch patch launch script [launching]AWSBIS308I End of Job================================================================ Exit Status : 0= System Time (Seconds) : 1 Elapsed Time (Minutes) : 0= User Time (Seconds) : 0= Mon 01/29/07 12:35:09 CST


The successful completion of the fixpack job (patch_install.sh script) will launch the patch_lau.sh script. The patch_lau.sh script will log which tasks have been completed.log to the ftaname_fp_fp##_jobnum.stdlog file in the /tmp directory. This file logs all procedures prior to execution of the twspatch installation script. Once the twspatch installation script launches, the fixpack install will write, to the log specified, the fixpack README file. Refer to Example 17.

Example 17

Example: FTA m82a fixpack install of fixpack 10 that had job number 27860 will create the log:

m82a_fp_10_27860.stdlog

A successful completion of the patch_lau.sh and twspatch fixpack installation script will restart the FTA and issue a SUCC job on the master for FTA. The log file ftaname_fp_fp##_jobnum.stdlog will show the status of all tasks performed. Refer to Figure 93.

Figure 93 Patch_lau.sh log file

Review the log file ftaname_fp_fp##_jobnum.stdlog, if problems exist. You should be able to determine if the problem was in the patch_lau.sh script or if failure was with the twspatch installation script. Twspatch fixpack installation errors will be written to the log file specified in the fixpack README file.

tail -15 /tmp/m82a_fp_10_27860.stdlogExtract TWS shortname [DONE]Change to TWS instance home directory [DONE]Stop and shut TWS processes [DONE]Terminate processes accessing TWS binaries [DONE]Display TWS binaries should not show active [DONE]Change to directory where twspatch exists [DONE]Display current path [DONE]Execute the twspatch install [DONE]Twspatch install [SUCC]FTA start and limit 0 command executed [DONE]Does SUCC patch schedule exist on Master [YES]Patch SUCC job sent to SUCC schedule [YES]Patch SUCC job sent to JOBS schedule [N/A]Exit script [YES]


Common issues

Here are some of the common issues when using this solution:

� TWSPATCH_LAUNCH job is SUCC, but TWSPATCH_SUCC job does not show up:

– Action:

Review the /tmp/ftaname_fp_##_######.stdlog file for logging of steps.

Where:

ftaname = name of FTA that was patched

## = two digit fix pack number

##### = job number of patch installation launch

– If patch job launch is:

M82A#M82A_820_FP_10 SUCC GO 13:02 00:01 #J27860

Then, review log /tmp/m82a_fp_10_27860.stdlog

– Possible causes:

Root user is not allowed to submit ad-hoc jobs to the master.

� Utility is unable to validate FTA user

– Action:

Review the "thiscpu" variable for FTA localopts file.

– Possible causes:

The value in "thiscpu" does not match the name of the defined FTA on the master.

Configuring OPENSSH

SSH can be used instead of telnet to provide an authenticated and encrypted connection to remote computers. SSH can be configured to make connections without needing to provide a password on the remote workstation.

This section will explain how to configure SSH so that connections to remote workstations, will not require passwords. SSH must be installed and enabled on local and remote workstation before it can be used.


Please consult your System Administrator for assistance with installation and enabling SSH on the workstations and before performing the following procedures.

1. Logon as the user that will be connecting to the remote workstation as the same user. Example: Logon as larry

2. Verify that SSH is working by connecting to the remote_workstation.domain.com as user "larry" by issuing the following:

ssh larry@remote_workstation.domain.com

SSH will ask if you want to keep connecting. Type yes, prompt for password, and open a shell in larry's home directory on remote_workstation.domain.com, just like a telnet session. If this fails, a problem exists somewhere. Verify that SSH is installed on the local workstation and verify that remote_workstation.domain.com is accepting SSH connections.

3. Close the remote connection by typing exit.

4. Create the .ssh directory on local workstation in the user's home directory (if the directory does not exist).

mkdir .ssh

5. Change to the .ssh directory. Generated private and public SSH keys will be created and placed in this directory.

cd .ssh

6. Create private and public key pairs so that providing passwords will be not necessary. The following command will create the id_dsa (private) and id_dsa.pub (public) key files.

ssh-keygen -t dsa

The ssh-keygen program might prompt for the name of key files; depress Enter to accept the default id_dsa file name. The program will then prompt for a passphrase; depress the Enter key unless you want to enter a passphrase. The program will prompt you to confirm the passphrase; depress the Enter key or enter passphrase. The above command creates the keys id_dsa and id_dsa.pub and puts them in the .ssh directory.

Note: Use Windows® Explorer to create the .ssh directory on Windows workstations.


Figure 94 The ssh-keygen display and prompts

7. The private key id_dsa must be readable only by the user that created the files. Change permissions of the id_dsa file.

chmod 600 id_dsa

8. Place a copy of the public key on the remote workstation. The remote workstation should also be running OpenSSH. You can transfer the id_dsa.pub key to the remote workstation, either by e-mail, ftp, or scp, which is included with SSH. The following example uses scp to copy file from local workstation to the remote workstation.

scp .ssh/id_dsa.pub pete@remote_workstation.domain.com:

You will be prompted for pete's password on the remote workstation before copying begins. The id_dsa.pub file will be copied to pete's home directory on the remote workstation.

Copy the public key on the remote workstation to the user's home directory that will receive the connection from the source system.

9. On remote workstation, in local home directory the id_dsa.pub should be placed in the .ssh directory. Create the .ssh directory if it does not exist.

10.Move the id_dsa.pub file to the .ssh directory.

11.Make a backup copy of the authorized_keys file if it exists.

cp authorized_keys authorized_keys.orig

12.Append the contents of the id_dsa.pub file to the authorized_keys file.

Generating public/private dsa key pair.Enter file in which to save the key (/home/larry/.ssh/id_dsaEnter passphrase (empty for no passphrase):Enter same passphrase again:Your identification has been saved in /home/larry/.ssh/id_dsa.Your public key has been saved in /home/larry/.ssh/id_dsa.pub.The key fingerprint is:09:28:f3:d3:8d:15:d3:8d:c9:67:84:2a:12:51:f6:26 larry@TREK

Note: Existing keys id_dsa and id_dsa.pub in the .ssh directory will be overwritten if they already exist. The user will be prompted before they are overwritten.

Note: Include the trailing colon ":".


13.The .ssh folder on the remote workstation must have the correct permissions; you may set them with chmod:

chmod 700 .ssh

14.Verify the password-less connection, from the original workstation, initiate a connection to the remote workstation as the specified user.

ssh larry@remote_workstation.domain.com

15.Close the remote connection by typing exit.

Authorized_keys fileTo view the defined users and workstation that are permitted to connect to the current workstation, without providing a password that exists in the authorized_keys file, execute the following command from .ssh directory:

more authorized_keys|grep "="|cut -f2-3 -d "="|tr -d "^="|tr -d "^ "

The sample output (Figure 95) from the above command on workstation taos means that the root user from testmaster.ibm.com and larry from TREK are permitted to connect without providing a password.

Figure 95 Defined users in authorized_keys file for taos workstation

The sample output (Figure 96) from the above command on the workstation testmaster means that the root user from taos.ibm.com is allowed to connect without providing a password.

Figure 96 Defined users in authorized_keys file for testmaster workstation

Know_hosts fileAn additional file, know_hosts, may exist in the .ssh directory. This file contains the remote host names that this workstation has connected to.

Note: A password-less connection to remote_workstation.domain.com will be established. The use of scp will not require a password either.

Warning: On the local workstation do not remove the id_dsa file, as the id_dsa.pub may be removed.

[email protected]@TREK

[email protected]


Every time you connect to a machine, SSH stores the remote machine's public key (for public key encryption) in a configuration file (unless you chose to continue connecting without adding the host to the known hosts list).

It uses this information to verify that you are connecting to the workstation you thought you were connecting to. This warning means that the host you were trying to connect to was not in your database, and so SSH could not verify that it was the right host. This will be the case if it is the first time you use SSH to connect to a remote workstation from a local workstation

Connect, let SSH add the host to your list, and you should not see the warning next time you connect to that host.


© Copyright International Business Machines Corporation 2007. All rights reserved.

Notices

This information was developed for products and services offered in the U.S.A.

IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.

The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you.

This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice.

Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk.

IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you.

Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products.

This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental.

COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrates programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing application programs conforming to IBM's application programming interfaces.

Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. 83

®

Redpaper

Send us your comments in one of the following ways:� Use the online Contact us review Redbooks form found at:

ibm.com/redbooks� Send your comments in an email to:

[email protected]� Mail your comments to:

IBM Corporation, International Technical Support OrganizationDept. HYTD Mail Station P099, 2455 South RoadPoughkeepsie, NY 12601-5400 U.S.A.

Trademarks

The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both:

AIX®IBM®

Redbooks (logo) ®Tivoli®

The following terms are trademarks of other companies:

Solaris, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries.

Other company, product, or service names may be trademarks or service marks of others.



http://www.ibm.com/redbooks/

http://www.ibm.com/redbooks/

http://www.redbooks.ibm.com/contacts.html

Autoinstall.sh utility script redp4296

Technology

Transcript of Autoinstall.sh utility script redp4296