2 Advanced Installation Oracle Grid Infrastructure for a Cluster Preinstallation Tasks

2.1.1 Completing a Minimal Linux Installation

To complete a minimal Linux installation, select a minimal install option (either a custom installation where you select the Minimal option from Package Group Selection, or where you deselect all packages except for the Base pack). This installation lacks many RPMs required for installation. However, when you install the Oracle Validated RPM for your platform, the RPM downloads the minimum number of packages required to run Oracle Clusterware and Oracle Database.

Unbreakable Linux Network (ULN) customers can obtain the Oracle Validated RPM by using up2date. If you are not a ULN customer, and your operating system is Red Hat or Oracle Enterprise Linux, then you can obtain the Oracle Validated RPM at the following URLs:

Enterprise Linux 4:

http://oss.oracle.com/el4/oracle-validated/

Enterprise Linux 5:

http://oss.oracle.com/el5/oracle-validated/

SSH is required for Oracle grid infrastructure installation. OpenSSH should be included in the Linux distribution minimal installation. To confirm that SSH packages are installed, enter the following command:

# rpm -qa |grep ssh

If you do not see a list of SSH packages, then install those packages for your Linux distribution.

2.1.2 Completing a Default Linux Installation

If you do not install the Oracle Validated RPM, then Oracle recommends that you install your Linux operating system with the default software packages (RPMs). This installation includes most of the required packages and helps you limit manual checks of package dependencies. Oracle recommends that you do not customize the RPMs during installation.

For information about a default installation, log on to My Oracle Support:

https://metalink.oracle.com

Search for "Default RPM."

After installation, review system requirements for your distribution to ensure that you have all required kernel packages installed, and complete all other configuration tasks required for your distribution, and for your system configuration.

2.1.3 About the Oracle Validated Configuration RPM

If your Linux distribution is Oracle Enterprise Linux, or Red Hat Enterprise Linux, and you are an Unbreakable Linux customer, then you can complete most preinstallation configuration tasks by using the Oracle Validated Configurations Setup RPM, available from the Unbreakable Linux Network (ULN).

When it is installed, the Oracle Validated Configuration RPM does the following:

• Automatically installs any additional packages needed for installing Oracle grid infrastructure and Oracle Database

• Creates an oracle user, and creates the oraInventory (oinstall) and OSDBA (dba) groups for that user

• Sets and verifies sysctl.conf settings, system startup parameters, user limits, and driver parameters to values based on recommendations from the Oracle Validated Configurations program

To become an Oracle Unbreakable Linux customer, contact your sales representative, or purchase a license from the Unbreakable Linux store:

http://oraclestore.oracle.com/linux

To register your server on the Unbreakable Linux Network, or to find out more information, refer to the following URL:

https://linux.oracle.com

If you are using Oracle Enterprise Linux 4.7 and higher, or Oracle Enterprise Linux 5.2 and higher, then the Oracle Validated RPM is included on the install media.

2.1.4 Installing the Oracle Validated Configuration RPM

Use the following procedure to subscribe to Oracle Unbreakable Linux channels, and to add the Oracle Software for Enterprise Linux channel that distributes the Oracle Validated Configurations Setup RPM:

1. Complete a default Oracle Enterprise Linux workstation installation, or a default Red Hat Enterprise Linux installation.

2. Register your server with Unbreakable Linux Network (ULN). By default, you are registered for the Enterprise Linux Latest channel for your operating system and hardware.

3. Log in to ULN at the following URL:

   https://linux.oracle.com

4. Click the Systems tab, and in the System Profiles list, select a registered server. The System Details window opens, and displays the subscriptions for the server.

5. From the Available Channels list, select the Oracle Software for Enterprise Linux channel that is appropriate for your installation of Linux (for example: "Oracle Software for Enterprise Linux 4 (x86_64)."

6. Click Subscribe.

7. From a terminal session, as root, enter the following command:

   # up2date --nox --show-channels
   

   You should see output indicating that you have subscribed to the Oracle Software for Enterprise Linux channel. For example:

   el4_i386_latest
   el4_i386_oracle
   

8. Open a terminal session as root, and install the Oracle Validated Configurations Setup RPM with up2date, using the following command:

   # up2date --install oracle-validated
   

9. Repeat steps 1 through 8 on all other servers in your cluster.

   Note:

   Check the Oracle Validated Configuration RPM log file to review system configuration changes:

   /etc/sysconfig/oracle-validated/results/orakernel.log
   

2.5.1 Determining If the Oracle Inventory and Oracle Inventory Group Exists

When you install Oracle software on the system for the first time, OUI creates the oraInst.loc file. This file identifies the name of the Oracle Inventory group (by default, oinstall), and the path of the Oracle Central Inventory directory. An oraInst.loc file has contents similar to the following:

inventory_loc=central_inventory_location
inst_group=group

In the preceding example, central_inventory_location is the location of the Oracle central inventory, and group is the name of the group that has permissions to write to the central inventory (the OINSTALL group privilege).

If you have an existing Oracle central inventory, then ensure that you use the same Oracle Inventory for all Oracle software installations, and ensure that all Oracle software users you intend to use for installation have permissions to write to this directory.

To determine if you have an Oracle central inventory directory (oraInventory) on your system:

Enter the following command:

# more /etc/oraInst.loc

If the oraInst.loc file exists, then the output from this command is similar to the following:

inventory_loc=/u01/app/oracle/oraInventory
inst_group=oinstall

In the previous output example:

• The inventory_loc group shows the location of the Oracle Inventory

• The inst_group parameter shows the name of the Oracle Inventory group (in this example, oinstall).

Use the command grep groupname /etc/group to confirm that the group specified as the Oracle Inventory group still exists on the system. For example:

$ grep oinstall /etc/group
oinstall:x:1000:crs,oracle

2.5.2 Creating the Oracle Inventory Group If an Oracle Inventory Does Not Exist

If the oraInst.loc file does not exist, then create the Oracle Inventory group by entering a command similar to the following:

# /usr/sbin/groupadd -g 1000 oinstall

The preceding command creates the group oinstall, with the group ID number 1000. Members of the OINSTALL group are granted privileges to write to the Oracle central inventory (oraInventory).

By default, if an oraInventory group does not exist, then the installer lists the primary group of the installation owner for the grid infrastructure for a cluster as the oraInventory group. Ensure that this group is available as a primary group for all planned Oracle software installation owners.

2.5.3 Creating the Oracle Grid Infrastructure User

You must create a software owner for Oracle grid infrastructure in the following circumstances:

• If an Oracle software owner user does not exist; for example, if this is the first installation of Oracle software on the system

• If an Oracle software owner user exists, but you want to use a different operating system user, with different group membership, to separate grid infrastructure administrative privileges from Oracle Database administrative privileges.

  In Oracle documentation, a user created to own only Oracle grid infrastructure software installations is called the grid user. A user created to own either all Oracle installations, or only Oracle database installations, is called the oracle user.

# id oracle

uid=501(oracle) gid=501(oinstall) groups=502(dba),503(oper)

2.5.4 Creating the Oracle Base Directory Path

The Oracle base directory for the grid installation owner is the location where diagnostic and administrative logs, and other logs associated with Oracle ASM and Oracle Clusterware are stored.

If you have created a path for the Oracle Clusterware home that is compliant with Oracle Optimal Flexible Architecture (OFA) guidelines for Oracle software paths then you do not need to create an Oracle base directory. When OUI finds an OFA-compliant path, it creates the Oracle base directory in that path.

For OUI to recognize the path as an Oracle software path, it must be in the form u0[1-9]/app, and it must be writable by any member of the oraInventory (oinstall) group. The Optimal Flexible Architecture path for the Oracle base is /u01/app/user, where user is the name of the Oracle software installation owner.

Oracle recommends that you create an Oracle base path manually, particularly if you have separate grid infrastructure for a cluster and Oracle Database software owners, so that you can separate log files.

For example:

# mkdir -p  /u01/app/grid
# chown -R grid:oinstall /u01/app/grid
# chmod -R 775 /u01/app/grid
# mkdir -p /u01/app/oracle
# chown -R oracle:oinstall /u01/app/oracle

2.5.5 Creating Job Role Separation Operating System Privileges Groups and Users

A Job Role Separation privileges configuration of Oracle ASM is a configuration with groups and users that divide administrative access privileges to the Oracle ASM installation from other administrative privileges users and groups associated with other Oracle installations. Administrative privileges access is granted by membership in separate operating system groups, and installation privileges are granted by using different installation owners for each Oracle installation.

If you prefer, you can allocate operating system user privileges so that you can use one administrative user and one group for operating system authentication for all system privileges on the storage and database tiers.

For example, you can designate the oracle user to be the installation owner for all Oracle software, and designate oinstall to be the group whose members are granted all system privileges for Oracle Clusterware, Automatic Storage Management, and all Oracle Databases on the servers, and all privileges as installation owners. This group must also be the Oracle Inventory group.

Oracle recommends that you use at least two groups: A system privileges group whose members are granted administrative system privileges, and an installation owner group (the oraInventory group) to provide separate installation privileges the OINSTALL privilege. To simplify using the defaults for Oracle tools such as Cluster Verification Utility, if you do choose to use a single operating system group to grant all system privileges and the right to write to the oraInventory, then that group name should be oinstall.

• Overview of Creating Job Role Separation Groups and Users

• Creating Database Groups and Users with Job Role Separation

# /usr/sbin/groupadd -g 1200 dba

# /usr/sbin/groupadd -g 1201 oper

# /usr/sbin/groupadd -g 1000 asmadmin

# /usr/sbin/groupadd -g 1301 asmoper

# /usr/sbin/groupadd -g 1300 asmdba

# id oracle

uid=501(oracle) gid=501(oinstall) groups=502(dba),503(oper)

# /usr/sbin/usermod -g oinstall -G dba,asmdba oracle

2.5.6 Example of Creating Standard Groups, Users, and Paths

The following is an example of how to create the Oracle Inventory group (oinstall), and a single group (dba) as the OSDBA, OSASM and OSDBA for ASM groups. In addition, it shows how to create the grid infrastructure software owner (grid), and one Oracle Database owner (oracle) with correct group memberships. This example also shows how to configure an Oracle base path compliant with OFA structure with correct permissions:

# groupadd -g 1000 oinstall
# groupadd -g 1200 dba
# useradd -u 1100 -g oinstall -G dba grid
# useradd -u 1101 -g oinstall -G dba oracle
# mkdir -p  /u01/app/11.2.0/grid
# chown -R grid:oinstall /u01
# mkdir /u01/app/oracle
# chown oracle:oinstall /u01/app/oracle
# chmod -R 775 /u01/

After running these commands, you have the following groups and users:

• An Oracle central inventory group, or oraInventory group (oinstall). Members who have the central inventory group as their primary group, are granted the OINSTALL permission to write to the oraInventory directory.

• A single system privileges group that is used as the OSASM, OSDBA, OSDBA for ASM, and OSOPER for ASM group (dba), whose members are granted the SYSASM and SYSDBA privilege to administer Oracle Clusterware, Oracle ASM, and Oracle Database, and are granted SYSASM and OSOPER for ASM access to the Oracle ASM storage.

• An Oracle grid installation for a cluster owner (grid), with the oraInventory group as its primary group, and with the OSASM group as the secondary group.

• An Oracle Database owner (oracle) with the oraInventory group as its primary group, and the OSDBA group as its secondary group.

• /u01/app owned by grid:oinstall with 775 permissions. This ownership and permissions enables OUI to create the Oracle Inventory directory, in the path /u01/app/oraInventory.

• /u01 owned by root.

• /u01/app/11.2.0/grid owned by grid:oinstall with 775 permissions. These permissions are required for installation, and are changed during the installation process.

• /u01/app/oracle owned by oracle:oinstall with 775 permissions.

2.5.7 Example of Creating Role-allocated Groups, Users, and Paths

The following is an example of how to create role-allocated groups and users that is compliant with an Optimal Flexible Architecture (OFA) deployment:

# groupadd -g 1000 oinstall
# groupadd -g 1100 asmadmin
# groupadd -g 1200 dba1
# groupadd -g 1250 dba2
# groupadd -g 1300 asmdba
# groupadd -g 1301 asmoper
# useradd -u 1100 -g oinstall -G asmadmin,asmdba,asmoper grid
# useradd -u 1101 -g oinstall -G dba1,asmdba oracle1
# useradd -u 1102 -g oinstall -G dba2,asmdba oracle2
# mkdir -p /u01/app/grid
# mkdir -p  /u01/app/11.2.0/grid
# chown -R grid:oinstall /u01
# mkdir -p /u01/app/oracle1
# chown oracle1:oinstall /u01/app/oracle1
# mkdir -p /u01/app/oracle2
# chown oracle2:oinstall /u01/app/oracle2
# chmod -R 775 /u01

After running these commands, you have the following groups and users:

• An Oracle central inventory group, or oraInventory group (oinstall), whose members that have the central inventory group as their primary group are granted permissions to write to the oraInventory directory.

• A separate OSASM group (asmadmin), whose members are granted the SYSASM privilege to administer Oracle Clusterware and Oracle ASM.

• A separate OSDBA for ASM group (asmdba), whose members include grid, oracle1 and oracle2, and who are granted access to Oracle ASM.

• A separate OSOPER for ASM group (asmoper), whose members include grid, and who are granted limited Oracle ASM administrator privileges, including the permissions to start and stop the Oracle ASM instance.

• An Oracle grid installation for a cluster owner (grid), with the oraInventory group as its primary group, and with the OSASM (asmadmin), OSDBA for ASM (asmdba) and OSOPER for ASM groups as secondary groups.

• Two separate OSDBA groups for two different databases (dba1 and dba2) to establish separate SYSDBA privileges for each database.

• Two Oracle Database software owners (oracle1 and oracle2), to divide ownership of the Oracle database binaries, with the OraInventory group as their primary group, and the OSDBA group for their database (dba1 or dba2) and the OSDBA for ASM group (asmdba) as their secondary groups.

• An OFA-compliant mount point /u01 owned by grid:oinstall before installation.

• An Oracle base /u01/app/oracle1 owned by oracle1:oinstall with 775 permissions.

• An Oracle base /u01/app/oracle 2 owned by oracle2:oinstall with 775 permissions.

• A Grid home /u01/app/11.2.0/grid owned by grid:oinstall with 775 (drwxdrwxr-x) permissions. These permissions are required for installation, and are changed during the installation process to root:oinstall with 755 permissions (drwxr-xr-x).

• An Oracle base for the grid installation owner /u01/app/grid owned by grid:oinstall with 775 permissions, and changed during the installation process to 755 permissions. The grid installation owner Oracle base directory is the location where Oracle ASM diagnostic and administrative log files are placed. During installation, OUI creates the Oracle Inventory directory, in the path /u01/app/oraInventory. This path remains owned by grid:oinstall, to enable other Oracle software owners to write to the central inventory.

2.7.1 Network Hardware Requirements

The following is a list of requirements for network configuration:

• Each node must have at least two network adapters or network interface cards (NICs): one for the public network interface, and one for the private network interface (the interconnect).

  To use multiple NICs for the public network or for the private network, Oracle recommends that you use NIC bonding. Use separate bonding for the public and private networks, because during installation each interface is defined as a public or private interface.

• The public interface names associated with the network adapters for each network must be the same on all nodes, and the private interface names associated with the network adaptors should be the same on all nodes.

  For example: With a two-node cluster, you cannot configure network adapters on node1 with eth0 as the public interface, but on node2 have eth1 as the public interface. Public interface names must be the same, so you must configure eth0 as public on both nodes. You should configure the private interfaces on the same network adapters as well. If eth1 is the private interface for node1, then eth1 should be the private interface for node2.

• For the public network, each network adapter must support TCP/IP.

• For the private network, the interconnect must support the user datagram protocol (UDP) using high-speed network adapters and switches that support TCP/IP (minimum requirement 1 Gigabit Ethernet).

  Note:

  UDP is the default interconnect protocol for Oracle RAC, and TCP is the interconnect protocol for Oracle Clusterware. You must use a switch for the interconnect. Oracle recommends that you use a dedicated switch.

  Oracle does not support token-rings or crossover cables for the interconnect.

• For the private network, the endpoints of all designated interconnect interfaces must be completely reachable on the network. There should be no node that is not connected to every private network interface. You can test if an interconnect interface is reachable using ping.

• During installation, you are asked to identify the planned use for each network interface that OUI detects on your cluster node. You must identify each interface as a public or private interface, and you must use the same private interfaces for both Oracle Clusterware and Oracle RAC.

  You can bond separate interfaces to a common interface to provide redundancy, in case of a NIC failure, but Oracle recommends that you do not create separate interfaces for Oracle Clusterware and Oracle RAC. If you use more than one NIC for the private interconnect, then Oracle recommends that you use NIC bonding. Note that multiple private interfaces provide load balancing but not failover, unless bonded.

  IP addresses on the subnet you identify as private are assigned as private IP addresses for cluster member nodes. You do not need to configure these addresses manually in a hosts directory.

2.7.2 IP Address Requirements

Before starting the installation, you must have at least two interfaces configured on each node: One for the private IP address and one for the public IP address.

You can configure IP addresses with one of the following options:

• Oracle Grid Naming Service (GNS) using a static public node address and dynamically allocated IPs for the Oracle Clusterware provided VIP addresses, DHCP server assigned, and resolved using a multicast domain name server configured as part of Oracle Clusterware within the cluster. If you plan to use GNS, then you must have the following:

  • A DHCP service running on the public network for the cluster

  • Enough addresses on the DHCP to provide 1 IP address for each node's virtual IP, and 3 IP addresses for the cluster used by the Single Client Access Name (SCAN) for the cluster

• Static addresses network administrators assign on a network domain name server (DNS) for each node. Selecting this option requires that you request network administration updates when you modify the cluster.

2.7.3 DNS Configuration for Domain Delegation to Grid Naming Service

If you plan to use GNS, then before grid infrastructure installation, you must configure your domain name server (DNS) to send to GNS name resolution requests for the subdomain GNS serves, which are the cluster member nodes.

You must configure the DNS to send GNS name resolution requests using delegation. Configure delegation using the following procedure:

1. In the DNS, create an entry for the GNS virtual IP address. For example:

   gns-server.clustername.com: 192.0.2.1
   

   The address you provide must be routable.

2. In the DNS, create an entry similar to the following for the delegated domain, where clusterdomain.example.com is the subdomain you want to delegate:

   clusterdomain.example.com: NS gns-server.clustername.com 
   

   When using GNS, you must configure the resolve.conf on the nodes in the cluster to contain name server entries that are resolvable to corporate DNS servers. The total timeout period configured—a combination of options attempts (retries) and options timeout (exponential backoff)—should be less than 30 seconds. For example, where xxx.xxx.xxx.42 and xxx.xxx.xxx.15 are valid name server addresses in your network, provide an entry similar to the following in /etc/resolv.conf:

   options attempts: 2
   options timeout: 1
   
   search clusterdomain.example.com example.com
   nameserver xxx.xxx.xxx.42
   nameserver xxx.xxx.xxx.15
   

   /etc/nsswitch.conf controls name service lookup order. In some system configurations, the Network Information System (NIS) can cause problems with Oracle SCAN address resolution. Oracle recommends that you place the nis entry at the end of the search list. For example:

   /etc/nsswitch.conf
        hosts:    files   dns   nis
   

2.7.4 Grid Naming Service Configuration Example

If you use GNS, then you need to specify a static IP address for the GNS VIP address, and delegate a subdomain to be delegated to that static GNS IP address.

As nodes are added to the cluster, your organization's DHCP server can provide addresses for these nodes dynamically. These addresses are then registered automatically in GNS, and GNS provides resolution within the subdomain to cluster node addresses registered with GNS.

Because allocation and configuration of addresses is performed automatically with GNS, no further configuration is required. Oracle Clusterware provides dynamic network configuration as nodes are added to or removed from the cluster. The following example is provided only for information.

With a two node cluster where you have defined the GNS VIP, after installation you might have a configuration similar to the following for a two-node cluster, where the cluster name is mycluster, the GNS parent domain is example.com, the subdomain is grid.example.com, 192.0.2 in the IP addresses represent the cluster public IP address network, and 192.168.0 represents the private IP address subnet:

^Footnote 1 Node hostnames may resolve to multiple addresses, including any private IP addresses or VIP addresses currently running on that host.

2.7.5 Manual IP Address Configuration Example

If you choose not to use GNS, then before installation you must configure public, virtual, and private IP addresses. Also, check that the default gateway can be accessed by a ping command. To find the default gateway, use the route command, as described in your operating system's help utility.

For example, with a two node cluster where each node has one public and one private interface, and you have defined a SCAN domain address to resolve on your DNS to one of three IP addresses, you might have the configuration shown in the following table for your network interfaces:

^Footnote 1 Node hostnames may resolve to multiple addresses.

You do not need to provide a private name for the interconnect. If you want name resolution for the interconnect, then you can configure private IP names in the hosts file or the DNS. However, Oracle Clusterware assigns interconnect addresses on the interface defined during installation as the private interface (eth1, for example), and to the subnet used for the private subnet.

The addresses to which the SCAN resolves are assigned by Oracle Clusterware, so they are not fixed to a particular node. To enable VIP failover, the configuration shown in the preceding table defines the SCAN addresses and the public and VIP addresses of both nodes on the same subnet, 192.0.2.

2.7.6 Network Interface Configuration Options

The precise configuration you choose for your network depends on the size and use of the cluster you want to configure, and the level of availability you require.

If certified Network-attached Storage (NAS) is used for Oracle RAC and this storage is connected through Ethernet-based networks, then you must have a third network interface for NAS I/O. Failing to provide three separate interfaces in this case can cause performance and stability problems under load.

2.7.7 Enabling the Name Service Cache Daemon

To prevent public network failures with Oracle RAC databases using NAS devices or NFS mounts, enable the Name Service Cache Daemon (nscd).

To check to see if nscd is set to load when the system is restarted, enter the command chkconfig --list nscd. For example:

# chkconfig --list nscd
nscd                      0:off  1:off  2:off  3:on   4:off  5:off   6:off 

In the preceding example, nscd is turned on for run level 3, and turned off for run level 5. The nsdc should be turned on for both run level 3 and run level 5.

To change the configuration to ensure that nsdc is on for both run level 3 and run level 5, enter one of the following command as root:

On Red Hat and Oracle Enterprise Linux 4 and 5:

# chkconfig --level 35 nscd on

On SUSE SLES10 and11:

# chkconfig --level 35 nscd on

To start up nscd in the current session, enter the command as root:

# service nscd start

To restart nscd with the new setting, enter the following command as root:

# service nscd restart

2.8.1 Software Requirements List for x86 (32-bit) Linux Platforms

For installations of Oracle grid infrastructure, ensure that you have the kernel versions and packages listed in Table 2-4 and Table 2-5.

If you intend to install Oracle Database or Oracle RAC in addition to Oracle grid infrastructure, then check Table 2-6 to determine if you must install additional packages for the features you plan to use.

binutils-2.15.92.0.2
compat-libstdc++-33.2.3
elfutils-libelf-0.97
elfutils-libelf-devel-0.97
gcc-3.4.6
gcc-c++-3.4.6
glibc-2.3.4-2.41
glibc-common-2.3.4
glibc-devel-2.3.4
glibc-headers-2.3.4
libaio-devel-0.3.105
libaio-0.3.105
libgcc-3.4.6
libstdc++-3.4.6
libstdc++-devel-3.4.6
make-3.80
pdksh-5.2.14
sysstat-5.0.5
unixODBC-2.2.11
unixODBC-devel-2.2.11

binutils-2.17.50.0.6
compat-libstdc++-33-3.2.3
elfutils-libelf-0.125
elfutils-libelf-devel-0.125
elfutils-libelf-devel-static-0.125
gcc-4.1.2
gcc-c++-4.1.2
glibc-2.5-24
glibc-common-2.5
glibc-devel-2.5
glibc-headers-2.5
kernel-headers-2.6.18
ksh-20060214
libaio-0.3.106
libaio-devel-0.3.106 
libgcc-4.1.2
libgomp-4.1.2
libstdc++-4.1.2 
libstdc++-devel-4.1.2
make-3.81
sysstat-7.0.2
unixODBC-2.2.11
unixODBC-devel-2.2.11

binutils-2.16.91.0.5
compat-libstdc++-5.0.7
gcc-4.1.2
gcc-c++-4.1.2
glibc-2.5-24
glibc-devel-2.4
ksh-93r-12.9
libaio-0.3.104
libaio-devel-0.3.104
libelf-0.8.5
libgcc-4.1.2
libstdc++-4.1.2
libstdc++-devel-4.1.2
make-3.80
sysstat-8.0.4

binutils-2.19
gcc-4.3
gcc-c++-4.3
glibc-2.9
glibc-devel-2.9
ksh-93t
libstdc++33-3.3.3
libstdc++43-4.3.3_20081022
libstdc++43-devel-4.3.3_20081022
libaio-0.3.104
libaio-devel-0.3.104
libgcc43-4.3.3_20081022
libstdc++-devel-4.3
make-3.81
sysstat-8.1.5

http://www.unixodbc.org

modinfo ocfs2

rpm -qa| grep ocfs2

http://oss.oracle.com/projects/ocfs2/

2.8.2 Software Requirements List for x86-64 Linux Platforms

For installations only of Oracle grid infrastructure, ensure that you have the kernel versions and packages listed in Table 2-7 and Table 2-8.

If you intend to install Oracle Database or Oracle RAC in addition to Oracle grid infrastructure, then check Table 2-9 to determine if you must install additional packages for the features you plan to use.

binutils-2.15.92.0.2
compat-libstdc++-33-3.2.3
compat-libstdc++-33-3.2.3 (32 bit)
elfutils-libelf-0.97
elfutils-libelf-devel-0.97
expat-1.95.7
gcc-3.4.6
gcc-c++-3.4.6
glibc-2.3.4-2.41
glibc-2.3.4-2.41 (32 bit)
glibc-common-2.3.4
glibc-devel-2.3.4
glibc-headers-2.3.4
libaio-0.3.105
libaio-0.3.105 (32 bit)
libaio-devel-0.3.105
libaio-devel-0.3.105 (32 bit)
libgcc-3.4.6
libgcc-3.4.6 (32-bit)
libstdc++-3.4.6
libstdc++-3.4.6 (32 bit)
libstdc++-devel 3.4.6
make-3.80
pdksh-5.2.14
sysstat-5.0.5
unixODBC-2.2.11
unixODBC-2.2.11 (32 bit)
unixODBC-devel-2.2.11
unixODBC-devel-2.2.11 (32 bit)

binutils-2.17.50.0.6
compat-libstdc++-33-3.2.3
compat-libstdc++-33-3.2.3 (32 bit)
elfutils-libelf-0.125
elfutils-libelf-devel-0.125
gcc-4.1.2
gcc-c++-4.1.2
glibc-2.5-24
glibc-2.5-24 (32 bit)
glibc-common-2.5
glibc-devel-2.5
glibc-devel-2.5 (32 bit)
glibc-headers-2.5
ksh-20060214
libaio-0.3.106
libaio-0.3.106 (32 bit)
libaio-devel-0.3.106
libaio-devel-0.3.106 (32 bit)
libgcc-4.1.2
libgcc-4.1.2 (32 bit)
libstdc++-4.1.2
libstdc++-4.1.2 (32 bit)
libstdc++-devel 4.1.2
make-3.81
sysstat-7.0.2
unixODBC-2.2.11
unixODBC-2.2.11 (32 bit)
unixODBC-devel-2.2.11
unixODBC-devel-2.2.11 (32 bit)

binutils-2.16.91.0.5
compat-libstdc++-5.0.7
gcc-4.1.0
gcc-c++-4.1.2
glibc-2.5-24
glibc-devel-2.4
glibc-devel-32bit-2.4
ksh-93r-12.9
libaio-0.3.104
libaio-32bit-0.3.104
libaio-devel-0.3.104
libaio-devel-32bit-0.3.104
libelf-0.8.5
libgcc-4.1.2
libstdc++-4.1.2
make-3.80
sysstat-8.0.4

binutils-2.19
gcc-4.3
gcc-32bit-4.3
gcc-c++-4.3
glibc-2.9
glibc-32bit-2.9
glibc-devel-2.9
glibc-devel-32bit-2.9
ksh-93t
libaio-0.3.104
libaio-32bit-0.3.104
libaio-devel-0.3.104
libaio-devel-32bit-0.3.104
libstdc++33-3.3.3
libstdc++33-32bit-3.3.3
libstdc++43-4.3.3_20081022
libstdc++43-32bit-4.3.3_20081022
libstdc++43-devel-4.3.3_20081022
libstdc++43-devel-32bit-4.3.3_20081022
libgcc43-4.3.3_20081022
libstdc++-devel-4.3
make-3.81
sysstat-8.1.5

http://www.unixodbc.org

unixODBC-2.2.11 (32 bit) or later
unixODBC-devel-2.2.11 (32 bit) or later

unixODBC-2.2.11 (32 bit) or later
unixODBC-devel-2.2.11 (32 bit) or later

modinfo ocfs2

rpm -qa| grep ocfs2

http://oss.oracle.com/projects/ocfs2/

http://oss.oracle.com/projects/ocfs2/

2.12.1 Requirements for Enabling IPMI

You must have the following hardware and software configured to enable cluster nodes to be managed with IPMI:

• Each cluster member node requires a Baseboard Management Controller (BMC) running firmware compatible with IPMI version 1.5 or greater, which supports IPMI over LANs, and configured for remote control using LAN.

• Each cluster member node requires an IPMI driver installed on each node.

• The cluster requires a management network for IPMI. This can be a shared network, but Oracle recommends that you configure a dedicated network.

• Each cluster member node's Ethernet port used by BMC must be connected to the IPMI management network.

• Each cluster member must be connected to the management network.

• Some server platforms put their network interfaces into a power saving mode when they are powered off. In this case, they may operate only at a lower link speed (for example, 100 MB, instead of 1 GB). For these platforms, the network switch port to which the BMC is connected must be able to auto-negotiate down to the lower speed, or IPMI will not function properly.

2.12.2 Configuring the IPMI Management Network

You can configure the BMC for DHCP, or for static IP addresses. Oracle recommends that you configure the BMC for dynamic IP address assignment using DHCP. To use this option, you must have a DHCP server configured to assign the BMC IP addresses.

2.12.3 Configuring the IPMI Driver

For Oracle Clusterware to communicate with the BMC, the IPMI driver must be installed permanently on each node, so that it is available on system restarts. The IPMI driver is available on the Asianux Linux, Oracle Enterprise Linux, Red Hat Enterprise Linux, and SUSE Enterprise Linux distributions supported with this release.

2.14.1 Environment Requirements for Oracle Grid Infrastructure Software Owner

You must make the following changes to configure the Oracle grid infrastructure software owner environment:

• Set the installation software owner user (grid, oracle) default file mode creation mask (umask) to 022 in the shell startup file. Setting the mask to 022 ensures that the user performing the software installation creates files with 644 permissions.

• Set ulimit settings for file descriptors and processes for the installation software owner (grid, oracle)

• Set the software owner's environment variable DISPLAY environment variables in preparation for the Oracle grid infrastructure installation

2.14.2 Procedure for Configuring Oracle Software Owner Environments

To set the Oracle software owners' environments, follow these steps, for each software owner (grid, oracle):

1. Start a new terminal session; for example, start an X terminal (xterm).

2. Enter the following command to ensure that X Window applications can display on this system:

   $ xhost + hostname
   

   The hostname is the name of the local host.

3. If you are not already logged in to the system where you want to install the software, then log in to that system as the software owner user.

4. If you are not logged in as the user, then switch to the software owner user you are configuring. For example, with the grid user:

   $ su - grid
   

5. To determine the default shell for the user, enter the following command:

   $ echo $SHELL
   

6. Open the user's shell startup file in any text editor:

   • Bash shell (bash):

     $ vi .bash_profile
     

   • Bourne shell (sh) or Korn shell (ksh):

     $ vi .profile
     

   • C shell (csh or tcsh):

     % vi .login
     

7. Enter or edit the following line, specifying a value of 022 for the default file mode creation mask:

   umask 022
   

8. If the ORACLE_SID, ORACLE_HOME, or ORACLE_BASE environment variables are set in the file, then remove these lines from the file.

9. Save the file, and exit from the text editor.

10. To run the shell startup script, enter one of the following commands:

    • Bash shell:

      $ . ./.bash_profile
      

    • Bourne, Bash, or Korn shell:

      $ . ./.profile
      

    • C shell:

      % source ./.login
      

11. If you are not installing the software on the local system, then enter a command similar to the following to direct X applications to display on the local system:

    • Bourne, Bash, or Korn shell:

      $ DISPLAY=local_host:0.0 ; export DISPLAY
      

    • C shell:

      % setenv DISPLAY local_host:0.0
      

    In this example, local_host is the host name or IP address of the system (your workstation, or another client) on which you want to display the installer.

12. If you determined that the /tmp directory has less than 1 GB of free space, then identify a file system with at least 1 GB of free space and set the TEMP and TMPDIR environment variables to specify a temporary directory on this file system:

    Note:

    You cannot use a shared file system as the location of the temporary file directory (typically /tmp) for Oracle RAC installation. If you place /tmp on a shared file system, then the installation fails.

    1. Use the df -h command to identify a suitable file system with sufficient free space.

    2. If necessary, enter commands similar to the following to create a temporary directory on the file system that you identified, and set the appropriate permissions on the directory:

       $ su - root
       # mkdir /mount_point/tmp
       # chmod 775 /mount_point/tmp
       # exit
       

    3. Enter commands similar to the following to set the TEMP and TMPDIR environment variables:

       • Bourne, Bash, or Korn shell:

         $ TEMP=/mount_point/tmp
         $ TMPDIR=/mount_point/tmp
         $ export TEMP TMPDIR
         

       • C shell:

         % setenv TEMP /mount_point/tmp
         % setenv TMPDIR /mount_point/tmp
         

13. To verify that the environment has been set correctly, enter the following commands:

    $ umask
    $ env | more
    

    Verify that the umask command displays a value of 22, 022, or 0022 and that the environment variables you set in this section have the correct values.

2.14.3 Setting Resource Limits for the Oracle Software Installation Users

To improve the performance of the software on Linux systems, you must increase the following resource limits for the Oracle software owner users (grid, oracle):

In addition, to increase the shell limits:

1. On each node, add the following lines to the /etc/security/limits.conf file (the following example shows the software account owners oracle and grid):

   grid                 soft    nproc   2047
   grid                 hard    nproc   16384
   grid                 soft    nofile  1024
   grid                 hard    nofile  65536
   oracle               soft    nproc   2047
   oracle               hard    nproc   16384
   oracle               soft    nofile  1024
   oracle               hard    nofile  65536
   

2. On each node, add or edit the following line in the /etc/pam.d/login file, if it does not already exist:

   session    required     pam_limits.so
   

3. Depending on your shell environment, make the following changes to the default shell startup file, to change ulimit setting for all Oracle installation owners (note that these examples show the users oracle and grid):

   • For the Bourne, Bash, or Korn shell, add lines similar to the following to the /etc/profile file (or the file on SUSE systems)/etc/profile.local

     if [ $USER = "oracle" ] || [ $USER = "grid" ]; then
             if [ $SHELL = "/bin/ksh" ]; then
                   ulimit -p 16384
                   ulimit -n 65536
             else
                   ulimit -u 16384 -n 65536
             fi
             umask 022
     fi
     

   • For the C shell (csh or tcsh), on Red Hat, OEL, or Asianux, add the following lines to the /etc/csh.login file. On SUSE systems add the lines to /etc/csh.login.local:

     if ( $USER == "oracle" || $USER == "grid" ) then
             limit maxproc 16384
             limit descriptors 65536
     endif
     

4. Repeat this procedure on all other nodes in the cluster, and for all Oracle software owners that you intend to use to install Oracle software.

2.14.4 Setting Display and X11 Forwarding Configuration

If you are on a remote terminal, and the local node has only one visual (which is typical), then use the following syntax to set the DISPLAY environment variable:

Bourne, Korn, and Bash shells

$ export DISPLAY=hostname:0

C shell:

$ setenv DISPLAY hostname:0

For example, if you are using the Bash shell, and if your hostname is node1, then enter the following command:

$ export DISPLAY=node1:0

To ensure that X11 forwarding will not cause the installation to fail, create a user-level SSH client configuration file for the Oracle software owner user, as follows:

1. Using any text editor, edit or create the software installation owner's ~/.ssh/config file.

2. Make sure that the ForwardX11 attribute is set to no. For example:

   Host *
         ForwardX11 no
   

2.14.5 Preventing Installation Errors Caused by stty Commands

During an Oracle grid infrastructure installation, OUI uses SSH to run commands and copy files to the other nodes. During the installation, hidden files on the system (for example, .bashrc or .cshrc) will cause makefile and other installation errors if they contain stty commands.

To avoid this problem, you must modify these files in each Oracle installation owner user home directory to suppress all output on STDERR, as in the following examples:

• Bourne, Bash, or Korn shell:

  if [ -t 0 ]; then
     stty intr ^C
  fi
  

• C shell:

  test -t 0
  if ($status == 0) then
     stty intr ^C
  endif
  

  Note:

  When SSH is not available, the Installer uses the rsh and rcp commands instead of ssh and scp.

  If there are hidden files that contain stty commands that are loaded by the remote shell, then OUI indicates an error and stops the installation.