E How to Complete Installation Prerequisite Tasks Manually

E.1.1 Checking Existing SSH Configuration on the System

To determine if SSH is running, enter the following command:

$ pgrep sshd

If SSH is running, then the response to this command is one or more process ID numbers. In the home directory of the installation software owner (grid, oracle), use the command ls -al to ensure that the .ssh directory is owned and writable only by the user.

You need either an RSA or a DSA key for the SSH protocol. RSA is used with the SSH 1.5 protocol, while DSA is the default for the SSH 2.0 protocol. With OpenSSH, you can use either RSA or DSA. The instructions that follow are for SSH1. If you have an SSH2 installation, and you cannot use SSH1, then refer to your SSH distribution documentation to configure SSH1 compatibility or to configure SSH2 with DSA.

E.1.2 Configuring SSH on Cluster Nodes

To configure SSH, you must first create RSA or DSA keys on each cluster node, and then copy all the keys generated on all cluster node members into an authorized keys file that is identical on each node. Note that the SSH files must be readable only by root and by the software installation user (oracle, grid), as SSH ignores a private key file if it is accessible by others. In the examples that follow, the DSA key is used.

You must configure SSH separately for each Oracle software installation owner that you intend to use for installation.

To configure SSH, complete the following:

E.1.3 Enabling SSH User Equivalency on Cluster Nodes

After you have copied the authorized_keys file that contains all keys to each node in the cluster, complete the following procedure, in the order listed. In this example, the Oracle Grid Infrastructure software owner is named grid:

1. On the system where you want to run OUI, log in as the grid user.

2. Use the following command syntax, where hostname1, hostname2, and so on, are the public host names (alias and fully qualified domain name) of nodes in the cluster to run SSH from the local node to each node, including from the local node to itself, and from each node to each other node:

   [grid@nodename]$ ssh hostname1 date
   [grid@nodename]$ ssh hostname2 date
       .
       .
       .
   

   For example:

   [grid@node1 grid]$ ssh node1 date
   The authenticity of host 'node1 (xxx.xxx.100.101)' can't be established.
   DSA key fingerprint is 7z:60:60:zz:48:48:z1:a0:f7:4e.
   Are you sure you want to continue connecting (yes/no)? yes
   Warning: Permanently added 'node1,xxx.xxx.100.101' (DSA) to the list of
   known hosts.
   Mon Dec 4 11:08:13 PST 2006
   [grid@node1 grid]$ ssh node1.example.com date
   The authenticity of host 'node1.example.com (xxx.xxx.100.101)' can't be
   established.
   DSA key fingerprint is 7z:60:60:zz:48:48:z1:a0:f7:4e.
   Are you sure you want to continue connecting (yes/no)? yes
   Warning: Permanently added 'node1.example.com,xxx.xxx.100.101' (DSA) to the
   list of known hosts.
   Mon Dec 4 11:08:13 PST 2006
   [grid@node1 grid]$ ssh node2 date
   Mon Dec 4 11:08:35 PST 2006
   .
   .
   .
   

   At the end of this process, the public host name for each member node should be registered in the known_hosts file for all other cluster nodes.

   If you are using a remote client to connect to the local node, and you see a message similar to "Warning: No xauth data; using fake authentication data for X11 forwarding," then this means that your authorized keys file is configured correctly, but your SSH configuration has X11 forwarding enabled. To correct this issue, proceed to "Setting Display and X11 Forwarding Configuration".

3. Repeat step 2 on each cluster node member.

If you have configured SSH correctly, then you can now use the ssh or scp commands without being prompted for a password. For example:

[grid@node1 ~]$ ssh node2 date
Mon Feb 26 23:34:42 UTC 2009
[grid@node1 ~]$ ssh node1 date
Mon Feb 26 23:34:48 UTC 2009

If any node prompts for a password, then verify that the ~/.ssh/authorized_keys file on that node contains the correct public keys, and that you have created an Oracle software owner with identical group membership and IDs.

E.2.1 Minimum Parameter Settings for Installation

During installation, or when you run the Cluster Verification Utility (cluvfy) with the flag -fixup, a fixup script is generated. This script updates required kernel packages if necessary to minimum values.

If you cannot use the fixup scripts, then review the following table to set values manually:

E.2.2 Additional Parameter and Kernel Settings for SUSE Linux

On SUSE systems only, complete the following steps as needed:

1. Enter the following command to cause the system to read the /etc/sysctl.conf file when it restarts:

   # /sbin/chkconfig boot.sysctl on
   

2. On SUSE 10 systems only, use a text editor to change the /etc/sysconfig/boot.sysctl parameter RUN_PARALLEL flag from yes to no.

3. Enter the GID of the oinstall group as the value for the parameter /proc/sys/vm/hugetlb_shm_group. Doing this grants members of oinstall a group permission to create shared memory segments.

   For example, where the oinstall group GID is 501:

   # echo 501 > /proc/sys/vm/hugetlb_shm_group
   

   After running this command, use vi to add the following text to /etc/sysctl.conf, and enable the boot.sysctl script to run on system restart:

   vm.hugetlb_shm_group=501
   

   Note:

   Only one group can be defined as the vm.hugetlb_shm_group.

4. Repeat steps 1 through 3 on all other nodes in the cluster.