5 Configuring Users, Groups and Environments for Oracle Grid Infrastructure and Oracle RAC

5.1.3.1 Understanding Restrictions for Oracle Software Installation Owners

Review the following restrictions for users created to own Oracle software:

• If you intend to use multiple Oracle software owners for different Oracle Database homes, then Oracle recommends that you create a separate software owner for Oracle Grid Infrastructure software (Oracle Clusterware and Oracle ASM), and use that owner to run the Oracle Grid Infrastructure installation.

• During installation, SSH must be set up between cluster member nodes. SSH can be set up automatically by Oracle Universal Installer (the installer). To enable SSH to be set up automatically, create Oracle installation owners without any stty commands in their profiles, and remove other security measures that are triggered during a login that generate messages to the terminal. These messages, mail checks, and other displays prevent Oracle software installation owner accounts from using the SSH configuration script that is built into the installer. If they are not disabled, then SSH must be configured manually before an installation can be run.

• If you plan to install Oracle Database or Oracle RAC, then Oracle recommends that you create separate users for the Oracle Grid Infrastructure and the Oracle Database installations. If you use one installation owner, then when you want to perform administration tasks, you must change the value for $ORACLE_HOME to the instance you want to administer (Oracle ASM, in the Oracle Grid Infrastructure home, or the database in the Oracle home), using command syntax such as the following example, where /u01/app/12.1.0/grid is the Oracle Grid Infrastructure home:

  $ORACLE_HOME=/u01/app/12.1.0/grid; export ORACLE_HOME

• If you try to administer an Oracle home or Grid home instance using sqlplus, lsnrctl, or asmcmd commands while the environment variable $ORACLE_HOME is set to a different Oracle home or Grid home path, then you encounter errors. For example, when you start SRVCTL from a database home, $ORACLE_HOME should be set to that database home, or SRVCTL fails. The exception is when you are using SRVCTL in the Oracle Grid Infrastructure home. In that case, $ORACLE_HOME is ignored, and the Oracle home environment variable does not affect SRVCTL commands. In all other cases, you must change $ORACLE_HOME to the instance that you want to administer.

• To create separate Oracle software owners and separate operating system privileges groups for different Oracle software installations, note that each of these users must have the Oracle central inventory group (oraInventory group) as their primary group. Members of this group are granted the OINSTALL system privileges to write to the Oracle central inventory (oraInventory) directory, and are also granted permissions for various Oracle Clusterware resources, OCR keys, directories in the Oracle Clusterware home to which DBAs need write access, and other necessary privileges. Members of this group are also granted execute permissions to start and stop Clusterware infrastructure resources and databases. In Oracle documentation, this group is represented as oinstall in code examples.

• Each Oracle software owner must be a member of the same central inventory oraInventory group, and they must have this group as their primary group, so that all Oracle software installation owners share the same OINSTALL system privileges. Oracle recommends that you do not have more than one central inventory for Oracle installations. If an Oracle software owner has a different central inventory group, then you may corrupt the central inventory.

5.1.3.2 Determining if an Oracle Software Owner User Exists

To determine whether an Oracle software owner user named oracle or grid exists, enter a command similar to the following (in this case, to determine if oracle exists):

# id oracle

If the user exists, then the output from this command is similar to the following:

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

Determine whether you want to use the existing user, or create another user. The user and group ID numbers must be the same on each node you intend to make a cluster member node.

To use an existing user as an installation owner for this installation, ensure that the user's primary group is the Oracle Inventory group (oinstall).

5.1.3.3 Creating or Modifying an Oracle Software Owner User for Oracle Grid Infrastructure

If the Oracle software owner (oracle, grid) user does not exist, or if you require a new Oracle software owner user, then create it. If you want to use an existing user account, then modify it to ensure that the user IDs (UID) and group IDs (GID) are the same on each cluster member node.

Oracle recommends that you do not use the defaults on each node, because UIDs and GIDs assigned by default are likely to be different on each node. Instead, determine specifically named and numbered UIDs and GIDs, and confirm that they are unused on any node before you create or modify groups and users. Oracle strongly recommends that you confirm that you have identical user configuration on each node you intend to make a cluster member node before you start installation, and that the UID and GIDs do not need to be changed. If you need to change UIDs and GIDs for Oracle software users and groups, then you must reinstall the software.

Oracle does not support changing the UID or GID or group memberships for a user account that you have previously used to install and configure Oracle RAC or Oracle Grid Infrastructure. Oracle does not support changing the ownership of an existing Oracle Database home from one Oracle user to a different user.

If you must modify an existing Grid installation owner after previously installing Oracle Grid Infrastructure (for example, if you want to modify an existing user to distinguish between the Oracle Grid Infrastructure owner and Oracle Database owner user accounts), then you must stop and start Oracle Clusterware on each node (in a rolling fashion) to pick up the changes made to the user account that owns Oracle Grid Infrastructure.

The following procedures use grid as the name of the Oracle software owner, and asmadmin as the OSASM group. To create separate system privilege groups to separate administration privileges, complete group creation before you create the user, as described in Section 5.1.7, "About Job Role Separation Operating System Privileges Groups and Users."

1. To create a grid installation owner account where you have an existing system privileges group (in this example, dba), whose members you want to have granted the SYSASM privilege to administer the Oracle ASM instance, enter a command similar to the following:

   # /usr/sbin/useradd -u 54322 -g oinstall -G dba grid
   

   In the preceding command:

   • The -u option specifies the user ID. Using this command flag is optional, as you can allow the system to provide you with an automatically generated user ID number. However, Oracle recommends that you specify a number. You must make note of the user ID number of the user you create for Oracle Grid Infrastructure, as you require it later during preinstallation. You must use the same user ID number for this user on all nodes of the cluster.

   • The -g option specifies the primary group, which must be the Oracle Inventory group. For example: oinstall.

   • The -G option specified the secondary group, which in this example is dba.

     The secondary groups must include the OSASM group, whose members are granted the SYSASM privilege to administer the Oracle ASM instance. You can designate a unique group for the SYSASM system privileges, separate from database administrator groups, or you can designate one group as the OSASM and OSDBA group, so that members of that group are granted the SYSASM and SYSDBA privileges to grant system privileges to administer both the Oracle ASM instances and Oracle Database instances. In code examples, this group is asmadmin.

     If you are creating this user to own both Oracle Grid Infrastructure and an Oracle Database installation, then this user must have the OSDBA for ASM group as a secondary group. In code examples, this group name is asmdba. Members of the OSDBA for ASM group are granted access to Oracle ASM storage. You must create an OSDBA for ASM group if you plan to have multiple databases accessing Oracle ASM storage, or you must use the same group as the OSDBA for all databases, and for the OSDBA for ASM group. You are also prompted during installation to assign operating system groups for several other Oracle Database system administrative privileges.

   Use the usermod command to change existing user ID numbers and groups.

   For example:

   # id oracle
   uid=501(oracle) gid=501(oracle) groups=501(dba)
   # /usr/sbin/usermod -u 54321 -g 54321 -G 54322,54327 oracle
   # id oracle
   uid=54321(oracle) gid=54321(oinstall) groups=54321(oinstall),54322(dba),54327 (asmdba)
   

2. Set the password of the user that will own Oracle Grid Infrastructure. For example:

   # passwd grid
   

3. Repeat this procedure on all of the other nodes in the cluster.

5.1.8.1 Oracle Software Owner For Each Oracle Software Product

Oracle recommends that you create one software owner to own each Oracle software product (typically, oracle, for the database software owner user, and grid for Oracle Grid Infrastructure).

You must create at least one software owner the first time you install Oracle software on the system. This user owns the Oracle binaries of the Oracle Grid Infrastructure software, and you can also make this user the owner of the Oracle Database or Oracle RAC binaries.

Oracle software owners must have the Oracle Inventory group as their primary group, so that each Oracle software installation owner can write to the central inventory (oraInventory), and so that OCR and Oracle Clusterware resource permissions are set correctly. The database software owner must also have the OSDBA group and (if you create them) the OSOPER, OSBACKUPDBA, OSDGDBA, and OSKMDBA groups as secondary groups. In Oracle documentation, when Oracle software owner users are referred to, they are called oracle users.

Oracle recommends that you create separate software owner users to own each Oracle software installation. Oracle particularly recommends that you do this if you intend to install multiple databases on the system.

In Oracle documentation, a user created to own the Oracle Grid Infrastructure binaries is called the grid user. This user owns both the Oracle Clusterware and Oracle Automatic Storage Management binaries.

5.1.8.2 Standard Oracle Database Groups for Job Role Separation

The following is a list of standard Oracle Database groups. These groups provide operating system authentication for database administration system privileges:

• OSDBA group (typically, dba)

  You must create this group the first time you install Oracle Database software on the system. This group identifies operating system user accounts that have database administrative privileges (the SYSDBA privilege). If you do not create separate OSDBA, OSOPER and OSASM groups for the Oracle ASM instance, then operating system user accounts that have the SYSOPER and SYSASM privileges must be members of this group. The name used for this group in Oracle code examples is dba. If you do not designate a separate group as the OSASM group, then the OSDBA group you define is also by default the OSASM group.

  To specify a group name other than the default dba group, you must either choose the Advanced installation type to install the software, or you start Oracle Universal Installer (OUI) as a user that is not a member of this group. If you start OUI with a user that is not a member of a group called dba, then OUI prompts you to specify the name of the OSDBA group.

  Members of the OSDBA group formerly were granted SYSASM privileges on Oracle ASM instances, including mounting and dismounting disk groups. This privileges grant is removed with Oracle Grid Infrastructure 11g Release 2 (11.2), if different operating system groups are designated as the OSDBA and OSASM groups. If the same group is used for both OSDBA and OSASM, then the privilege is retained.

• OSOPER group for Oracle Database (typically, oper)

  You can choose to create this group if you want a separate group of operating system users to have a limited set of database administrative privileges for starting up and shutting down the database (the SYSOPER privilege).

5.1.8.3 Extended Oracle Database Groups for Job Role Separation

Starting with Oracle Database 12c Release 1 (12.1), in addition to the OSOPER privilege to start up and shut down the database, you can create new administrative privileges that are more task-specific and less privileged than the OSDBA/SYSDBA system privileges to support specific administrative privileges tasks required for everyday database operation Users granted these system privileges are also authenticated through operating system group membership.

You do not have to create these specific group names, but during installation you are prompted to provide operating system groups whose members are granted access to these system privileges. You can assign the same group to provide authentication for these privileges, but Oracle recommends that you provide a unique group to designate each privilege.

The OSDBA subset job role separation privileges and groups consist of the following:

• OSBACKUPDBA group for Oracle Database (typically, backupdba)

  Create this group if you want a separate group of operating system users to have a limited set of database backup and recovery related administrative privileges (the SYSBACKUP privilege).

• OSDGDBA group for Oracle Data Guard (typically, dgdba)

  Create this group if you want a separate group of operating system users to have a limited set of privileges to administer and monitor Oracle Data Guard (the SYSDG privilege).

• OSKMDBA group for encryption key management (typically, kmdba)

  Create this group if you want a separate group of operating sytem users to have a limited set of privileges for encryption key management such as Oracle Wallet Manager management (the SYSKM privilege).

5.1.8.4 Oracle ASM Groups for Job Role Separation

The SYSASM, SYSOPER for ASM, and SYSDBA for ASM system privileges enables the separation of the Oracle ASM storage administration privileges from SYSDBA. In addition, if you plan to use Oracle Automatic Storage Management Cluster File System (Oracle ACFS), then you can enable separation of privileges for the Oracle ACFS Audit Manager and Oracle ACFS Auditor storage administration roles. Members of operating systems you designate are granted the system privileges for these roles. Select separate operating system groups as the operating system authentication groups for privileges on Oracle ASM.

Before you start OUI, create the following OS groups and users for Oracle ASM, whose members are granted the corresponding SYS privileges:

• OSASM Group for Oracle ASM Administration (typically asmadmin)

  Create this group as a separate group if you want to have separate administration privilege groups for Oracle ASM and Oracle Database administrators. Members of this group are granted the SYSASM system privilege to administer Oracle ASM. In Oracle documentation, the operating system group whose members are granted privileges is called the OSASM group, and in code examples, where there is a group specifically created to grant this privilege, it is referred to as asmadmin.

  Oracle ASM can support multiple databases. If you have multiple databases on your system, and use multiple OSDBA groups so that you can provide separate SYSDBA privileges for each database, then you should create a group whose members are granted the OSASM/SYSASM administrative privileges, and create a grid infrastructure user (grid) that does not own a database installation, so that you separate Oracle Grid Infrastructure SYSASM administrative privileges from a database administrative privileges group.

  Members of the OSASM group can use SQL to connect to an Oracle ASM instance as SYSASM using operating system authentication. The SYSASM privileges permit mounting and dismounting disk groups, and other storage administration tasks. SYSASM privileges provide no access privileges on an RDBMS instance.

• OSDBA for ASM Database Administrator group for ASM, typically asmdba)

  Members of the ASM Database Administrator group (OSDBA for ASM) are granted read and write access to files managed by Oracle ASM. The Oracle Grid Infrastructure installation owner and all Oracle Database software owners must be a member of this group, and all users with OSDBA membership on databases that have access to the files managed by Oracle ASM must be members of the OSDBA group for ASM.

• OSOPER for ASM Group for ASM Operators (OSOPER for ASM, typically asmoper)

  This is an optional group. Create this group if you want a separate group of operating system users to have a limited set of Oracle ASM instance administrative privileges (the SYSOPER for ASM privilege), including starting up and stopping the Oracle ASM instance. By default, members of the OSASM group also have all privileges granted by the SYSOPER for ASM privilege.

  To use the Oracle ASM Operator group to create an Oracle ASM administrator group with fewer privileges than the default asmadmin group, then you must choose the Advanced installation type to install the software, In this case, OUI prompts you to specify the name of this group. In code examples, this group is asmoper.

After installation, if you intend to use Oracle ACFS, then you can use an existing group or create one or two groups whose members are granted the Oracle ACFS Audit Manager and Oracle ACFS Auditor system privileges:

• Oracle ACFS Audit Manager Group

  Members of the group you create or designate as the Oracle ACFS Audit Manager Group are granted the Auditor system privilege, which includes the privilege to create and manage audit policy for Oracle ACFS. This group should be different from the system administrator group, Oracle ACFS security administrator OS group, and the Oracle ACFS Audit Auditor Group. You can use an existing group, or you can create a group. For example: osacfs

• Oracle ACFS Audit Auditor Group

  Members of the group you create or designate as the Oracle ACFS Auditor Group are granted Auditor system privileges to perform audits on Oracle ACFS. You can use an existing group, or you can create a group. For example: osaudit

5.1.9.1 Creating the OSDBA Group to Prepare for Database Installations

If you intend to install Oracle Database to use with the Oracle Grid Infrastructure installation, then you must create an OSDBA group in the following circumstances:

• An OSDBA group does not exist; for example, if this is the first installation of Oracle Database software on the system

• An OSDBA group exists, but you want to give a different group of operating system users database administrative privileges for a new Oracle Database installation

If the OSDBA group does not exist, or if you require a new OSDBA group, then create it. Use the group name dba unless a group with that name already exists. For example:

# /usr/sbin/groupadd -g 54322 dba

5.1.9.2 Creating an OSOPER Group for Database Installations

Create an OSOPER group only if you want to identify a group of operating system users with a limited set of database administrative privileges (SYSOPER operator privileges). For most installations, it is sufficient to create only the OSDBA group. To use an OSOPER group, then you must create it in the following circumstances:

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

• If an OSOPER group exists, but you want to give a different group of operating system users database operator privileges in a new Oracle installation

If the OSOPER group does not exist, or if you require a new OSOPER group, then create it. Use the group name oper unless a group with that name already exists. For example:

# groupadd -g 54359 oper

5.1.9.3 Creating the OSASM Group

If the OSASM group does not exist, or if you require a new OSASM group, then create it. Use the group name asmadmin unless a group with that name already exists. For example:

# groupadd -g 54323 asmadmin

5.1.9.4 Creating the OSOPER for ASM Group

Create an OSOPER for ASM group if you want to identify a group of operating system users, such as database administrators, whom you want to grant a limited set of Oracle ASM storage tier administrative privileges, including the ability to start up and shut down the Oracle ASM storage. For most installations, it is sufficient to create only the OSASM group, and provide that group as the OSOPER for ASM group during the installation interview.

If the OSOPER for ASM group does not exist, or if you require a new OSOPER for ASM group, then create it. Use the group name asmoper unless a group with that name already exists. For example:

# groupadd -g 54328 asmoper

5.1.9.5 Creating the OSDBA for ASM Group for Database Access to Oracle ASM

You must create an OSDBA for ASM group to provide access to the Oracle ASM instance. This is necessary if OSASM and OSDBA are different groups.

If the OSDBA for ASM group does not exist, or if you require a new OSDBA for ASM group, then create it. Use the group name asmdba unless a group with that name already exists. For example:

# groupadd -g 54324 asmdba

5.1.9.6 Oracle Software Owner User Installation Tasks

This section contains information about the Oracle software owner user, which is typically the user that owns Oracle Database or other Oracle application software. This section contains the following topics:

• About the Oracle Software Owner User

• Determining if an Oracle Software Owner User Exists

• Creating an Oracle Software Owner User

• Modifying an Existing Oracle Software Owner User

# id oracle

uid=1101(oracle) gid=1000(oinstall) groups=1200(dba),1104(oper)

5.1.9.7 Creating Identical Database Users and Groups on Other Cluster Nodes

Oracle software owner users and the Oracle Inventory, OSDBA, and OSOPER groups must exist and be identical on all cluster nodes. To create these identical users and groups, you must identify the user ID and group IDs assigned them on the node where you created them, and then create the user and groups with the same name and ID on the other cluster nodes.

Identifying Existing User and Group IDs

To determine the user ID (uid) of the grid or oracle users, and the group IDs (gid) of the existing Oracle groups, follow these steps:

1. Enter a command similar to the following (in this case, to determine a user ID for the oracle user):

   # id oracle
   

   The output from this command is similar to the following:

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

2. From the output, identify the user ID (uid) for the user and the group identities (gids) for the groups to which it belongs. Ensure that these ID numbers are identical on each node of the cluster. The user's primary group is listed after gid. Secondary groups are listed after groups.

Creating Users and Groups on the Other Cluster Nodes

To create users and groups on the other cluster nodes, repeat the following procedure on each node:

1. Log in to the node as root.

2. Enter commands similar to the following to create the asmadmin, asmdba, backupdba, dgdba, kmdba, asmoper and oper groups, and if not configured by the Oracle Pre-Install RPM or prior installations, the oinstall and dba groups. Use the -g option to specify the correct group ID for each group.

   # groupadd -g 54321 oinstall
   # groupadd -g 54322 dba
   # groupadd -g 54323 oper
   # groupadd -g 54324 backupdba
   # groupadd -g 54325 asmdba
   # groupadd -g 54326 dgdba
   # groupadd -g 54327 kmdba
   # groupadd -g 54328 asmadmin
   # groupadd -g 54329 asmoper
   

   Note:

   You are not required to use the UIDs and GIDs in this example. If a group already exists, then use the groupmod command to modify it if necessary. If you cannot use the same group ID for a particular group on a node, then view the /etc/group file on all nodes to identify a group ID that is available on every node. You must then change the group ID on all nodes to the same group ID.

3. To create the oracle or Oracle Grid Infrastructure (grid) user, enter a command similar to the following:

   # useradd -u 54322 -g oinstall -G asmadmin,asmdba grid
   

   In the preceding command:

   • The -u option specifies the user ID, which must be the user ID that you identified in the previous subsection.

   • The -g option specifies the primary group for the Grid user, which must be the Oracle Inventory group (OINSTALL), which grants the OINSTALL system privileges. In this example, the OINSTALL group is oinstall.

   • The -G option specifies the secondary groups. The Grid user must be a member of the OSASM group (asmadmin) and the OSDBA for ASM group (asmdba).

     Note:

     If the user already exists, then use the usermod command to modify it if necessary. If you cannot use the same user ID for the user on every node, then view the /etc/passwd file on all nodes to identify a user ID that is available on every node. You must then specify that ID for the user on all of the nodes.

4. Set the password of the user. For example:

   # passwd oracle
   

5. Complete user environment configuration tasks for each user as described in the section Section 5.2, "Configuring Grid Infrastructure Software Owner User Environments."

5.1.11.1 Oracle Grid Infrastructure Groups and Users Example

• An Oracle central inventory group, or oraInventory group (oinstall), whose members that have this group as their primary group. Members of this group are granted the OINSTALL system privileges, which grants permissions to write to the oraInventory directory, and other associated install binary privileges.

• An OSASM group (asmadmin), associated with Oracle Grid Infrastructure during installation, whose members are granted the SYSASM privilege to administer Oracle ASM.

• An OSDBA for ASM group (asmdba), associated with Oracle Grid Infrastructure storage during installation. Its members include grid and any database installation owners, such as oracle1 and oracle2, who are granted access to Oracle ASM. Any additional installation owners that use Oracle ASM for storage must also be made members of this group.

• An OSOPER for ASM group for Oracle ASM (asmoper), associated with Oracle Grid Infrastructure during installation. Members of asmoper group are granted limited Oracle ASM administrator privileges, including the permissions to start and stop the Oracle ASM instance.

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

• An Oracle OCFS Audit Manager group whose members are granted Audit Manager system privileges on Oracle ACFS storage

• An Oracle ACFS Auditor group whose members are granted Auditor system privileges on Oracle ACFS storage

• /u01/app/oraInventory. The central inventory of Oracle installations on the cluster. This path remains owned by grid:oinstall, to enable other Oracle software owners to write to the central inventory.

• An OFA-compliant mount point /u01 owned by grid:oinstall before installation, so that Oracle Universal Installer can write to that path.

• 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.

• A Grid home /u01/app/12.1.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).

5.1.11.2 Oracle Database DB1 Groups and Users Example

• An Oracle Database software owner (oracle1), which owns the Oracle Database binaries for DB1. The oracle1 user has the oraInventory group as its primary group, and the OSDBA group for its database (dba1) and the OSDBA for ASM group for Oracle Grid Infrastructure (asmdba) as secondary groups. In addition the oracle1 user is a member of asmoper, granting that user privileges to start up and shut down Oracle ASM.

• An OSDBA group (dba1). During installation, you identify the group dba1 as the OSDBA group for the database installed by the user oracle1. Members of dba1 are granted the SYSDBA privileges for the Oracle Database DB1. Users who connect as SYSDBA are identified as user SYS on DB1.

• An OSBACKUPDBA group (backupdba1). During installation, you identify the group backupdba1 as the OSDBA group for the database installed by the user oracle1. Members of backupdba1 are granted the SYSBACKUP privilege for the database installed by the user oracle1 to back up the database.

• An OSDGDBA group (dgdba1). During installation, you identify the group dgdba1 as the OSDGDBA group for the database installed by the user oracle1. Members of dgdba1 are granted the SYSDG privilege to administer Oracle Data Guard for the database installed by the user oracle1.

• An OSKMDBA group (kmdba1). During installation, you identify the group kmdba1 as the OSKMDBA group for the database installed by the user oracle1. Members of kmdba1 are granted the SYSKM privilege to administer encryption keys for the database installed by the user oracle1.

• An OSOPER group (oper1). During installation, you identify the group oper1 as the OSOPER group for the database installed by the user oracle1. Members of oper1 are granted the SYSOPER privilege (a limited set of the SYSDBA privileges), including the right to start up and shut down the DB1 database. Users who connect as OSOPER privilege are identified as user PUBLIC on DB1.

• An Oracle base /u01/app/oracle1 owned by oracle1:oinstall with 775 permissions. The user oracle1 has permissions to install software in this directory, but in no other directory in the /u01/app path.

5.1.11.3 Oracle Database DB2 Groups and Users Example

• An Oracle Database software owner (oracle2), which owns the Oracle Database binaries for DB2. The oracle2 user has the oraInventory group as its primary group, and the OSDBA group for its database (dba2) and the OSDBA for ASM group for Oracle Grid Infrastructure (asmdba) as secondary groups. However, the oracle2 user is not a member of the asmoper group, so oracle2 cannot shut down or start up Oracle ASM.

• An OSDBA group (dba2). During installation, you identify the group dba2 as the OSDBA group for the database installed by the user oracle2. Members of dba2 are granted the SYSDBA privileges for the Oracle Database DB2. Users who connect as SYSDBA are identified as user SYS on DB2.

• An OSBACKUPDBA group (backupdba2). During installation, you identify the group backupdba2 as the OSDBA group for the database installed by the user oracle2. Members of backupdba2 are granted the SYSBACKUP privilege for the database installed by the user oracle2 to back up the database.

• An OSDGDBA group (dgdba2). During installation, you identify the group dgdba2 as the OSDGDBA group for the database installed by the user oracle2. Members of dgdba2 are granted the SYSDG privilege to administer Oracle Data Guard for the database installed by the user oracle2.

• An OSKMDBA group (kmdba2). During installation, you identify the group kmdba2 as the OSKMDBA group for the database installed by the user oracle2. Members of kmdba2 are granted the SYSKM privilege to administer encryption keys for the database installed by the user oracle2.

• An OSOPER group (oper2). During installation, you identify the group oper2 as the OSOPER group for the database installed by the user oracle2. Members of oper2 are granted the SYSOPER privilege (a limited set of the SYSDBA privileges), including the right to start up and shut down the DB2 database. Users who connect as OSOPER privilege are identified as user PUBLIC on DB2.

• An Oracle base /u01/app/oracle2 owned by oracle1:oinstall with 775 permissions. The user oracle2 has permissions to install software in this directory, but in no other directory in the /u01/app path.

5.4.1.1 IPMI Firmware Patches

Oracle has provided patch-level information for IPMI firmware on Sun systems. If your cluster includes any of the following systems then ensure their firmware is updated to include at least the following patches. Obtain the patch version needed for your firmware from the following URL:

http://www.oracle.com/technetwork/systems/patches/firmware/index.html

Install on each cluster member node:

• Sun Blade T6340 Server Module Sun System Firmware with LDOMS support

  139448-03

• SPARC Enterprise T5440 Sun System Firmware with LDOMS support

  139446-03

• Netra T5440 Sun System Firmware with LDOMS support

  139445-04

• SPARC Enterprise T5140 & T5240 Sun System Firmware LDOMS

  139444-03

• Netra T5220 Sun System Firmware with LDOMS support

  139442-06

• Sun Blade T6320 + T6320-G2 Server Module Sun System Firmware with LDOMS support

  139440-04

• SPARC Enterprise T5120 & T5220 Sun System Firmware with LDOMS support

  139439-04

5.4.3.1 Configuring IPMI in the ILOM Processor on Oracle Solaris

When you log in to the ILOM web interface, configure parameters to enable IPMI using the following procedures:

1. Click Configuration, then System Management Access, then IPMI. Click Enabled to enable IPMI over LAN.

2. Click Configuration, then Network. Enter information for the IP address, the netmask, and the default gateway.

3. Click User Management, then User Account Settings. Add the IPMI administrator account username and password, and set the role to Administrator.

5.4.3.2 Example of BMC Configuration Using IPMItool

The utility ipmitool is provided as part of the Oracle Solaris distribution. You can use ipmitool to configure IPMI parameters, but be aware that setting parameters using ipmitool also sets the corresponding parameters for the service processor.

The following is an example of configuring BMC using ipmitool (version 1.8.6).

1. Log in as root.

2. Verify that ipmitool can communicate with the BMC using the IPMI driver by using the command bmc info, and looking for a device ID in the output. For example:

   # ipmitool bmc info
   Device ID                 : 32
   .
   .
   .
   

   If ipmitool is not communicating with the BMC, then review the section "Configuring the BMC" and ensure that the IPMI driver is running.

3. Enable IPMI over LAN using the following procedure

   1. Determine the channel number for the channel used for IPMI over LAN. Beginning with channel 1, run the following command until you find the channel that displays LAN attributes (for example, the IP address):

      # ipmitool lan print 1
       
      . . . 
      IP Address Source       : 0x01
      IP Address              : 140.87.155.89
      . . .
      

   2. Turn on LAN access for the channel found. For example, where the channel is 1:

      # ipmitool -I bmc lan set 1 access on
      

4. Configure IP address settings for IPMI using the static IP addressing procedure:

   • Using static IP Addressing

     If the BMC shares a network connection with ILOM, then the IP address must be on the same subnet. You must set not only the IP address, but also the proper values for netmask, and the default gateway. For example, assuming the channel is 1:

     # ipmitool -I bmc lan set 1 ipaddr 192.168.0.55
     # ipmitool -I bmc lan set 1 netmask 255.255.255.0
     # ipmitool -I bmc lan set 1 defgw ipaddr 192.168.0.1
     

     Note that the specified address (192.168.0.55) will be associated only with the BMC, and will not respond to normal pings.

5. Establish an administration account with a username and password, using the following procedure (assuming the channel is 1):

   1. Set BMC to require password authentication for ADMIN access over LAN. For example:

      # ipmitool -I bmc lan set 1 auth ADMIN MD5,PASSWORD
      

   2. List the account slots on the BMC, and identify an unused slot (that is, slot less than the maximum ID and not listed, ID 4 in the following example). Note that some slots may be reserved and not available for reuse on some hardware.

      # ipmitool user summary 1
      Maximum IDs         : 20
      Enabled User Count  : 3
      Fixed Name Count    : 2
      # ipmitool user list 1
      ID  Name     Enabled Callin  Link Auth  IPMI Msg   Channel Priv Lim
      1            true    false   false      true       USER
      2   root     true    false   false      true       ADMINISTRATOR
      3   sysoper  true    true    false      true       OPERATOR
      12  default  true    true    false      true       NO ACCESS
      13           true    false   true       false      CALLBACK
       
      

      In the example above, there are 20 possible slots, and the first unused slot is number 4.

   3. Assign the desired administrator user name and password and enable messaging for the identified slot. (Note that for IPMI v1.5 the user name and password can be at most 16 characters). Also, set the privilege level for that slot when accessed over LAN (channel 1) to ADMIN (level 4). For example, where username is the administrative user name, and password is the password:

      # ipmitool user set name 4 username
      # ipmitool user set password 4 password
      # ipmitool user enable 4
      # ipmitool channel setaccess 1 4 privilege=4
      # ipmitool channel setaccess 1 4 link=on
      # ipmitool channel setaccess 1 4 ipmi=on
      

   4. Verify the setup using the command lan print 1. The output should appear similar to the following. Note that the items in bold text are the settings made in the preceding configuration steps, and comments or alternative options are indicated within brackets []:

      # ipmitool lan print 1
      Set in Progress         : Set Complete
      Auth Type Support       : NONE MD2 MD5 PASSWORD
      Auth Type Enable        : Callback : MD2 MD5
                              : User     : MD2 MD5
                              : Operator : MD2 MD5
                              : Admin    : MD5 PASSWORD
                              : OEM      : MD2 MD5
      IP Address Source       : DHCP Address [or Static Address]
      IP Address              : 192.168.0.55
      Subnet Mask             : 255.255.255.0
      MAC Address             : 00:14:22:23:fa:f9
      SNMP Community String   : public
      IP Header               : TTL=0x40 Flags=0x40 Precedence=… 
      Default Gateway IP      : 192.168.0.1
      Default Gateway MAC     : 00:00:00:00:00:00
      .
      .
      .
      # ipmitool channel getaccess 1 4
      Maximum User IDs     : 10
      Enabled User IDs     : 2
       
      User ID              : 4
      User Name            : username [This is the administration user]
      Fixed Name           : No
      Access Available     : call-in / callback
      Link Authentication  : enabled
      IPMI Messaging       : enabled
      Privilege Level      : ADMINISTRATOR
      

6. Verify that the BMC is accessible and controllable from a remote node in your cluster using the bmc info command. For example, if node2-ipmi is the network host name assigned the IP address of node2's BMC, then to verify the BMC on node node2 from node1, with the administrator account username, enter the following command on node1:

   $ ipmitool -H node2-ipmi -U username lan print 1
   

   You are prompted for a password. Provide the IPMI password.

   If the BMC is correctly configured, then you should see information about the BMC on the remote node. If you see an error message, such as Error: Unable to establish LAN session, then you must check the BMC configuration on the remote node.

7. Repeat this process for each cluster member node.

8. After installation, configure IPMI as described in Section 8.2.1, "Configuring IPMI-based Failure Isolation Using Crsctl."