Redpaper
Pete Soto
Vasfi Gucer
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
© Copyright IBM Corp. 2007. All rights reserved.
ibm.com/redbooks
1
maintain FTA workstations that are current on maintenance fixpacks. This is
accomplished by automating and monitoring UNIX FTA fixpack installations from
a central location.
Note: Lowercase should be used for all inputs, except for passwords,
because they are case sensitive.
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.
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
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.
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.
4
Autoinstall.sh Utility Script
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/patches
twsverison = 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
Autoinstall.sh Utility Script
5
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.
Note: Because each fixpack includes all fixes for previous fixpacks, entering
multiple fixpacks for the same FTA workstation is not required.
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.
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.
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.
6
Autoinstall.sh Utility Script
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.
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 patched
twsver is the TWS version
xx is fixpack number (2 digit format)
jobnum is the job number of FTA fixpack install job
Example: 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.
Autoinstall.sh Utility Script
7
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.
8
Autoinstall.sh Utility Script
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.
Autoinstall.sh Utility Script
9
Current system OS is HPUX
The current process id is 18671, Temporary created files will
be created in the /tmp directory and have a .18671 extension.
No existing MDM definition file exists
You will need to create a mdm definition file.
This is a list of defined MDM users in the TWSRegistry.dat file
for this workstation.
m821a
m83rtm
Enter TWS User for master cpu or press enter to obtain a list of
MDM users listed in the TWSRegistry.dat file ->
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.
10
Autoinstall.sh Utility Script
Enter TWS User for master cpu or press enter to obtain a list of
MDM 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 m821a
on 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 exists
Will 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 will
be 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 ->
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.
Autoinstall.sh Utility Script
11
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.
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 3 FTA patch installation prompt
Pressing <Enter> will display all workstations that exist on the current master.
Refer to Figure 4.
Note: Only UNIX FTA workstations may be patched.
Enter a valid FTA workstation name to patch. 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
HORBLM82
M82A
XA-FUEGO
M821A
HORBLM82
M82A
M82A
AF T
A AT
AFAT
A AT
38211
31822
31822
31822
taos
testmaster
taos
fuego.tivlab.austin.ibm.com
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 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.
12
Autoinstall.sh Utility Script
Enter a valid FTA workstation name to patch. 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 taos
is 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 on
master m821a exists.
Will need to create information file for m82a:
/etc/TWS/MDM.m821a.m821a/FTA.m82a
since the above file does not exist.
Additional information is required for TWS workstation m82a.
Enter the TWS user for workstation m82a (node/ip taos) or
press enter to obtain list of TWS users on node/ip taos. ->
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.
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 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.
Autoinstall.sh Utility Script
13
Enter the TWS user for workstation m82a (node/ip taos) or
press 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 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.
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:
fta2nd83
fta83rtm
m82a
m82b
mae001
The above is a list of TWS users for FTA workstations
listed in the TWSRegistry.dat file on node/ip taos.
You will need to specify the correct TWS user for TWS
workstation m82a.
Enter the TWS user for workstation m82a (node/ip taos) or
press enter to obtain list of TWS users on node/ip taos.
->
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
14
Autoinstall.sh Utility Script
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
Enter the TWS user for workstation m82a (node/ip taos) or
press enter to obtain list of TWS users on node/ip taos.
-> pete
/localopts: No such file or directory
The 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 pete
or n to specify another user ->
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.
Autoinstall.sh Utility Script
15
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.2
Will 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 / ->
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).
Note: The base path provided must be valid, because it will be used to
determine the fixpack directory path.
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/patches
twsverison = is 8.3.0 (use 3 digit format)
os = aix (aix, hpux,linux_i386 or solaris
16
Autoinstall.sh Utility Script
/images/patches/8.2.0/hpux
You may need to provide the root password for taos.
Password:
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.
Path /images/patches/8.2.0/hpux exists
Enter y, to use this path or enter n to specify another path.
->
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.
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 taos
basic 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 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.
Autoinstall.sh Utility Script
17
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.
Provide TWS 8.2.0 patch level to install, in ## format ie.. 01, 02,
03 …
Enter TWS patch level of patch -> 10
Level entered is 10
10
TWS patch level 10 will be verified.
Base patch path is /images/patches/8.2.0/hpux. Will verify
that patch files exist in /images/patches/8.2.0/hpux/fp10
directory.
You may need to provide root password for node/ip taos
Password:
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.
18
Autoinstall.sh Utility Script
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 currently
installed on workstation.
Do you want to use the specified information? (Enter y or n) ->
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.
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 created
in 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) ->
Figure 16 Apply fixpack to another FTA prompt
Autoinstall.sh Utility Script
19
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.
Enter p, b or e) -> e
Will exit patch FTA mode.
The current process id is 28525, removing all temporary
files with .28525 extension in the /tmp directory.
Exiting ./autoinstall.sh 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.
Note: Using a different MDM definition is only possible if the current
workstation has multiple master instances.
Current system OS is HPUX
The current process id is 20511, Temporary created files will
be created in the /tmp directory and have a .20511 extension.
Found an existing MDM definition for m821a user on master
cpu m821a on this workstation, ok to use? (Enter y or n) ->
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.
20
Autoinstall.sh Utility Script
Found an existing MDM definition for m821a user on master
cpu 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 file
for this workstation.
m821a
m83rtm
Enter TWS User for master cpu or press enter to obtain a list of
MDM users listed in the TWSRegistry.dat file ->
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.
Found an existing MDM definition for m821a user on master
cpu m821a on this workstation, ok to use? (Enter y or n) -> y
Existing TWS user m821a for master
cpu m821a on this workstation will be used.
This is a list of defined MDM users in the TWSRegistry.dat file
for this workstation.
m821a
m83rtm
drwxrwxr-x
2 root
/etc/TWS/APPL.tws
sys
96 Feb 20 16:15
Found the tws application definition on this
workstation, ok to use? (Enter y or n) ->
Figure 20 Use APPL.tws definition prompt
2. Reply to the prompt asking to use the existing APPL.tws application.
Autoinstall.sh Utility Script
21
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.
Found the tws application definition on this
workstation, ok to use? (Enter y or n) -> n
You will need to create a APPL definition.
Enter name for application ->
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.
22
Autoinstall.sh Utility Script
Found the tws application definition on this
workstation, ok to use? (Enter y or n) -> y
Application tws definition for master cpu m821a
on this workstation will be used to schedule install.
Application tws will be used.
logout
The current process id is 20511, Temporary created files will
be 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 ->
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.
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 23 FTA patch installation prompt
Pressing <Enter> will display all of the workstations that exist on the current
master. Refer to Figure 24.
Autoinstall.sh Utility Script
23
Note: Only UNIX FTA workstations may be patched.
Enter a valid FTA workstation name to patch. 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
HORBLM82
M82A
XA-FUEGO
M821A
HORBLM82
M82A
M82A
AF T
A AT
AFAT
A AT
38211
31822
31822
31822
taos
testmaster
taos
fuego.tivlab.austin.ibm.com
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.
24
Autoinstall.sh Utility Script
Enter a valid FTA workstation name to patch. 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 taos
is 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 on
master m821a exists.
Will need to create information file for m82a:
/etc/TWS/MDM.m821a.m821a/FTA.m82a
since the above file does not exist.
Additional information is required for TWS workstation m82a.
Enter the TWS user for workstation m82a (node/ip taos) or
press enter to obtain list of TWS users on node/ip taos.
->
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.
Autoinstall.sh Utility Script
25
Enter the TWS user for workstation m82a (node/ip taos) or
press 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:
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.
Enter the TWS user for workstation m82a (node/ip taos) or
press 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 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.
26
Autoinstall.sh Utility Script
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:
fta2nd83
fta83rtm
m82a
m82b
mae001
The above is a list of TWS users for FTA workstations
listed in the TWSRegistry.dat file on node/ip taos.
You will need to specify the correct TWS user for TWS
workstation m82a.
Enter the TWS user for workstation m82a (node/ip taos) or
press enter to obtain list of TWS users on node/ip taos.
->
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
Autoinstall.sh Utility Script
27
Enter the TWS user for workstation m82a (node/ip taos) or
press enter to obtain list of TWS users on node/ip taos.
-> test
Warning: Unable to validate user. Enter y to use user test
or n to specify another user ->
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.
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.2
Will 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 / ->
Figure 30 Validate user and prompt for fixpack base path
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
28
Autoinstall.sh Utility Script
/images/patches/8.3.0/aix
Where:
patchesbasepath = /images/patches
twsverison = 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).
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:
Figure 31 Password prompt
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.
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 32 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 33.
Autoinstall.sh Utility Script
29
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 taos
basic 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 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.
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.
Because each fixpack includes all fixes for previous fixpacks, entering
multiple fixpacks for the same FTA workstation is not required.
30
Autoinstall.sh Utility Script
Provide TWS 8.2.0 patch level to install, in ## format ie.. 01, 02,
03 …
Enter TWS patch level -> 10
Level entered is 10
10
TWS patch level 10 will be verified.
Base patch path is /images/patches/8.2.0/hpux. Will verify
that patch files exist in /images/patches/8.2.0/hpux/fp10
directory. You may need to provide root password for node/ip taos
Password:
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.
Base patch path is /images/patches/8.2.0/hpux. Will verify
that patch files exist in /images/patches/8.2.0/hpux/fp10
directory. 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 currently
installed on workstation.
Do you want to use the specified information? (Enter y or n) ->
Figure 35 Fixpack installation confirmation
Autoinstall.sh Utility Script
31
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.
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 created
in 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) ->
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.
Enter p, b or e) -> e
Will exit patch FTA mode.
The current process id is 28525, removing all temporary
files with .28525 extension in the /tmp directory.
Exiting ./autoinstall.sh script.
Figure 37 Exit autoinstall.sh script
32
Autoinstall.sh Utility 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.
Current system OS is HPUX
The current process id is 18671, Temporary created files will
be created in the /tmp directory and have a .18671 extension.
Found an existing MDM definition for m821a user on master
cpu m821a on this workstation, ok to use? (Enter y or n) ->
Figure 38 Use existing MDM definition
2. Reply “n” to the prompt asking to use the APPL.tws application definition.
Refer to Figure 39.
Autoinstall.sh Utility Script
33
Found an existing MDM definition for m821a user on master
cpu m821a on this workstation, ok to use? (Enter y or n) -> y
Existing TWS user m821a for master
cpu m821a on this workstation will be used.
This is a list of defined MDM users in the TWSRegistry.dat file
for this workstation.
m821a
m83rtm
drwxrwxr-x
2 root
/etc/TWS/APPL.tws
sys
96 Feb 20 16:15
Found the tws application definition on this
workstation, ok to use? (Enter y or n) ->
Figure 39 Use APPL.tws definition prompt
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.
Found the tws application definition on this
workstation, ok to use? (Enter y or n) -> n
You will need to create a APPL definition.
Enter name for application ->
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.
34
Autoinstall.sh Utility Script
Enter name for application -> test
You specified test definition is this correct. (y or n) ->
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.
You specified test definition is this correct. (y or n) -> y
APPL.test directory will be created on this
workstation 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 temporary
files with .12365 extension in the /tmp directory.
Exiting ./autoinstall.sh script.
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.
Autoinstall.sh Utility Script
35
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.
Note: Using a different MDM definition is only possible if the current
workstation has multiple master instances.
Current system OS is HPUX
The current process id is 20511, Temporary created files will
be created in the /tmp directory and have a .20511 extension.
Found an existing MDM definition for m821a user on master
cpu m821a on this workstation, ok to use? (Enter y or n) ->
Figure 43 Use existing MDM definition
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.
36
Autoinstall.sh Utility Script
Found an existing MDM definition for m821a user on master
cpu m821a on this workstation, ok to use? (Enter y or n) -> y
Existing TWS user m821a for master
cpu m821a on this workstation will be used.
This is a list of defined MDM users in the TWSRegistry.dat file
for this workstation.
m821a
m83rtm
drwxrwxr-x
2 root
/etc/TWS/APPL.tws
sys
96 Feb 20 16:15
Found the tws application definition on this
workstation, ok to use? (Enter y or n) ->
Figure 44 Use APPL.tws definition prompt
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.
Autoinstall.sh Utility Script
37
Found the tws application definition on this
workstation, ok to use? (Enter y or n) -> y
Application tws definition for master cpu m821a
on this workstation will be used to schedule install.
Application tws will be used.
logout
The current process id is 20511, Temporary created files will
be 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 ->
Figure 45 Prompt for patch or utilities operations
3. Reply “u” to proceed to the Main Utilities Menu. Refer to Figure 46.
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 46 FTA utilities menus
4. For FTA maintenance tasks, reply f to perform FTA maintenance tasks.
38
Autoinstall.sh Utility Script
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 ->
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 File
i. At the FTA Utilities Menu screen, reply a to add or update an FTA
definition file. Refer to Figure 48.
Enter a, d, x, b or e -> a
FTA to be added or updated must be exist in current Symphony file
and linked before executing utility.
Press enter l to get a list of FTA files that may be updated or
any other key to bypass list. ->
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.
Autoinstall.sh Utility Script
39
Pressing any other key will bypass this operation.
ii. Press either “l” or any key to continue. Refer to Figure 49.
Press enter l to get a list of FTA files that may be updated or
any 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. ->
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.
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
HORBLM82
M82A
XA-FUEGO
M821A
HORBLM82
M82A
M82A
AF T
A AT
AFAT
A AT
38211
31822
31822
31822
taos
testmaster
taos
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. ->
Figure 50 Workstation list from the master Symphony file
40
Autoinstall.sh Utility Script
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 Definition
Press <Enter> to display a current list of workstations in the master
Symphony file.
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.
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.
Autoinstall.sh Utility Script
41
Input value is HORBLM82.
TWS workstation HORBLM82 on node/ip testmaster
is 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 on
master m821a exists.
Will need to create information file for horblm82:
/etc/TWS/MDM.m821a.m821a/FTA.horblm82
since the above file does not exist.
Additional information is required for TWS workstation horblm82.
Enter the TWS user for workstation horblm82 (node/ip testmaster) or
press enter to obtain list of TWS users on node/ip testmaster.
->
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.
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.
42
Autoinstall.sh Utility Script
Enter the TWS user for workstation horblm82 (node/ip testmaster) or
press 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:
e82pdm
f821
The above is a list of TWS users for FTA workstations
listed in the TWSRegistry.dat file on node/ip testmaster.
You will need to specify the correct TWS user for TWS
workstation horblm82.
Enter the TWS user for workstation horblm82 (node/ip testmaster) or
press enter to obtain list of TWS users on node/ip testmaster.
->
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.
Enter the TWS user for workstation horblm82 (node/ip testmaster) or
press 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 testmaster
more than once.
Password:
Figure 53 FTA TWS user prompt and root password prompt
Autoinstall.sh Utility Script
43
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.
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.2
Will 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 / ->
Figure 54 Validate user and prompt for fixpack base path
Example 8 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
/images/patches/8.3.0/aix
Where:
patchesbasepath = /images/patches
twsverison = 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).
44
Autoinstall.sh Utility Script
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
You may need to provide the root password for taos.
Password:
Figure 55 Password prompt
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.
Because each fixpack includes all fixes for previous fixpacks, entering
multiple fixpacks for the same FTA workstation is not required.
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.
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 56 Fixpack path validation and prompt
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.
Autoinstall.sh Utility Script
45
Enter y, to use this path or enter n to specify another path.
-> y
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 ->
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.
Enter a, b or e to exit -> e
The current process id is 28800, removing all temporary
files with .28800 extension in the /tmp directory.
Exiting ./autoinstall.sh script.
Figure 58 Exit script
Update an Existing FTA.workstation File
Press <Enter> to display a current list of workstations in the master
Symphony file.
46
Autoinstall.sh Utility Script
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.
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.
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 taos
is 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 on
master m821a exists.
Information for m82a exists in file
/etc/TWS/MDM.m821a.m821a/FTA.m82a
Basic information for FTA m82a:
CPUNAME=m82a
NODENAME_IP=taos
TWSUSER=m82a
VERSION=8.2.0
OS=HPUX
BASEPATCHPATH=/images/patches/8.2.0/hpux
Do you want to use above information? (Enter y or n) ->
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.
Autoinstall.sh Utility Script
47
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) or
press enter to obtain list of TWS users on node/ip taos.
->
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.
48
Autoinstall.sh Utility Script
Enter the TWS user for workstation m82a (node/ip taos) or
press 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:
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.2
Will 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 / ->
Figure 61 Validate user and prompt for fixpack base path
iv. Provide the fixpack base path for FTA (see base path requirements in
Example 9).
Example 9 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
/images/patches/8.3.0/aix
Autoinstall.sh Utility Script
49
Where:
patchesbasepath = /images/patches
twsverison = is 8.3.0 (use 3 digit format)
os = aix (aix, hpux,linux_i386 or solaris)
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:
Figure 62 Password prompt
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.
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.
Path /images/patches/8.2.0/hpux exists
Enter y, to use this path or enter n to specify another path.
->
Figure 63 Fixpack path validation and prompt
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.
50
Autoinstall.sh Utility Script
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 taos
basic 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 ->
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.
Enter a, b or e to exit -> e
The current process id is 28800, removing all temporary
files with .28800 extension in the /tmp directory.
Exiting ./autoinstall.sh script.
Figure 65 Exit script
Delete an FTA file
i. At the FTA Utilities Menu screen, enter d to delete an FTA.workstation
file. Refer to Figure 66.
Autoinstall.sh Utility Script
51
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. ->
Figure 66 FTA Utilities menu
ii. Press <Enter> to get a list of the defined FTA.workstation files. Refer to
Figure 67.
Enter name of FTA file to delete, press enter to get a list
of 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 list
of FTA files or e to exit utility. ->
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.
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) ->
Figure 68 FTA name to delete
52
Autoinstall.sh Utility Script
Note: Do not use “*” asterisk in the FTA name.
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.
Do you want to delete the FTA file? (Enter y, n or e to exit) -> y
File /etc/TWS/MDM.m821a.m821a/FTA.horblm82
exists 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 69 FTA delete confirmation
v. Reply to the prompt.
Export Utility Scripts to FTA
i. At the FTA Utilities Menu screen, enter x to export the utility scripts to
FTA. Refer to Figure 70.
Autoinstall.sh Utility Script
53
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. ->
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.
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.
Pressing <Enter> will display list of all workstations that exist on the
current master’s Symphony file. Refer to Figure 71.
54
Autoinstall.sh Utility Script
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
HORBLM82
M82A
XA-FUEGO
M821A
HORBLM82
M82A
M82A
AF T
A AT
AFAT
A AT
38211
31822
31822
31822
taos
testmaster
taos
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. ->
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.
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.com
is 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 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.
Autoinstall.sh Utility Script
55
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 taos
is 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 taos
more that once.
Will attempt to transfer files to FTA m82a on node/ip taos.
Password:
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.
56
Autoinstall.sh Utility Script
Will attempt to transfer files to FTA m82a on node/ip taos.
Password:
patch_lau.sh
Password:
patch_install.sh
100% 6243
0.0KB/s
00:00
100%
0.0KB/s
00:00
19KB
Review the above scp messages and verify that secure copies
were 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 ->
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.
Autoinstall.sh Utility Script
57
Current system OS is HPUX
The current process id is 20511, Temporary created files will
be created in the /tmp directory and have a .20511 extension.
Found an existing MDM definition for m821a user on master
cpu m821a on this workstation, ok to use? (Enter y or n) ->
Figure 75 Use existing MDM definition
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.
Found an existing MDM definition for m821a user on master
cpu m821a on this workstation, ok to use? (Enter y or n) -> y
Existing TWS user m821a for master
cpu m821a on this workstation will be used.
This is a list of defined MDM users in the TWSRegistry.dat file
for this workstation.
m821a
m83rtm
drwxrwxr-x
2 root
/etc/TWS/APPL.tws
sys
96 Feb 20 16:15
Found the tws application definition on this
workstation, ok to use? (Enter y or n) ->
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.
58
Autoinstall.sh Utility Script
Found the tws application definition on this
workstation, ok to use? (Enter y or n) -> y
Application tws definition for master cpu m821a
on this workstation will be used to schedule install.
Application tws will be used.
logout
The current process id is 20511, Temporary created files will
be 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 ->
Figure 77 Prompt for patch or utilities operations
3. Reply “u” to proceed to the Main Utilities Menu. Refer to Figure 77.
Autoinstall.sh Utility Script
59
Enter p to patch a workstation, u for utilities to create patch job
streams, 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
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.
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 ->
Figure 79 Job and Job Stream Utilities Menu
60
Autoinstall.sh Utility Script
Create Job Stream Definition Files
At 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.
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.
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.
Autoinstall.sh Utility Script
61
Enter c, a, r, b or e -> c
The patch_succ_sch_def file in the /etc/TWS/MDM.m821a.m821a
directory will have the TWSPATCH_SUCC job stream definition.
1 unique TWS patch install job definition(s) have been extracted
from 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.m821a
directory 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).
To exit utility enter (e).
Enter c, a, r, b or e ->
Figure 80 Job stream files creation
Add Job and Job Stream definitions to Tivoli Workload
Scheduler database
When 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 .
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.
62
Autoinstall.sh Utility Script
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_def
TWS for UNIX (HPUX)/COMPOSER 8.2.1 (1.18.2.21)
Licensed Materials Property of IBM
5698-WKB
(C) Copyright IBM Corp 1998, 2005
US Government User Restricted Rights
Use, 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_def
AWSBIA090E Total errors in /etc/TWS/MDM.m821a.m821a/patch_job_def:
0, warnings 0.
-replace /etc/TWS/MDM.m821a.m821a/patch_lau_sch_def
AWSBIA019E 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_def
AWSBIA019E 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 messages
when 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).
To exit utility enter (e).
Enter c, a, r, b or e ->
Figure 81 Add job and job stream definitions to TWS database
Autoinstall.sh Utility Script
63
Rename patch_job_def file
After 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.
64
Autoinstall.sh Utility Script
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 ->
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
Autoinstall.sh Utility Script
65
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.
Important: Because fixpack cycles can overlap, great care must be taken to
make sure that definitions are not overwritten by the next fixpack cycle.
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.
66
Autoinstall.sh Utility Script
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
Example: conman command from master
%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
Example: conman command from master
Autoinstall.sh Utility Script
67
%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.
%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
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.
ps -ef |grep patch
root 27904
1 0 13:02:48 ?
root 28264 27179 0 13:04:25 pts/28
root 27961 27904 0 13:04:02 ?
Figure 84 ps -ef |grep patch list
68
Autoinstall.sh Utility Script
0:00 /bin/sh -x /etc/TWS/patch_lau.sh
0:00 grep patch
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.
M821A
[Carry]
#TWSPATCH_SUCC
*************************** SUCC 10 13:05 00:01
M82A_820_FP_10_27860_SUCC
SUCC 10 13:05 00:01 #J28449
0
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.
%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]
(M82A#)M82A_820_FP_10
#J27860
0
M821A
#TWSPATCH_SUCC
SUCC 10 13:05 00:01 [Carry]
SUCC 10 13:05 00:01
#J28449
SUCC GO 13:02 00:01
****************************************
M82A_820_FP_10_27860_SUCC
0
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.
Autoinstall.sh Utility Script
69
$ pwd
/etc/TWS
$ ll
total 160
drwxrwxr-x
drwxrwxr-x
-rw-rw-r-drwxrwxr-x
-rw-rw-rw-rwxr-xr-x
-rwxr-xr-x
drwxrwxr-x
2
2
1
2
1
1
1
2
root
root
root
root
root
root
root
root
sys
sys
sys
sys
sys
sys
sys
sys
96
8192
5422
96
68
20312
6459
8192
May
May
May
Feb
May
May
May
Jan
14
15
8
26
7
14
14
29
20:03
18:39
11:49
16:16
13:30
20:03
20:03
12:01
APPL.tws
MDM.m821a.m821a
TWSRegistry.dat
appl.tws
mdm_m821a_fixpack.log
patch_install.sh
patch_lau.sh
patchutils
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.
$ more mdm_m821a_fixpack.log
HORBLM82_820_FP_07_10479_SUCC completed Mon May 7 11:20:52 CDT 2007
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
70
Autoinstall.sh Utility Script
23.You can rerun abended fixpack installation jobs after making changes.
Note: Reruns of patch installation jobs will run immediately unless priority is
lowered from GO to 0.
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.
Autoinstall.sh Utility Script
71
򐂰 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).
Figure 89 Pre-troubleshooting checklist
72
Autoinstall.sh Utility Script
Fixpack logs
The 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.
$ pwd
/etc/TWS
$ ll
total 160
drwxrwxr-x
drwxrwxr-x
-rw-rw-r-drwxrwxr-x
-rw-rw-rw-rwxr-xr-x
-rwxr-xr-x
drwxrwxr-x
2
2
1
2
1
1
1
2
root
root
root
root
root
root
root
root
sys
sys
sys
sys
sys
sys
sys
sys
96
8192
5422
96
68
20312
6459
8192
May
May
May
Feb
May
May
May
Jan
14
15
8
26
7
14
14
29
20:03
18:39
11:49
16:16
13:30
20:03
20:03
12:01
APPL.tws
MDM.m821a.m821a
TWSRegistry.dat
appl.tws
mdm_m821a_fixpack.log
patch_install.sh
patch_lau.sh
patchutils
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.
$ more mdm_m821a_fixpack.log
HORBLM82_820_FP_07_10479_SUCC completed Mon May 7 11:20:52 CDT 2007
Figure 91 FTA fixpack installation log record
Autoinstall.sh Utility Script
73
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 mode
To 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.
#Debug Mode Option
#To place in debug mode set DEBUG to y
DEBUG="";export DEBUG
SETVAR="vx";export SETVAR
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.
74
Autoinstall.sh Utility Script
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.sh
Check for existence of TWS patch log
[passed]
directory /tmp
Patch install logs will default to:
/tmp directory
F1le m82a_fp_10_27860.stdlog in /tmp directory
will 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
Autoinstall.sh Utility Script
75
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.
tail -15 /tmp/m82a_fp_10_27860.stdlog
Extract TWS shortname
Change to TWS instance home directory
Stop and shut TWS processes
Terminate processes accessing TWS binaries
Display TWS binaries should not show active
Change to directory where twspatch exists
Display current path
Execute the twspatch install
Twspatch install
FTA start and limit 0 command executed
Does SUCC patch schedule exist on Master
Patch SUCC job sent to SUCC schedule
Patch SUCC job sent to JOBS schedule
Exit script
[DONE]
[DONE]
[DONE]
[DONE]
[DONE]
[DONE]
[DONE]
[DONE]
[SUCC]
[DONE]
[YES]
[YES]
[N/A]
[YES]
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.
76
Autoinstall.sh Utility Script
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
#J27860
SUCC GO 13:02 00:01
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.
Autoinstall.sh Utility Script
77
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
Note: Use Windows® Explorer to create the .ssh directory on Windows
workstations.
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.
78
Autoinstall.sh Utility Script
Generating public/private dsa key pair.
Enter file in which to save the key (/home/larry/.ssh/id_dsa
Enter 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
Figure 94 The ssh-keygen display and prompts
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.
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:
Note: Include the trailing colon ":".
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.
Autoinstall.sh Utility Script
79
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
Note: A password-less connection to remote_workstation.domain.com will be
established. The use of scp will not require a password either.
15.Close the remote connection by typing exit.
Warning: On the local workstation do not remove the id_dsa file, as the
id_dsa.pub may be removed.
Authorized_keys file
To 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.
root@testmaster.tivlab.austin.ibm.com
larry@TREK
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.
root@taos.ibm.com
Figure 96 Defined users in authorized_keys file for testmaster workstation
Know_hosts file
An additional file, know_hosts, may exist in the .ssh directory. This file contains
the remote host names that this workstation has connected to.
80
Autoinstall.sh Utility Script
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.
Autoinstall.sh Utility Script
81
82
Autoinstall.sh Utility Script
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.
© Copyright International Business Machines Corporation 2007. All rights reserved.
Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by
GSA ADP Schedule Contract with IBM Corp.
83
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:
redbook@us.ibm.com
򐂰 Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. HYTD Mail Station P099, 2455 South Road
Poughkeepsie, NY 12601-5400 U.S.A.
®
Redpaper
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.
84
Autoinstall.sh Utility Script