2 Oracle Real Application Clusters Preinstallation Tasks

2.1.2.1 Verifying That the User nobody Exists

If you intend to install Oracle Database or Oracle RAC, then complete the following procedure to verify that the user nobody exists on the system:

1. To determine if the user exists, enter the following command:

   # id nobody
   

   If this command displays information about the nobody user, then you do not have to create that user.

2. If the nobody user does not exist, then enter a command similar to the following to create it:

   # /usr/sbin/useradd -u 65001 nobody
   

3. Repeat this procedure on all the other nodes in the cluster. Note that the ID number for uid and gid should be the same on all nodes of the cluster.

2.1.2.2 Creating the OSDBA Group

To create the OSDBA group, complete the following procedure:

1. Enter a command similar to the following:

   # /usr/sbin/groupadd -g 502 dba
   

   The preceding command creates the group dba, with the group ID number 502.

2.1.2.3 Creating Identical Users and Groups on Other Cluster Nodes

Oracle software owner users and groups must exist and be identical on all cluster nodes.

Identifying Existing User and Group IDs

To determine the user ID (UID) of the oracle user, and the group IDs (GID) of the Oracle Inventory, OSDBA, and OSOPER groups, follow these steps:

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

   # id oracle
   

   The output from this command is similar to the following:

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

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 are identical on each node.

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 next cluster node as root.

2. Enter commands similar to the following to create groups. Use the -g option to specify the correct GID for each group.

   # /usr/sbin/groupadd -g 501 oinstall
   # /usr/sbin/groupadd -g 502 dba
   

   Note:

   If a group already exists, but has a different group ID, then use the groupmod command to modify it if necessary. If you cannot use the same group ID for a particular group on this node, then view the /etc/group file on all nodes to identify a group ID that is available on every node. You must then specify that ID for the group on all of the nodes.

3. To create the oracle user or another required user, enter a command similar to the following (in this example, to create the oracle user):

   # /usr/sbin/useradd -u 501 -g oinstall oracle
   

   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, which must be the Oracle Inventory group; for example, oinstall

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

2.2.1.1 Users for Oracle Installations with Job Role Separation

Oracle recommends that you create the following operating system group and users for all installations where you create separate software installation owners:

• One software owner to own each Oracle software product (typically, oracle, for the database software owner user, crs for Oracle Clusterware, and asm for Oracle ASM.

  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 Clusterware software, and you can also make this user the owner of the binaries of Automatic Storage Management and Oracle Database or Oracle RAC.

  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, 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 it) the OSOPER group 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 more than one database on the system.

  In Oracle documentation, a user created to own the Oracle Clusterware binaries is called the crs user.

  If you intend to use Automatic Storage Management (ASM), then Oracle recommends that you create a separate user to own ASM files. In Oracle documentation, that user is referred to as asm.

  See Also:

  Oracle Database Administrator's Reference for UNIX Systems and Oracle Database Administrator's Guide for more information about the OSDBA, OSASM and OSOPER groups and the SYSDBA, SYSASM and SYSOPER privileges

• An unprivileged user

  Verify that the unprivileged user nobody exists on the system. The nobody user must own the external jobs (extjob) executable after the installation.

2.2.1.2 Database Groups for Job Role Installations

The following operating system groups and user are required if you are installing Oracle Database:

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

  If you want to specify a group name other than the default dba group, then you must choose the Custom installation type to install the software or start Oracle Universal Installer (OUI) as a user that is not a member of this group. In this case, OUI prompts you to specify the name of this group.

  On Automatic Storage Manager (ASM) instances, members of the OSDBA group are given privileges to perform all administrative privileges granted to the SYSASM privileges, including mounting and dismounting disk groups. This privileges grant is deprecated, and will be removed in a future release.

• The OSOPER group for Oracle Database (typically, oper)

  This is an optional group. Create this group if you want a separate group of operating system users to have a limited set of database administrative privileges (the SYSOPER privilege). By default, members of the OSDBA group also have all privileges granted by the SYSOPER privilege.

  If you want to use the OSOPER group to create a database administrator group with fewer privileges than the default dba group, then you must choose the Custom installation type to install the software or start OUI as a user that is not a member of the dba group. In this case, OUI prompts you to specify the name of this group. The usual name chosen for this group is oper.

2.2.1.3 ASM Groups for Job Role Installations

SYSASM is a new system privilege that enables the separation of the ASM storage administration privilege from SYSDBA. Members of the database OSDBA group are granted SYSASM privileges, but this privilege is deprecated, and may be removed in a future release.

Use the Custom Installation option to designate separate operating system groups as the operating system authentication groups for privileges on ASM. Before you start OUI, create the following groups and users for ASM

• The Oracle Automatic Storage Management Group (typically asm)

  SYSASM privileges for ASM files provide administrator privileges for storage file equivalent to SYSDBA privileges for the database. In Oracle documentation, the operating system group whose members are granted SYSASM privileges is called the OSASM group, and in command lines, is referred to as asm.

  If you have more than one database on your system, then you must create a separate OSASM group, and a separate ASM user. ASM can support multiple databases.

  Members of the OSASM group can use SQL to connect to an 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. In this release of Oracle Clusterware and Oracle Database, SYSASM privileges and SYSDBA privileges are equivalent, but using SYSDBA privileges to perform ASM management tasks on ASM instances is deprecated. SYSDBA privileges may be limited on ASM instances in a future release.

• The OSDBA group for ASM (typically asmdba)

  Members of the OSDBA group for ASM are granted read and write access to files managed by ASM. The Oracle database software owner (typically oracle) must be a member of this group, and all users with OSDBA membership on databases that you want to have access to the files managed by ASM should be members of the OSDBA group for ASM

2.2.2.1 Creating the OSDBA Group for Custom Installations

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 as follows. In the following procedure, use the group name dba unless a group with that name already exists:

# /usr/sbin/groupadd -g 502 dba

2.2.2.2 Creating an OSOPER Group

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. If you want 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 you require a new OSOPER group, then create it as follows. In the following, use the group name oper unless a group with that name already exists.

# /usr/sbin/groupadd -g 505 oper

2.2.2.3 Creating the OSASM Group

If the OSASM group does not exist or if you require a new OSASM group, then create it as follows. In the following procedure, use the group name asm unless a group with that name already exists:

# /usr/sbin/groupadd -504 asm

2.2.2.4 Creating the OSDBA Group for ASM

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

If the OSDBA group for ASM does not exist or if you require a new OSDBA group for ASM, then create it as follows. In the following procedure, use the group name asmdba unless a group with that name already exists:

# /usr/sbin/groupadd -g 506 asmdba

2.2.2.5 Creating the Oracle Software Owner User

You must create an Oracle software owner user in the following circumstances:

• If an Oracle software owner user exists, but you want to use a different operating system user, with different group membership, to give database administrative privileges to those groups in a new Oracle Database installation

• If you have created an Oracle software owner for Oracle Clusterware, such as crs, and you want to create a separate Oracle software owner for Oracle Database software, such as dba.

# id oracle

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

# /usr/sbin/usermod -g oinstall -G dba[,oper] oracle

2.2.2.6 Creating a Separate ASM Owner

1. To create asm, enter a command similar to the following:

   # /usr/sbin/useradd -u 504 -g oinstall -G asm
   

   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, you must make note of the asm ID number, as you require it later during preinstallation.

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

   • The -G option specifies the secondary groups, which must include the OSASM group. For example: asm.

2. Set the password for asm:

   # passwd asm
   

2.2.2.7 Verifying That the User nobody Exists

Before installing the software, complete the following procedure to verify that the user nobody exists on the system:

1. To determine if the user exists, enter the following command:

   # id nobody
   

   If this command displays information about the nobody user, then you do not have to create that user.

2. If the nobody user does not exist, then enter the following command syntax to create it:

   # /usr/sbin/useradd -u number nobody
   

   for example:

   # /usr/sbin/useradd -u 65555 nobody
   

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

2.2.2.8 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 crs, oracle, or asm users, and the group IDs (GID) of the Oracle Inventory, OSDBA, and OSOPER 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)
   

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.

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 next cluster node as root.

2. Enter commands similar to the following to create the oinstall and dba groups, and if required, the oper and asm groups. Use the -g option to specify the correct GID for each group.

   # /usr/sbin/groupadd -g 501 oinstall
   # /usr/sbin/groupadd -g 502 crs
   # /usr/sbin/groupadd -g 503 dba
   # /usr/sbin/groupadd -g 505 oper
   # /usr/sbin/groupadd -g 504 asm
   # /usr/sbin/groupadd -g 506 asmdba
   

   Note:

   If the 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 this 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 asm user, enter a command similar to the following (in this example, to create the oracle user):

   # /usr/sbin/useradd -u 502 -g oinstall -G dba[,oper] oracle
   

   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, which must be the Oracle Inventory group, for example oinstall

   • The -G option specifies the secondary groups, which must include the OSDBA group and if required, the OSOPER group. For example: dba or dba,oper

     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 SSH configuration for each user as described in the section "Configuring SSH on All Cluster Nodes".

6. Complete user environment configuration tasks for each user as described in the section Configuring Software Owner User Environments.