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

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

6.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=1101(oracle) gid=1000(oinstall) groups=1200(dba),1104(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.

If you are using the Oracle Preinstallation RPM to provision your Linux operating system for an Oracle Grid Infrastructure and Oracle Database installation, then it has configured for you the Oracle database installation owner (oracle), an Oracle Inventory group (oinstall). and an Oracle administrative privileges group (dba).

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

6.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 Oracle Database user account before you install Oracle RAC, to distinguish between the Oracle Grid Infrastructure owner and the Oracle RAC 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 privileges groups to separate administration privileges, complete group creation before you create the user, as described in Section 6.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 privilege, 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 privilege 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=1101(oracle) gid=1000(oinstall) groups=1200(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.

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

6.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 privilege 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 privileges are 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).

6.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 privileges 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).

6.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. 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 privileges groups for Oracle ASM and Oracle Database administrators. Members of this group are granted the SYSASM system privileges 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.

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

6.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 54323 oper

6.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 54328 asmadmin

6.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 54329 asmoper

6.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 54325 asmdba

6.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)

6.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=1101(oracle) gid=1000(oinstall) groups=1200(dba),1104(oper),1021(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 Preinstallation 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 6.2, "Configuring Grid Infrastructure Software Owner User Environments".

6.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 privileges 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.

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

6.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 privileges 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 privileges 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 privileges 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 privileges (a limited set of the SYSDBA privileges), including the right to start up and shut down the DB1 database. Users who connect as OSOPER privileges 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.

6.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 privileges 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 privileges 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 privileges 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 privileges (a limited set of the SYSDBA privileges), including the right to start up and shut down the DB2 database. Users who connect as OSOPER privileges 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.

6.3.3.1 Configuring the Open IPMI Driver

On Linux systems, the OpenIPMI driver is the supported driver for Oracle Clusterware deployments with IPMI.

You can install and configure the driver dynamically by manually loading the required modules. Contact your Linux distribution vendor for information about how to configure IPMI for your distribution.

The following example shows how to configure the Open IPMI driver manually on Oracle Linux:

1. Log in as root.

2. Run the following commands:

   # /sbin/modprobe ipmi_msghandler
   # /sbin/modprobe ipmi_si
   # /sbin/modprobe ipmi_devintf
   

3. (Optional) Run the command /sbin/lsmod |grep ipmi to confirm that the IPMI modules are loaded. For example:

   # /sbin/lsmod | grep ipmi
   ipmi_devintf           12617  0
   ipmi_si                33377  0
   ipmi_msghandler        33701  2 ipmi_devintf,ipmi_si
   

   Note:

   You can install the modules whether or not a BMC is present.

4. Open the /etc/rc.local file using a text editor, navigate to the end of the file, and enter lines similar to the following so that the modprobe commands in step 2 will be run automatically on system restart:

   # START IPMI ON SYSTEM RESTART
   /sbin/modprobe ipmi_msghandler
   /sbin/modprobe ipmi_si
   /sbin/modprobe ipmi_devintf
   

   Note:

   On SUSE Linux Enterprise Server systems, add the modprobe commands above to /etc/init.d/boot.local.

5. Check to ensure that the Linux system is recognizing the IPMI device, using the following command:

   ls -l /dev/ipmi0
   

   If the IPMI device has been dynamically loaded, then the output should be similar to the following:

   # ls -l /dev/ipmi0
   crw-------  1 root root 253, 0 Sep 23 06:29 /dev/ipmi0
   

   If you do see the device file output, then the IPMI driver is configured, and you can ignore the following step.

   If you do not see the device file output, then the udevd daemon is not set up to create device files automatically. Proceed to the next step.

6. Determine the device major number for the IPMI device using the command grep ipmi /proc/devices. For example:

   # grep ipmi /proc/devices
   253 ipmidev
   

   In the preceding example, the device major number is 253.

7. Run the mknod command to create a directory entry and i-node for the IPMI device, using the device major number. For example:

   # mknod /dev/ipmi0 c 253 0x0
   

   The permissions on /dev/ipmi0 in the preceding example allow the device to be accessible only by root. The device should only be accessed by root, to prevent a system vulnerability.

6.3.3.2 Configuring the BMC

Configure BMC on each node for remote control using LAN for IPMI-based node fencing to function properly. You can configure BMC from the BIOS prompt, using a distribution-specific management utility, or you can configure BMC using publicly available utilities, such as the following:

IPMItool, which is available for Linux:

http://ipmitool.sourceforge.net

IPMIutil, which is available for Linux and Windows:

http://ipmiutil.sourceforge.net

Refer to the documentation for the configuration tool you select for details about using the tool to configure the BMC.

When you configure the BMC on each node, you must complete the following:

• Enable IPMI over LAN, so that the BMC can be controlled over the management network.

• Enable dynamic IP addressing using DHCP or GNS, or configure a static IP address for the BMC.

• Establish an administrator user account and password for the BMC.

• Configure the BMC for VLAN tags, if you will use the BMC on a tagged VLAN.

The configuration tool you use does not matter, but these conditions must be met for the BMC to function properly.