This appendix describes the prerequisites to performing an installation using the Agent Deploy application. It contains the following sections:
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.
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 |
|
0.85 GB |
Solaris 5.9 SPARC |
|
0.85 GB |
|
Solaris 5.10 SPARC |
SUNWbtool |
0.85 GB |
|
HP-UX |
HP-UX 11.11 PA-RISC2.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 |
|
0.75 GB |
Red Hat Enterprise Linux AS/ES 4.0 ia 64 |
|
0.75 GB |
|
SUSE Linux Enterprise Server 9 ia 64 |
|
0.75 GB |
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.
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 ofvar=value
.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 (" ").-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 CygwinBASH
shell. This script will fail to execute if run from outside this location.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
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:
On host A, touch ~user1/checkSharedHome.tmp
.
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.
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.
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:
Right-click on My Computer and go to Properties.
In the System Properties window that appears, click Advanced.
In this tab, click Environment Variables.
Here, search for the Path system variable, select it, and if the OpenSSH\bin
and mksnt
are present in the PATH, click Edit.
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:
Right-click on My Computer, and select Manage.
In the Computer Management window that appears, go to Services under Services and Applications.
In the right-pane, select the SSH daemon service and click the Stop Service icon.
Note:
Ensure you rename the installation directories ofOpenSSH
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 thanC:\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:
Zip, unzip binaries from the Archive package.
OpenSSH and dependencies (automatically selected if you choose OpenSSH) from the Net package.
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, enterbinmode 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:
Right-click on My Computer, and select Manage.
In the Computer Management dialog box that appears, go to Services and Applications, and select CYGWIN sshd.
Right-click CYGWIN sshd and select Properties.
In the Properties dialog box, go to the Log On tab.
Here, specify the domain/username and password. Click Apply.
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
Start the SSH daemon by executing:
/usr/sbin/sshd
Alternatively, from the same BASH prompt, you can also execute:
cygrunsrv -S sshd
Note:
Usecygrunsrv -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.
Note:
Before executing thesshUserSetupNT.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 theSSHUserSetupNT.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 thesshUserSetupNT.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 thatC:/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\/
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 -homeDir
m 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 thesshUserSetupNT.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.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:
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'
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:
Ifsshd
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.
For dropping SSH connection for 10.2.0.1 and 10.2.0.2 release, do the following on the Oracle Management Service machine:
For UNIX operating systems, remove the $HOME/.ssh folder (use the rm -rf $HOME/.ssh command). In the 10.2.0.1 release, $HOME is the home directory of the user who runs sshConnectivity.sh/sshUserSetup.sh.
For Windows operating systems, in the cygwin bash prompt, go to $HOME folder (use the cd $HOME command).
Note:
If $HOME value has spaces, for example, C:\Documents and Settings\foo\, make sure that you type the value of $HOME in double-quotes. For example:cd "C:\Documents and Settings\foo"
Remove the .ssh folder as follows:
rm -rf .ssh
Navigate to C:\cygwin, which is the default folder where agentpush assumes you installed cygwin. If cygwin is installed in folder X, go to folder X. Remove the .ssh folder.
Note:
The sub-key value of ' SOFTWARE->Cygnus Solutions->Cygwin -> mounts v2->/' is the installation directory of cygwin, by default. If you have changed it manually, go to that folder and remove the .ssh folder.For Enterprise Manager 10.2.0.3.0 or higher, SSH is setup and dropped by the application itself. Dropping the SSH setup will bring back the previous existing setup, if any.
If SSH was set up by the user, by running sshConnectivity.sh and the application has used this existing setup, the user will need to follow the steps explained above for dropping SSH connection for 10.2.0.1 and 10.2.0.2 release. Dropping the SSH setup will not bring back any existing SSH setup.
To check if SSH connection is removed, do the following:
Run the following command on the Oracle Management Service machine:
ssh -l username <remote node> date sshConnectivity.sh/sshUserSetup.sh/sshUserSetupNT.sh
where username is the value of the -user option used while running and remote node is one of the nodes used in the -hosts argument while running. For example:
sshConnectivity.sh/sshUserSetup.sh/sshUserSetupNT.sh This command should NOT show date output. This command must stop for password conformation to proceed. For Example: $ssh -l john mybox.mydomain.com 'date' The authenticity of host 'mybox.mydomain.com (111.222.333.444)' can't be established. RSA key fingerprint is ec:52:5d:63:bc:85:07:ef:fe:5b:74:d3:6b:18:04:1c. Are you sure you want to continue connecting (yes/no)?
The above message ensures that the SSH connection is dropped from the Oracle Management Service to the remote node.
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 thecygwin
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 theses*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
.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
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.
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.
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 theoraInventory
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.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.
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.
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. |
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 ( |
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, |
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 |
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.
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 ActionFoot 1 |
---|---|---|
Nodes are active |
Nodes are not accessible. |
|
SSH Server is up |
SSH daemon on one or more nodes is not up. |
|
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. |
|
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. |
|
Footnote 1 Where there are multiple user actions listed, you can choose to perform the action that is most appropriate.
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 ActionFoot 1 |
---|---|---|
Certified Versions |
The failed host may have an operating system or version that is not certified to deploy the agent on that machine. |
|
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. |
|
Agent Targets |
The failed nodes may have some targets that were installed by a different user, and hence cannot be monitored by the agent. |
|
Port |
|
|
Oracle Home Location |
The |
|
Existing Agent Installations |
An agent already exists on the failed remote hosts that is registered with the central inventory. |
|
Write Permissions for Base Directory |
The installation base directory is not writable. |
|
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:
|
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. |
|
NFS Agent Existence Check |
An agent already exists on the remote hosts that is registered with the central inventory. |
|
Write Permissions 'for NFS Agent |
|
|
Time Zone ENV Check |
The TZ environment variable is not set on the remote hosts. |
Recommended
Optional
|
Software Existence Check |
The alternative software location that you have specified is not valid. |
|
Footnote 1 Where there are multiple user actions listed, you can choose to perform the action that is most appropriate.
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 |
A sample of each property file in the platforminfo.properties
file is provided as follows:
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
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
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