C Agent Deploy Application - Installation Prerequisites

This appendix describes the prerequisites to performing an installation using the Agent Deploy application. It contains the following sections:

Prerequisites
Prerequisite Checks Executed by Agent Deploy
Troubleshooting Failed Prerequisite Checks

Prerequisites

The following prerequisites must be met before proceeding with the installation:

Verify if the package requirements for each platform are met. See
SSH (Secure Shell) User Equivalence is set up
Validate all command locations
Modify response file for Big IP host and port
Verify oraInventory permissions on remote hosts
Verify if user installing the agent is same as the user that installed Oracle Application Server and Oracle Collaboration Suite.
Verify if the Target Monitor Check and Host Name Check are the same for all platforms.
- Target Monitor Checks: The agent will not be able to monitor those targets that have been installed by different users.
- Host Name Check: The name of the host on which the installation is being performed should neither be localhost.localdomain nor an IP address. It must be a valid host name.

Check Platform-Specific Package Requirements for Agent Installation

Table C-1 lists the packages and disk space requirements for each platform.

Table C-1 Platform-Specific Packages and Disk Space Requirements

Operating System	Platform	Packages	Disk Space for Installation
Solaris	Solaris 5.8 SPARC	SUNWarc SUNWbtool SUNWhea SUNWlibm, SUNWlibms SUNWsprot SUNWsprox SUNWtoo SUNWi1of SUNWxwfnt	0.85 GB
	Solaris 5.9 SPARC	SUNWlibm SUNWlibms SUNWsprot SUNWsprox SUNWtoo SUNWi1of SUNWxwfnt	0.85 GB
	Solaris 5.10 SPARC	SUNWbtool	0.85 GB

HP-UX	HP-UX 11.11 PA-RISC2.0	X11MotifDevKit version 0.0 X11MotifDevKit.MOTIF21-PRG version 0.0	1.5 GB
	HP-UX 11.23 PA-RISC2.0	BUNDLE11i version B.11.23.0409.3	1.5 GB

IBM-AIX	AIX 5200	bos.perf.proctools version 0.0	1.5 GB
	AIX 5300	bos.perf.proctools version 0.0	1.5 GB

Linux Itanium	Red Hat Enterprise Linux AS/ES 3.0 ia 64	GLIBC>=2.3.2-95.27 Make version 3.79 binutils version 2.14 Libaio version 0.3.96	0.75 GB
	Red Hat Enterprise Linux AS/ES 4.0 ia 64	GLIBC>=2.3.2-95.27 Make version 3.79 binutils version 2.14 Libaio version 0.3.96 gcc version 3.2	0.75 GB
	SUSE Linux Enterprise Server 9 ia 64	GLIBC>=2.3.3-98.28 Make version 3.80 binutils version 2.14 Libaio version 0.3.102 gcc version 3.3	0.75 GB

Set Up SSH (Secure Shell) User Equivalence

You must set up SSH (Secure Shell) prior to deploying the Management Agent using the Agent Deploy application. This is required as the Agent Deploy application uses SSH and SCP as modes of communication between nodes. Setting up the user equivalence helps avoid SSH authentication calls during future Agent Deploy operations.

Caution:

The SSH User Equivalence must always be set between the target hosts and the OMS, and never among the target hosts.

In order to set up SSH, you must execute the sshUserSetup.sh script (sshUserSetupNT.sh on Microsoft Windows) that is available at the following location:

OMS_HOME/sysman/prov/resources/scripts

The SSH connectivity script should be used for 10.2.0.2 Management Agent when establishing connectivity with both Windows and Linux targets.

If 10.2.0.1 Management Agent is in use, then sshUserSetup.sh needs to be used for Linux and sshUserSetupNT.sh is to be used for Windows hosts. Refer to section 5 of the Agent Best Practice paper available at http://www.oracle.com/technology/products/oem/pdf/10gr2_agent_deploy_bp.pdf.

Setting Up SSH User Equivalence Using sshConnectivity.sh

The sshConnectivity.sh script is used on UNIX/Microsoft Windows platforms to set up SSH user equivalence from the (local) host on which it is run, to the specified remote hosts. After this script is executed, you can use SSH to run commands on the remote hosts, or copy files between the local and the remote hosts without being prompted for passwords or confirmations.

Before executing this script, you must ensure that the following environment variables are set:

ORACLE_HOME

Set this to the OMS home as an environment variable using the following command:

For CSH shell
```
setenv ORACLE_HOME /scratch/OracleHomes/oms10g
```
For BASH shell
```
export ORACLE_HOME= /scratch/OracleHomes/oms10g
```
SSH_LOC

You need not specify this if the ORACLE_HOME variable has already been set. If it has not been set, ensure that this value points to the directory that contains the SSH and remote interfaces JARS files (ssh.jar, remoteinterfaces.jar, jsch.jar).
OUI_JAR

You need not specify this if the ORACLE_HOME variable has already been set. If this variable has not been set, ensure that this value points to the OUI home directory.
JAVAHOME

You need not specify this if the ORACLE_HOME variable has already been set. If this variable has not been set, ensure that this value points to the JAVA home directory.

Note:

All these variables can also be passed as command-line variables to the script in the form of var=value.

sshConnectivity.sh Script Usage

The usage of this script is as follows:

./sshConnectivity.sh -user <username> -hosts <space separated
hostlist> | -hostfile <absolute path of cluster configuration file>
[-asUser <user for which the setup needs to be done on the local machine, for example,SYSTEM>
[-asUserGrp <group that the specified asUser belongs to>]
-sshLocalDir <windows style full path of dir where keys should be
generated on the local machine for asUser>] [ -advanced ]
[-usePassphrase] [-logfile <absolute path of logfile> ] [-confirm]
[-shared] [-verify] [-exverify] [-remotePlatform <platform id (linux:46,
solaris:453, msplats:912>] [-obPassword <obfuscated password>] [-silent]
[-localPlatformGrp <unix,win>] [help]

Example C-1 Usage of the sshConnectivity.ch Script to Set Up User Equivalence on Local UNIX Platforms (Linux, Solaris, HP-UX, and IBM AIX)

./sshConnectivity.sh -user <username> -hosts <space separated 
hostlist> | -hostfile <absolute path of cluster configuration file>
[-remotePlatform <platform id (linux:46, solaris:453, msplats:912>]
[-shared] [-confirm]

For example,

./sshConnectivity.sh -user pjohn -hosts sidtest1
./sshConnectivity.sh -user alhammel -hosts zeke2 -remotePlatform 453

Example C-2 Usage of the sshConnectivity.ch Script to Set Up User Equivalence on Local Microsoft Windows Platforms

./sshConnectivity.sh -user<username> -localPlatformGrp win -asUser <user for which the setup needs to 
be done on the local machine, for example, SYSTEM> [-asUserGrp <group that the 
specified asUser belongs to>] -sshLocalDir <Windows style full 
path of dir where keys should be generated on the local machine for 
asUser> -hosts <space separated hostlist> | -hostfile <absolute path of 
cluster configuration file> [-remotePlatform <platform id (linux:46,
solaris:453, msplats:912>] [-shared] [-confirm]

For example,

Go to the Cygwin BASH prompt and execute cd /
Execute mkdir .ssh

Now, execute the script as follows:

./sshConnectivity.sh -user alhammel -localPlatformGrp win -asUser SYSTEM-asUserGrp root -sshLocalDir C:\cygwin\.ssh -hosts scrat2

Note:

Specify all the paths in double quotation marks (" ").

Parameter Description

-user

This is the user on remote hosts.
-hosts

This specifies space-separated remote hosts list.
-hostfile

You can specify the host names either through the -hosts option, or by specifying the absolute path of a cluster configuration file. A sample of the host file content is as follows:
```
scrat02 scrat02int 10.1.0.0 scrat02v -
scrat06 scrat06int 10.1.0.1 scrat06v -
```
Note:
The first column in each row of the host file will be used as the host name.
-localPlatformGrp

Specify this option if the local platform is Microsoft Windows. The default value of this option is unix.
-remotePlatform

You must specify this option is the remote platform is not the same as the local platform. Here, you must specify the platform ID of the remote platform. You can find the platform IDs of the supported platforms in the platforminfo.properties file.

Caution:

When you are executing this script on a Microsoft Windows OMS machine, ensure it is executed from within the Cygein BASH shell. This script will fail to execute if run from outside this location.

Setting Up SSH on UNIX Using sshUserSetup.sh

Usage of this script is as follows:

sshUserSetup.sh -hosts "<hostlist>" -user <user name> [-verify] [-confirm] [-shared]

For example, sshUserSetup.sh -hosts "host1 host2" -user sjohn

Description

This script is used to set up SSH user equivalence from the host on which it is run to the specified remote hosts. After this script is run, you can use SSH to execute commands on the remote hosts, or copy files between the local host and the remote hosts without being prompted for passwords or confirmations.

The list of remote hosts and their user names are specified as command-line parameters to the script.

-shared

In case you have the home directory NFS-mounted or shared across the remote hosts, the script should be used with the -shared option.

To determine whether or not an Oracle Home Directory is Shared or Not Shared, consider a scenario where you want to determine whether the Oracle home directory of user1 is shared across hosts A, B, and C or not.You can determine this by following these instructions:
1. On host A, touch ~user1/checkSharedHome.tmp.
2. On hosts B and C, execute ls -al ~user1/checkSharedHome.tmp.
  
  If the file is present on hosts B and C in the ~user1 directory and is identical on all nodes, it means that the user's home directory is shared.
3. On host A, rm -f ~user1/checkSharedHome.tmp.
Note:
In the event that you accidentally pass the -shared option for nonshared homes or reverse, the SSH equivalence is set up for only a subset of the hosts. You will have to rerun the setup script with the correct option to rectify this issue.
-verify

The -verify option allows you to verify if SSH has been set up. In this case, the script does not set up SSH, but only checks if SSH user equivalence has been set up from the local host to the remote hosts. It then runs the date command on each remote host using SSH. In case you are prompted for a password or see a warning message for a particular host, it means the SSH user equivalence has not been set up correctly for that host.In case the -verify option is not specified, the script sets up SSH and then does the verification as well.
-confirm

The -confirm option allows you to set up SSH user equivalence with a forced change in the permissions on remote hosts. This means that the script will not prompt you to confirm the change in permissions, if you execute the script passing the -confirm option.
-help

Use this option to view the readme file for the sshUserSetup.sh script. The usage is as follows:
```
sshUserSetup.sh -help 
```

The following examples provides usage of the previously mentioned options:

Local host = Z
Remote Hosts = A, B, and C
Local user = sjohn
Remote users = foo (non-shared)
        aime (shared)
./sshUserSetup.sh -user foo -hosts "A B C" -confirm

Example C-3 Set Up SSH User Equivalence and Verify the Setup

sshUserSetup.sh -hosts "A B C" -user foo

This script sets up user equivalence from:

Z to A
Z to B
Z to C

Example C-4 Set Up SSH User Equivalence and verify the Setup Without a Confirmation Prompt

sshUserSetup.sh -hosts "A B C" -user foo -confirm

This sets up SSH between the local host and A, B, C. It also verifies the setup. However, due to the usage of the -confirm option, it assumes that users are aware of the changes that would be made on the systems and will not ask for any confirmation.

Example C-5 Verify Existing SSH User Equivalence Setup

./sshUserSetup.sh -hosts "A B C" -user foo -verify

Because the -verify option is specified, the script does not set up the SSH setup, but only verifies the existing setup.

Setting Up SSH Server (SSHD) on Microsoft Windows

Before starting with the SSHD setup, ensure you are not using OpenSSH and MKSNT when using the Agent Deploy application. The Agent Deploy application uses the complete Cygwin suite (full collection of the software tools packaged in Cygwin). To get the complete collection of Cygwin, do the following:

Ensure OpenSSH\bin and mksnt are not in your %PATH%. If they are, remove them by doing the following:
1. Right-click on My Computer and go to Properties.
2. In the System Properties window that appears, click Advanced.
3. In this tab, click Environment Variables.
4. Here, search for the Path system variable, select it, and if the OpenSSH\bin and mksnt are present in the PATH, click Edit.
5. In the Edit System Variable dialog box that appears, delete these two values from the PATH, and click OK.
Now, stop the SSH Daemon if it is running from OpenSSH. To do this:
1. Right-click on My Computer, and select Manage.
2. In the Computer Management window that appears, go to Services under Services and Applications.
3. In the right-pane, select the SSH daemon service and click the Stop Service icon.
  
  Note:
  Ensure you rename the installation directories of OpenSSH and MKSNT.
To install the full suite of Cygwin software, go to http://www.cygwin.com, and install Cygwin in your C:\cygwin directory.

Note:
If you are installing Cygwin into another directory than what has been previously mentioned, ensure you update the $OMS_HOME/sysman/prov/resources/ssPaths_msplats.properties file with the proper Cygwin binary values after installing Oracle Enterprise Manager Grid Control.

Caution:
If you are installing Cygwin at a directory that is other than C:\cygwin on a remote machine, you must also ensure that Cygwin is installed on the OMS machine at the exact same location.
The Cygwin installation directory should not contain any spaces.

While installing Cygwin, ensure you choose the following binaries:
1. Zip, unzip binaries from the Archive package.
  
  Figure C-1 Zip Unzip Binaries
2. OpenSSH and dependencies (automatically selected if you choose OpenSSH) from the Net package.
  
  Figure C-2 Net Packages
Modify the C:\cygwin\cygwin.bat file to add the following line:
```
set CYGWIN=binmode tty ntsec
```
Ensure cygrunsrv is installed by going to C:\cygwin\bin and executing the following:
```
bash
cygrunsrv -h
```
Note:
If you are prompted to provide a Cygwin value, enter binmode tty ntsec. If this returns an error message stating "service does not exist", you are on the right track, and can proceed to the next step.
If you encounter any other error message, (for example, "command cygrunsrv not found"), see AppendixA, "Troubleshooting the "command cygrunsrv not found" Error." for more information on troubleshooting this issue.
Open a new command prompt and execute the following:
```
bashssh-host-config
```
Note:
Enter "no" when prompted to create sshd user account (message reads "sshd user account needs to be created").
Enter "yes" at all other prompts.

When prompted to answer the question "Which value should the environment variable CYGWIN have when sshd starts?", Oracle recommends that you set the value to at least "ntsec" as shown in the following example. This will enable you to change the user context without having to specify the password.

As an answer to the previously mentioned question, specify a value that is similar to the following and press Enter:
```
CYGWIN="binmode tty ntsec"
```
Now, open the /etc/passwd file, and remove only those entries of the user that you will use to connect to the OMS machine.

For example,
- If the user that you are employing to connect to the OMS machine is a local user, execute the following:
```
/bin/mkpasswd -l –u <USER> >> /etc/passwd
```
- If the user you are employing to connect to the OMS machine is a domain user, execute the following:
```
/bin/mkpaswd.exe -d -u <USER> >> /etc/passwd
/bin/mkgroup.exe -d >> /etc/group


mkdir -p /home/<USER>  (for example, mkdir -p /home/pjohn)
chown <USER> /home/<USER> (for example, chown pjohn /home/pjohn)
```
Start the SSH daemon.

If the user you are employing to connect to the OMS machine is a domain user, do the following:
1. Right-click on My Computer, and select Manage.
2. In the Computer Management dialog box that appears, go to Services and Applications, and select CYGWIN sshd.
3. Right-click CYGWIN sshd and select Properties.
4. In the Properties dialog box, go to the Log On tab.
5. Here, specify the domain/username and password. Click Apply.
6. Now, go to the CYGWIN command prompt, and execute the following:
```
chmod 644 /etc/ssh*
           chmod <USERNAME> /var/empty
   chmod 755 /var/empty   chmod 644 /var/log/sshd.log
```
  Note:
  If /var/log/sshd.log does not exist, you do not have to execute the following command:
```
chmod 644 /var/log/sshd.log
```
7. Start the SSH daemon by executing:
```
/usr/sbin/sshd
```
  Alternatively, from the same BASH prompt, you can also execute:
```
cygrunsrv -S sshd
```
  Note:
  Use cygrunsrv -E sshd to stop the SSH daemon.
You can now test your cygwin setup.

To do this, go to a different machine (that has the ssh client running), and execute the following command:
```
ssh -l <USERNAME> <localhost> 'date'

OR

ssh -l <USERNAME> <this node> 'date'
```
For example,
```
ssh -l pjohn egal07.db.funds.com 'date'
```
This command will prompt you to specify the password. When you specify the correct password, the command should return the accurate date.

Setting Up SSH on Microsoft WIndows Using sshUserSetupNT.sh

Note:

Before executing the sshUserSetupNT.sh script, execute the following commands to ensure the home directory has been correctly set:

Execute echo $HOME

Ensure this displays the home directory of the current user.
If it points to the home directory of another user, execute the following command:
```
export HOME=<Windows style absolute path of homedir>
```
Now, execute echo $HOME again, to verify the home directory. The $HOME value must be the same as that passed to -homeDir

This is the script that should be executed to set up user equivalence on Microsoft Windows platforms. The usage of the script is as follows:

./sshUserSetupNT.sh -user -asUser -asUserGrp -sshLocalDir -homeDir -hosts -hostfile

For example, ./sshUserSetupNT.sh -user pjohn -asUser SYSTEM -asUserGrp root-sshLocalDir "C:\cygwin\.ssh" -homeDir "C:\Documents and Settings\pjohn" -hosts "host1 host2"

Note:

After the SSHUserSetupNT.sh script has been executed, you must verify the successful SSH user setup on all the hosts, individually.

That is, if you have run the script to set up user equivalence on two hosts (host1, and host2), you must run the following command on each host to verify successful SSH setup:

ssh -l <username> host1 'date'

and then run:

ssh -l <username> host2 'date'

Caution:

You must execute the sshUserSetupNT.sh script on the local OMS machine from within the cygwin (BASH) shell only. The script will fail to execute if done from outside this location.

All the previously mentioned options are mandatory, and should be passed while executing the script.

Note:

It is assumed that C:/cygwin is the default installation directory for the Cygwin binaries.

If you install cygwin at a location other than c:\cygwin (default location), it can cause the SSH setup to fail, and in turn, the agent installation will fail.

To work around this issue, you must either install cygwin in the default directory (c:\cygwin), or update the ssPaths_msplats.properties file with the correct path to the cygwin binaries.

You can look into the following remote registry key to find out the correct Cygwin path:

HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/

Description

This script is used on Microsoft Windows platforms to set up SSH user equivalence from the host on which it is run to the specified remote hosts. After this script is run, you can use SSH to execute commands on the remote hosts, or copy files between the local host and the remote hosts without being prompted for passwords or confirmations.

The list of remote hosts and their user names are specified as command-line parameters to the script.

-asUser

This is the user of the local machine on which the setup must be performed. For example, SYSTEM.
-asuserGrp

This is the group to which the specified asUser belongs.
-sshLocalDir

This is the full path to the directory where the keys should be generated for the asUser on the local machine.
-homeDir

This is the full path to the home directory of the current user.

If the /home key (in regedit) is seen as a subkey under the Cygnus Solutions key, then the value of the /home key must have /<username> as a suffix and then be used as -homeDirm value.

If the /home key is not found, go to the Cygwin BASH prompt and check the value of $HOME. You can now use the same value of $HOME as the value for -homeDir.

If $HOME does not have any value (is empty), then you must update the /etc/passwd file.

Identifying the Correct Entry in the /etc/passwd File

If the /etc/passwd file has only one entry for the user, you can simply modify that value. In the event that there are multiple entries in this file, you must first identify the correct entry and then modify it.

To identify the correct entry:
- Execute the following command if you have specified a local user during SSH setup:
```
/bin/mkpasswd -l -u <username>
```
- Execute the following command if you have specified a domain user during SSH setup:
```
/bin/mkpasswd -d -u <username>
```
Now, match the output with the corresponding entry in the /etc/passwd file. This is the entry that you must modify.

Updating the -homeDir value

All values for all users are listed as colon (:) separated entries (or fields). To update the user entry that you have identified previously, go to the penultimate value (or field) of that user entry, and modify the value of the home directory for that user.

Always specify the absolute path needed by Cygwin as value for the home directory. For example, if the path is C:\Documents and Settings\pjohn, modify it to:
```
/cygdrive/c/Documents and Settings/pjohn 
```
Or, if the path reads C:\cygwin\pjohn, modify this to:
```
/cygdrive/c/cygwin/pjohn
```
Now, save the password file and reenter the BASH shell.

Note:

If you have used spaces in the $HOME value (for example, /cygdrive/c/Documents and Settings/pjohn), specify the $HOME value in Microsoft Windows style and within double quotation marks (for example, "C:\ Documents and Settings\pjohn").

Note:

Specify the full path within double quotation marks (" ").

Caution:

You must execute the sshUserSetupNT.sh script on the local OMS machine from within the cygwin (BASH) shell only. The script will fail to execute if done from outside this location.

Setting Up the Timezone Variable on Remote Hosts

This section lists the steps you must follow to set up the timezone environment variable on remote hosts.

To verify if the timezone environment variable (TZ) is accessible by the SSH server on the remote hosts, execute the following command from the OMS host:

ssh -l <user_name> -n <remote_node> 'echo $TZ'

If this command does not return the TZ environment variable value, you must set the TZ variable and ensure this is accessible by the SSH server. You can set the TZ environment variable on remote hosts in the following sections:

Set the TZ variable and Restart the SSH Daemon

If the shell being used is BASH, add the following line to the .bashrc file in the home directory of the user (being used) for ssh access:

export TZ=<your machine's timezone>

If you are using a CSH shell, then add the following line to the .cshrc file in that directory:

setenv TZ <your machine's timezone>

Depending on the shell that is present on the host, set the TZ variable by executing the following command:
```
For a CSH Shell, specify:
setenv TZ PST8PDT
```
Restart the SSH daemon by executing:
```
sudo /etc/init.d/sshd restart
```
Now, execute the following command from the OMS home to verify if the SSH server can access the TZ variable.
```
ssh -l <user_name> -n <node_name> 'echo $TZ'
```

Set the TZ Variable in the "Shell rc" File

The timezone variable must be set in the rc file of the shell that the host is using.

For example, if the host is using a BASH shell, go to the user's home directory ($HOME) and add the following to the ~/.bashrc file to set the TZ variable:

TZ=PST8PDT; export TZ

If the host is using a CSH shell, go to $HOME and add the following to the ~/.cshrc file:

setenv TZ PST8PDT

Now, execute the following command from the OMS home to verify if the SSH server can access the TZ variable.

ssh -l <user_name> -n <node_name> 'echo $TZ'

Note:

If sshd is not set up on remote box for TZ, you can pass this variable in the Additional Parameters text box using the -z option for default software source location (for install or upgrade) and the s_timezone=<timezone> option for a nondefault software location.

Note that this will perform the installation of agents on all remote nodes with the same timezone value that you specify in the Additional Parameters text box. See Appendix D, "Additional Parameters for Agent Deploy" for more information.

Validate All Command Locations

The properties files located at <omshome>/sysman/prov/resources/ comprises the default locations of commands that are required for successful execution of certain application programming interfaces (APIs), for example, the ping executable.

Such command locations can vary between machines and platforms. Run the Validatepaths script to verify whether the command locations in the properties file are correct. This script provides a list of commands that are not found in the default locations.

Run the following command to execute this script:

./validatePaths -dirloc oms/sysman/prov/resources/

In the preceding example (of the ping executable), if the executable is present in /usr/sbin/ping, which is not the default location, you must specify this value in the userpaths.properties file by specifying PING_PATH=/usr/sbin/ping.

The properties files that are loaded by the Agent Deploy application are the following:

platforminfo.properties

Contains a list of files that need to be loaded for each platform. These files specify the paths for the commands. For example, /bin/ping.
- Paths.properties
  
  This file contains the arguments that need to be passed everytime the commands listed in this file are executed.
- sPaths.properties
  
  This is a generic file that contains the paths for all commands that need to be executed, regardless of the platform.
- ssPaths_<platform>.properties
  
  This is a platform-specific file and contains the commands that need to be executed for that platform. For example, ssPaths_sol.properties.
  Caution:
  On Microsoft Windows platforms, the path to the cygwin binaries is hardcoded in the ssPaths_msplats.properties file. If you install cygwin at a location other than c:\cygwin (default location), it can cause the agent installation to fail.
  To work around this issue, you must either install cygwin in the default directory (c:\cygwin), or update this properties file with the correct path to the cygwin binaries.
  
  You can look into the following remote registry key to find out the correct Cygwin path:
```
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
```
- userPaths.properties
  
  This file lists all the variables that are used to specify the command paths. You must uncomment the variables that you want to use, and specify appropriate values.
Caution:
The files that comprise each properties file are loaded in the ascending order of their precedence. This means that values you specify in the last file that is loaded will override the values for the same property in the previous files.
For example, the platforminfo.properties file comprises paths.properties, spaths.properties, ssPaths.properties, and userPaths.properties.

If the default location for the ping executable in sPaths.properties file is usr/bin/ping, and you specified an alternative location in the ssPaths.properties file as usr/sbin/ping, the value in the latter file takes precedence over the others.

Note:
If you want to include other command variables, you can either choose to specify these variables in any of these s*Paths.properties/userPaths.properties files, or create another properties file and specify its name in platforminfo.properties.
Ensure these files are part of the platforminfo.properties file. If they are not, Agent Deploy ignores the paths to the executables that you have specified in these files and attempts to run the executables from their default locations.

Sample property files are provided at the end of this appendix under Sample Properties Files.
system.properties

This file contains properties that help you control the activity and performance of the application. For example:
- oracle.system.prov.threadpoolsize
  
  Number of threads that get created in the application and work in parallel to execute commands on remote hosts. The default threadpool size value that is set for Agent Deploy is 32. You can specify an appropriate value for the threadpool size in this property.
  
  For example oracle.sysman.prov.threadpoolsize=128.
- oracle.sysman.prov.threadpoolmaxsize
  
  Number of threads that can increase dynamically depending on the workload.
  
  The default value used in the application is 256 (oracle.sysman.prov.threadpoolmaxsize=256). You can specify an appropriate maximum value for the threadpool size in this property.
ignoreMessages.txt

If there are error messages displayed in the error stream that you know can be ignored in the setup, you can update these messages in the ignoreMessages.txt file.

Generally, if the error stream contains data when you execute any command, it is assumed that the command failed. But the data in the error stream may not always correspond to the error. So, to ignore such error messages, you must add these messages (including the banner) to the ignoreMessages.txt file.
```
Consider the following example:
When you run /usr.local/bin/sudo on a remote machine, it writes the following messages on to the error stream:
Administrator. It usually boils down to these two things:#1) Respect the privacy of others.#2) Think before you type.Password:
This essentially, is just a warning to the user and does not constitute the failure of the executed command.
Such error messages can be added to the ignore_Message.txt file.
```

Note:

The data format for these files mandates only one property per line. You must specify the property values in the format: variable=value.

Location of Properties File

You can view the following properties files at <OMS_HOME>/sysman/prov/resources/:

platformInfo.properties
Paths.properties
sPaths.properties
ssPaths_sol.properties
userPaths.properties
system.properties
ignoreMessages.txt

Location of Installation Logs

See Appendix F, "Installation and Configuration Log File Locations" for more information on the various installation and configuration logs that are created, and their locations.

Modify Response File for Big IP Host and Port

If the Management Service is using a load balancer, you must modify the s_omsHost and s_OMSPort values in the <omshome>/sysman/agent_download/10.2.0.2.0/agent_download.rsp file to reflect the load balancer host and port before using the Agent Deploy application.

Verify oraInventory Permissions on Remote Hosts

Ensure you (or the user performing the agent installation) have read, write, and execute permissions to oraInventory on all remote hosts. If you do not have these permissions on the default inventory (typically at /etc/oraInst.loc) on any remote host, you can specify the path to an alternative inventory location by using the -i <location> option in the Additional Parameters section.

Note:

If this is the first installation on a remote host, Oracle Universal Installer automatically creates the oraInventory in the user's home directory with read, write, and execute permissions for that user, as well as the OS group to which the user belongs.

Verify User Credentials

Ensure the user installing the agent is the same as the user that has installed Oracle Application Server and/or Oracle Collaboration Suite. You must also ensure the user has SUDO privileges that are required to execute the root.sh script (UNIX platforms only).

You can either select Run Root.sh in Agent Deploy that will automatically execute the root.sh script (on UNIX platforms only) at the end of the installation, or choose not to select this option, but manually execute this script at the end of the installation.

This script must be run after the installation is complete in order to discover all the targets.

Prerequisite Checks Executed by Agent Deploy

The Agent Deploy application runs a local prerequisite check (on the machine running the Management Service) and remote prerequisite checks on all the remote hosts before proceeding with the installation process.

Prerequisite Checks Executed on the Local Host

Table C-2 lists the connectivity prerequisite checks that are run on the local (Oracle Management Service) host.

Table C-2 Connectivity Prerequisite Check

Check if	Description
Nodes are active	Verifies if the remote nodes are accessible.
SSH Server is up	Verifies if there is an SSH Server Daemon running on all remote hosts, since the installation process will require SSH.
SSH user equivalence is set	Verifies if the user name specified in the installation details page has the SSH User Equivalence on all the remote hosts.
Installation directory is writable on the remote hosts	Verifies if the installation base directory that you have specified is writable.

Prerequisite Checks Executed on Remote Hosts

Table C-3 lists the prerequisite checks that are executed by Agent Deploy for each installation type.

Table C-3 Prerequisite Checks for a New Installation of Management Agent

Prerequisite Check for	Description	New Installation	Shared Agent Installation	Upgrade
Certified Versions	Checks if the operating system on remote hosts is certified.	Yes	Yes	Yes
Packages	Checks if the minimum required packages are available on remote hosts	Yes	No	Yes
Disk Space	Checks if the minimum required disk space is available.	Yes	No	Yes
Agent Targets	Checks for targets on remote hosts that cannot be monitored by the agent. Targets that have been installed by another user cannot be monitored by the agent that you are going to install.	Yes	Yes	Yes
Oracle Home Location	Verifies if the specified Oracle home (`<install_base_dir/agent10g>`) is empty.	Yes	Yes	Yes
Existing Agent Installations	Checks for any existing agent installations on the remote hosts.	Yes	No	No
Write Permissions for Base Directory	Checks if the installation base directory on all remote hosts have write permissions.	Yes	No	No
Inventory Check	Checks if the user credentials that you have specified have write permissions on the central inventory of each remote host.	Yes	Yes	Yes
Upgrade Agent Existence Check	Determines the existence of an agent (10.1) that can be upgraded on the remote hosts.	No	No	Yes
Write Permissions for Upgrade Agent	Checks if the installation base directory on all remote hosts have write permissions.	No	No	Yes
NFS Agent Existence Check	Checks for any existing agent installations on the remote hosts.	No	Yes	No
Write Permissions for NFS Agent	Checks if the installation base directory, `EMSTATE` directory, and the NFS location are writable from all the remote hosts.	No	Yes	No
Time Zone ENV Check (UNIX Only)	Checks if the Timezone (TZ) environmental variable is set on the remote hosts.	Yes	Yes	Yes
Software Existence Check	Ensures the alternative software that you have specified is valid. Note: This check is executed only if you have selected a nondefault (Another Location) software location for the agent installation.	Yes

Troubleshooting Failed Prerequisite Checks

This section details the possible errors that you may encounter when the prerequisite checks are executed, and the appropriate user actions to be taken to resolve the errors.

Prerequisite Check Errors and Resolutions on Local Host

Table C-4 lists the most common reasons for prerequisite check failures, and the corresponding user actions to be performed to resolve them.

Table C-4 Prerequisite Check Errors and Resolutions on Local Host

Prerequisite Check	Reason for Failure	User Action^Foot 1
Nodes are active	Nodes are not accessible.	Ensure all the nodes are active. Remove the nodes that are not accessible from the nodes list.
SSH Server is up	SSH daemon on one or more nodes is not up.	Try to start the SSH daemon on the failed nodes. Remove the failed nodes from the node list.
SSH user Equivalence is set	SSH user equivalence is not set up from the local host to the failed nodes for the specified user credentials.	Set up the user equivalence for the specified user credentials between the Management Service and remote hosts using the `sshUserSetup.sh` script. See AppendixC, "Set Up SSH (Secure Shell) User Equivalence" for more information. Remove the failed nodes from the nodes list.
Installation directory is writable on the remote hosts	Installation base directory that you have specified is not writable, or cannot be created on the failed nodes.	Include write permissions on the failed nodes by executing the following command on the failed hosts from the local (OMS) host: [ssh -l <user> <host> "chmod +w -R <dir>"] Remove failed nodes from the nodes list.

^Footnote 1Where there are multiple user actions listed, you can choose to perform the action that is most appropriate.

Prerequisite Check Errors and Resolutions on Remote Hosts

Table C-5 lists the most common reasons for prerequisite check failures on remote hosts, and the corresponding user actions to be performed to resolve them.

Table C-5 Reasons for Prerequisite Check Failure and Corresponding User Actions

Prerequisite Check	Reason for Failure	User Action^Foot 1
Certified Versions	The failed host may have an operating system or version that is not certified to deploy the agent on that machine.	Exit the current installation and retry the agent installation without the failed hosts. Upgrade the failed node to an operating system or version that is certified before proceeding with the installation.
Packages	The failed hosts may not comprise the recommended minimum packages required to deploy the agent.	Click Fix and Retry in the Prorate Details page. Agent Deploy performs an automatic packages fix using YUM or RPMs. During the process, it returns to the Installation Details page and prompts you to specify valid or alternative values where required, and then reruns the prerequisite checks.
Disk Space	This check may fail if the required minimum disk space for the installation is not found on the remote hosts.	Increase the disk space on the failed hosts. Remove the failed nodes from the nodes list.
Agent Targets	The failed nodes may have some targets that were installed by a different user, and hence cannot be monitored by the agent.	Remove the targets that cannot be monitored from the failed hosts. Continue with the installation because the failure message is only a warning (though not recommended).
Port	The specified port is not valid, or is not available. You have not specified any port and there is no available port in the default range.	Ensure the specified port is not blocked on the failed hosts. In the Installation Details page, leave the Port value blank. If the default ports are either blocked or not available, remove the failed nodes from the nodes list.
Oracle Home Location	The `<install_base_dir>/agent10g` already exists and is not empty.	Clean up the `<install_base_dir>/agent10g` directory. Specify an alternative installation base directory. Remove the failed nodes from the nodes list.
Existing Agent Installations	An agent already exists on the failed remote hosts that is registered with the central inventory.	Uninstall the existing agent and retry the prerequisite checks. Continue with the installation because the failure message is only a warning (though not recommended).
Write Permissions for Base Directory	The installation base directory is not writable.	Include write permissions on the failed nodes by executing the following command on the failed hosts from the local (OMS) host: [ssh -l <user> <host> "chmod +w -R <dir>"] Remove failed nodes from the nodes list.
Inventory Check	The specified user credential does not have write permissions on the central inventory.	Change the central inventory permission settings to render the central inventory and its subdirectories writable. Complete the following steps to resolve this issue: Log in to the local host (machine running the Oracle Management Service). Change the directory to: <HOME>/sysman/prov/agentpush/resources/fixup For each failed host, run the following script: ./fixOraInvPermissions.sh <install user> <install group> <failed host name> <inventory location>. As this script must be run as `root` (using `sudo`) on the failed remote host, you are prompted to specify the `sudo` password.
Upgrade Agent Existence Check	A Management Agent release 10.1 is not present in the remote hosts on which you want to perform the agent upgrade.	Exit the upgrade process.
Write Permissions for Upgrade Agent	The installation base directory is not writable.	Include write permissions on the failed nodes by executing the following command on the failed hosts from the local (OMS) host: [ssh -l <user> <host> "chmod +w -R <dir>"] Remove failed nodes from the nodes list.
NFS Agent Existence Check	An agent already exists on the remote hosts that is registered with the central inventory.	Uninstall the existing agent and retry the prerequisite checks. Continue with the installation since the failure message is only a warning (though not recommended).
Write Permissions 'for NFS Agent	The installation base directory is not writable. The NFS location is not accessible. The `EMSTATE` directory is not writable.	Include write permissions on the failed nodes by executing the following command on the failed hosts from the local (OMS) host: [ssh -l <user> <host> "chmod +w -R <dir>"] Remove failed nodes from the nodes list.
Time Zone ENV Check	The TZ environment variable is not set on the remote hosts.	Recommended Specify the time zone in the Additional Parameters section (using the -z option) of the Installation Details page. Optional Set the TZ environment variable. Shut down and restart SSH on all remote hosts. Update with the TZ environment variable on all remote hosts.
Software Existence Check	The alternative software location that you have specified is not valid.	Revert to the default software source location. Change the alternative software location to a valid location (having `./stage/product.xml`).

^Footnote 1Where there are multiple user actions listed, you can choose to perform the action that is most appropriate.

Commands and Arguments Executed to Run Agent Deploy Plugins

The Agent Deploy application makes use of plugins to perform certain functions (for example, collect installation logs from targets). These plugins execute certain commands from the local (OMS) node (for example, mkdir, scp, and unzip), while others are executed from the remote nodes (for example, zip).

Table C-6 provides a list of commands that are executed on local and remote nodes.

Table C-6 Commands Executed on Local (OMS) and Remote Nodes

Commands Executed on Local Node (OMS)	Commands Executed on Remote Nodes
PING_PATH	RSH_PATH
SH_PATH	SSH_PATH
SHELL_PATH	RCP_PATH
SHELL_ARGS	SCP_PATH
TAR_PATH	SSH_ARGS
TAR_EXTRACT_ARGS	SCP_ARGS
TAR_MTIME_ARGS	RCP_ARGS
MKDIR	UNZIP_PATH
	UNZIP_ARGS

Sample Properties Files

A sample of each property file in the platforminfo.properties file is provided as follows:

platforminfo.properties

Contains the mapping between platform ID and the files to be loaded for that platform.

# Copyright (c) 2005, Oracle. All rights reserved.  
 
#unix
-1=Paths.properties,sPaths.properties,userPaths.properties
#linux x86
46=Paths.properties,sPaths.properties,userPaths.properties
#solaris sparc
453=Paths.properties,sPaths.properties,ssPaths_sol.properties,userPaths.properties
#ms_plats
-3=Paths.properties,ssPaths_msplats.properties
#windows nt
912=Paths.properties,ssPaths_msplats.properties
#HP-UIX
2=Paths.properties,sPaths.properties,ssPaths_hpuix.properties,userPaths.properties
#AIX
610=Paths.properties,sPaths.properties,ssPaths_aix.properties,userPaths.properties

Paths.properties

This is a generic file.

# Copyright (c) 2005, 2006, Oracle. All rights reserved.  
 
SSH_ARGS=-o FallBackToRsh=no  -o PasswordAuthentication=no  -o StrictHostKeyChecking=yes
SCP_ARGS=-p -o FallBackToRsh=no  -o PasswordAuthentication=no  -o StrictHostKeyChecking=yes  
UNZIP_ARGS=-o
ZIP_ARGS=-r
ZIP_EXCLUDE_ARGS=-x
ZIP_INCLUDE_ARGS=-i

sPaths.properties

This is a UNIX-specific file.

# Copyright (c) 2006, Oracle. All rights reserved.  
 
TRUE=/bin/true
SSH_PATH=/usr/bin/ssh
SCP_PATH=/usr/bin/scp
RSH_PATH=/usr/bin/rsh
RCP_PATH=/usr/bin/rcp
RCP_ARGS=-p
SH_PATH=/bin/sh
SH_ARGS=-c
KSH_PATH=/usr/bin/ksh
PING_ARGS=-c 1 -w
PING_PATH=/bin/ping
ZIP_PATH=/usr/bin/zip
UNZIP_PATH=/usr/bin/unzip
TAR_PATH=/bin/tar
TAR_CREATE_ARGS=cvf
TAR_EXTRACT_ARGS=xvfm
TAR_EXCLUDE_ARGS=-X
TAR_INCLUDE_ARGS=-T
TAR_MTIME_ARGS=-m
CAT_PATH=/bin/cat
CP_PATH=/bin/cp
CP_ARGS=-p
MV_PATH=/bin/mv
MV_ARGS=-f
MKDIR_PATH=/bin/mkdir
MKDIR_ARGS=-p
RMDIR_PATH=/bin/rmdir
RMDIR_PARENTS_ARGS=-p
RMDIR_ARGS=--ignore-fail-on-non-empty
RM_PATH=/bin/rm
RM_F_ARGS=-f
RM_RF_ARGS=-rf
LN_PATH=/bin/ln
LN_ARGS=-fs
XARGS_PATH=/usr/bin/xargs
LS_PATH=/bin/ls
LS_ARGS=-A
CHMOD_PATH=/bin/chmod
CHOWN_PATH=/bin/chown
DF_PATH=/bin/df
DF_ARGS=-k
DF_COL_NAME=Available
SUDO_PATH=/usr/local/bin/sudo
SUDO_K_ARGS=-K
SUDO_S_ARGS=-S
TOUCH_PATH=/bin/touch
HOSTNAME_PATH=/bin/hostname
HOSTNAME_ARGS=-f
DATE_PATH=/bin/date
DATE_ARGS=+%s
SSH_KEYGEN_PATH=/usr/bin/ssh-keygen
SSH_KEYGEN_ARGS=-t rsa
SSH_KEYGEN_ARGS_KEYFILE=-f
SSH_KEYGEN_ARGS_PASSPHRASE=-N
SSH_HOST_KEY_LOC=/etc/ssh
PATH_EXISTS_FLAG=-e
FILE_EXISTS_FLAG=-f
DIR_EXISTS_FLAG=-d
DIR_WRITABLE_FLAG=-w
SLINK_EXISTS_FLAG=-h
SCRATCHPATH=/tmp
 
#{0} REMOTESHELL
#{1} NODE
#{2} LOGINSHELL
#{3} CMD
 
#KEY0=$REMOTESHELL $NODE $LOGINSHELL '$CMD;echo :EXITCODE:$? '
KEY0={0} {1} {2} ''{3};echo :EXITCODE:$? ''
#KEY1=$REMOTESHELL $NODE $LOGINSHELL '$CMD'
KEY1={0} {1} {2} ''{3}''
#KEY2=$LOGINSHELL '$CMD'
KEY2={2} ''{3}''
#KEY3=$REMOTESHELL $NODE $CMD
KEY3={0} {1} {3}
#KEY4=$LOGINSHELL '$CMD NODE'
KEY4={2} ''{3} {1}''
 
 
#{0} REMOTESHELLPATH
#{1} REMOTESHELLARGS
#{2} NODE
#{3} LOGINSHELLPATH
#{4} LOGINSHELLARGS
#{5} CMD
 
#KEY10=$REMOTESHELLPATH#$REMOTESHELLARGS#NODE#$LOGINSHELLPATH#$LOGINSHELLARGS#''$CMD;echo :EXITCODE:$?''
KEY10={0}#{1}#{2}#{3}#{4}#''{5};echo :EXITCODE:$?''
 
#KEY11=$REMOTESHELLPATH#$REMOTESHELLARGS#NODE#$LOGINSHELLPATH#$LOGINSHELLARGS#''$CMD''
KEY11={0}#{1}#{2}#{3}#{4}#''{5}''
 
#KEY12=$LOGINSHELLPATH#$LOGINSHELLARGS#''$CMD''
KEY12={3}#{4}#''{5}''
 
#KEY13=$REMOTESHELLPATH#$REMOTESHELLARGS#$NODE#$CMD
KEY13={0}#{1}#{2}#{5}
 
#KEY15=$REMOTESHELLPATH#$REMOTESHELLARGS#NODE#$LOGINSHELLPATH#$LOGINSHELLARGS#$CMD
KEY15={0}#{1}#{2}#{3}#{4}#{5}
 
#{0} ENV
#{1} PATH
#{2} ARGS
#{3} LOGINSHELL
#{4} FLAGS
 
#CMD0=$PATH $ARGS
CMD0={1} {2}
 
#CMD1=$ENV $PATH $ARGS
CMD1={0} {1} {2}
 
#CMD2=if [[ $FLAGS $PATH ]] ; then exit 0; else exit 1; fi
CMD2=if [[ {4} {1} ]] ; then exit 0; else exit 1; fi
 
#CMD3=if [[ $FLAGS $PATH ]] ; then echo :EXITCODE:0; else echo :EXITCODE:1; fi
CMD3=if [[ {4} {1} ]] ; then echo :EXITCODE:0; else echo :EXITCODE:1; fi
 
#CMD4=$PATH $ARGS $LOGINSHELL '$ENV $PATH $ARGS'
CMD4={0} {1} {2} ''{3} {4} {5}''
 
#CMD5=$PATH $ARGS $LOGINSHELL '$ENV $PATH $ARGS'
CMD5={0} {1} {2} ''{3} {4} {5};echo :EXITCODE:$?''
 
#CMD2=$CMD1 && $CMD1
#CMD2={0} {1} {2}
#CMD3=$CMD1 $LOGINSHELL $CMD1
#CMD6=( $CMD1 && $CMD1 )
#CMD7= $CMD1 | $CMD1

ssPaths_sol.properties (Solaris-specific file)

# Copyright (c) 2005, Oracle. All rights reserved.  
 
SH_PATH=/bin/bash
SH_ARGS=-c
KSH_PATH=/usr/bin/ksh
RMDIR_ARGS=
#the date should be in the format of year:month:date:hour:minute:second
DATE_ARGS=-u +%y:%m:%d:%H:%M:%S
PING_PATH=/usr/sbin/ping
PING_ARGS=
SSH_PATH=/usr/local/bin/ssh
SSH_KEYGEN_PATH=/usr/local/bin/ssh-keygen
SCP_PATH=/usr/local/bin/scp
TAR_EXCLUDE_ARGS=X
TAR_INCLUDE_ARGS=-I
DF_COL_NAME=avail
SSH_HOST_KEY_LOC=/usr/local/etc

ssPaths_msplats.properties (Microsoft Windows-specific file)

# Copyright (c) 2005, 2006, Oracle. All rights reserved.  
 
FALSE=C:/cygwin/bin/false.exe
#SSH_PATH=C:\\Program Files\\OpenSSH\\bin\\ssh.exe
#SCP_PATH=C:\\Program Files\\OpenSSH\\bin\\scp.exe
SSH_PATH=C:/cygwin/bin/ssh.exe
SCP_PATH=C:/cygwin/bin/scp.exe
PING_ARGS=-n 5 -w
PING_PATH=C:\\WINDOWS\\system32\\ping.exe
LS_PATH=C:/cygwin/bin/ls.exe
LS_ARGS=-A
MKDIR_PATH=C:/cygwin/bin/mkdir.exe
MKDIR_ARGS=-p
ZIP_PATH=C:/cygwin/bin/zip.exe
UNZIP_PATH=C:/cygwin/bin/unzip.exe
DATE_PATH=cmd.exe /c date
DATE_ARGS=/T
TIME_PATH=cmd.exe /c time
TIME_ARGS=/T
TOUCH_PATH=C:/cygwin/bin/touch.exe
HOSTNAME_PATH=C:/WINDOWS/system32/hostname.exe
MV_PATH=cmd.exe /c move
MV_ARGS=/Y
#MV_PATH=C:/cygwin/bin/mv.exe
#MV_ARGS=
SH_PATH=
SH_ARGS=
RMDIR_PATH=cmd.exe /c rmdir
#RM_PATH=C:/cygwin/bin/rm.exe
#RM_F_ARGS=-f
#RM_RF_ARGS=-rf
RM_PATH=cmd.exe /c del
RM_F_ARGS=/F /Q
RM_RF_ARGS=/S /Q
RM_ERR1=Could not find
CHMOD_PATH=C:/cygwin/bin/chmod.exe
CHOWN_PATH=C:/cygwin/bin/chown.exe
CP_PATH=cmd.exe /c copy
CP_ARGS=/Y
PATH_EXISTS_FLAG=-e
FILE_EXISTS_FLAG=-f
DIR_EXISTS_FLAG=-d
DIR_WRITABLE_FLAG=-w
SCRATCHPATH=C:/tmp
MORE_PATH=cmd.exe /c more
SHELL_PATH=C:/cygwin/bin/sh.exe
SHELL_ARGS=-c
CMD_PATH=C:/WINDOWS/system32/cmd.exe
CMD_ARGS=/c
SSH_HOST_KEY_LOC=C:/Program Files/OpenSSH/etc
 
#{0} REMOTESHELLPATH
#{1} REMOTESHELLARGS
#{2} NODE
#{3} LOGINSHELLPATH
#{4} LOGINSHELLARGS
#{5} CMD
 
#KEY1=$REMOTESHELLPATH#$REMOTESHELLARGS#NODE#$CMD
#KEY1={0}#{1}#{2}#\"{5}\"
KEY11={0}#{1}#{2}#{5}
 
#{0} ENV
#{1} PATH
#{2} ARGS
#{3} LOGINSHELL
#{4} FLAGS
 
#CMD2=if [ $FLAGS $PATH ] ; then exit 0; else exit 1; fi
CMD2=if [ {4} {1} ] ; then exit 0; else exit 1; fi