2 Setting Up Your Infrastructure

This chapter describes the infrastructure requirements you must meet before you start using the lifecycle management features. This chapter is essentially for administrators or designers who create the infrastructure. The requirements described in this chapter have to be performed only once.

This chapter covers the following:

• Getting Started with Setting Up Your Infrastructure

• Setting Up Oracle Software Library

• Setting Up Credentials

• Creating Enterprise Manager User Accounts

• (Optional) Setting Up My Oracle Support

• (Optional) Configuring Self-Update

• (Optional) Setting Up E-mail Notifications

• (Optional) Setting Restricted Accesses for the Root Components

2.1 Getting Started with Setting Up Your Infrastructure

This chapter helps you get started by providing an overview of all the steps involved in setting up your infrastructure. Consider this section to be a documentation map to understand the sequence of actions you must perform to successfully set up your infrastructure for carrying out all the lifecycle management tasks, including Patching and Provisioning.

Figure 2-1 is a pictorial representation of the sequence of steps you must perform in order to setup your infrastructure.

Figure 2-1 Setting Up Your Infrastructure WorkFlow

Click the reference links provided against the steps in the Table 2-1 for more information on each section.

Table 2-1 Getting Started with Setting Up Your Infrastructure

Step	Description	Reference Links
Step 1	Setting Up Software Library	Setting Up Oracle Software Library
Step 2	Setting Up Credentials	Setting Up Credentials
Step 3	Creating Enterprise Manager User Accounts	Creating Enterprise Manager User Accounts
Step 4	Setting Up My Oracle Support Credentials	(Optional) Setting Up My Oracle Support
Step 5	Additional /Value Add setup (optional) Configuring Self-Update	(Optional) Configuring Self-Update
Step 6	Additional /Value Add setup (optional) Setting Up E-Mail Notifications	(Optional) Setting Up E-mail Notifications

Note:

Ensure that the OMS is patched appropriately to the required level. For information about the patches that need to be applied on the Enterprise Manager Cloud Control Management Server (OMS) for using the Provisioning and Patching features, see My Oracle Support note 427577.1.

2.2 Setting Up Oracle Software Library

Oracle Software Library (Software Library) is one of the core features offered by Oracle Enterprise Manager Cloud Control (Cloud Control). Technically, it is a storage location that stores certified software entities such as software patches, virtual appliance images, reference gold images, application software and their associated directive scripts. In addition to storing them, it also enables you to maintain versions, maturity levels, and states of these software entities.

To access the Software Library console page, in Cloud Control, from the Enterprise menu, select Provisioning and Patching and then, click Software Library. On the Software Library home page, as shown in Figure 2-2, there are two types of folders: Oracle-owned folders (marked by a lock symbol) and User-owned folders.

Figure 2-2 Software Library Console

To start using the Software Library to create and manage entities, the Software Library Storage Locations must be configured. System Administrators are responsible for configuring the Software Library storage locations, following which the Software Library becomes usable.

Cloud Control offers the following types of storage locations:

• Upload File Locations: These locations are configured for storing files uploaded by Software Library as part of creating or updating an entity. The Upload File Locations support two storage options:

  1. OMS Shared File System

  2. OMS Agent File System

• Referenced File Locations: These are locations that allow you to leverage the organization's existing IT infrastructure (like file servers, web servers, or storage systems) for sourcing software binaries and scripts. Such locations allow entities to refer to files without having to upload them explicitly to a Software Library storage. Referenced File Locations support three storage options:

  1. HTTP Locations

  2. NFS Locations

  3. Management Agent Locations

You can configure the storage locations from the Administration Console. To do so, in Cloud Control, from Setup menu, select Provisioning and Patching, then select Software Library. The Software Library Administration Page as shown in Figure 2-3 appears:

Figure 2-3 Software Library Administration

See Also:

For information on configuring Software Library, see Oracle Enterprise Manager Cloud Control Administrator's Guide

Note:

To run the procedure on a Windows host which involves executing some Software Library entities (for example, directive scripts), you (the Windows user) must be granted the following privileges:

• Act as part of the operating system

• Adjust memory quotas for a process

• Logon as batch job

• Replace a process level token

If not, the execution of the directive steps in the procedure may fail.

2.3 Setting Up Credentials

To perform any of the provisioning and patching tasks in Enterprise Manager Cloud Control, you need to set up Named Credentials for normal operating system user account (Oracle) and Named Credentials for privileged user accounts (root).

A Named Credential specifies a user's authentication information on a system. Named credentials can be a username and password pair such as the operating system login credentials, or the Oracle home owner credentials primarily used for performing operations such as running jobs, patching and other system management tasks.

Enterprise Manager Cloud Control enables you to register the system credentials as Named Credentials for normal user (Oracle). Alternately, if you have root privileges, you can even register the root account details as Named Credentials for the privileged users. Once they are registered as Named Credentials, you can save them as Preferred Credentials if you want.

The advantages of saving the credentials are:

• You do not have to expose the credential details to all the users.

• It saves time and effort as you do not have to specify the user name and password every time for each Oracle home or host machine, you can instead select a named profile that will use the saved credentials.

For more information on Named Credentials, see Oracle Enterprise Manager Cloud Control Security Guide.

While most steps within a Deployment Procedure can be run as a normal user, there are some steps that require special permissions and privileges, and the Oracle account credentials or the root account credentials may not be sufficient. Under such circumstances, use authentication utilities to run some steps within the Deployment Procedure with the privileges of another user. The authentication utilities supported by Enterprise Manager Cloud Control are SUDO and PowerBroker. This support is offered using the Privilege Delegation mechanism available in Enterprise Manager Cloud Control.

For a conceptual overview of Privilege Delegation and the authentication tools supported by it, see Oracle Enterprise Manager Cloud Control Security Guide.

Table 2-2 lists the use cases pertaining to credentials, and describes the steps to be performed for setting up credentials for provisioning. Select the use case that best matches with the situation you are in, and follow the suggested instructions.

Table 2-2 Setting Up Enterprise Manager Credentials

Use Case	Steps to be performed
If you do not have direct access or the required credentials for the normal operating system user account (Oracle) OR If you do not have direct access or the required credentials for the privileged account (root).	Do the following: Set up the Privilege Delegation as follows: Create Privilege Delegation (PDP) Template either for SUDO or PowerBroker. To do so, see Creating Privilege Delegation section in Oracle Enterprise Manager Cloud Control Security Guide. Apply the created template on the Management Agents of the target hosts. Create Named Credentials for normal operating system user account (Oracle) with privileges to run as SUDO or PowerBroker, for more information see Creating Named Credentials section in Oracle Enterprise Manager Cloud Control Security Guide. OR Create Named Credentials for privileged users account (root) with privileges to run as SUDO or PowerBroker, for more information see Creating Privileged Credentials section in Oracle Enterprise Manager Cloud Control Security Guide. Save the Named credential for normal operating system account or the named credentials for the privileged user account as Preferred Credential. To do so, see Saving Preferred Credentials for Hosts and Oracle Homes and Saving Preferred Credentials to Access My Oracle Support sections in Oracle Enterprise Manager Cloud Control Security Guide.
If you have direct access or the required credentials for the normal operating system user account (Oracle) OR If you have direct access or the required credentials for the privileged account (root).	Do the following: Create Named Credentials for normal operating system user account (Oracle), for more information see Creating Named Credentials section in Oracle Enterprise Manager Cloud Control Security Guide. OR Create Named Credentials for privileged user accounts (root) Credentials, for more information see Creating Privileged Credentials section in Oracle Enterprise Manager Cloud Control Security Guide. Save the Named credential for normal operating system account or the named credentials for the privileged user account as Preferred Credential. To do so, see Saving Preferred Credentials for Hosts and Oracle Homes and Saving Preferred Credentials to Access My Oracle Support sections in Oracle Enterprise Manager Cloud Control Security Guide.

2.4 Creating Enterprise Manager User Accounts

This section describes the following:

• Overview of User Accounts

• Creating Designer User Account

• Creating Operator User Account

2.4.1 Overview of User Accounts

From the Cloud Control, you can create and manage new Enterprise Manager Administrator accounts. Each administrator account includes its own login credentials, as well as a set of roles and privileges that are assigned to the account.

Based on the accesses, the users can be classified as follows:

• Super Administrator

• Designers (EM_ALL_DESIGNER)

• Operators (EM_ALL_OPERATOR)

Super Administrators

Super Administrators are powerful Cloud Control administrators with full access privileges on all targets. They are responsible for creating and administering accounts within the Cloud Control environment. For example, Super Administrators create the Designer and Operator roles, and grant these roles to different users and groups within their enterprise.

Designers

Designers are lead administrators with increased privileges on Deployment Procedures and Software Library. Starting with Cloud Control, designers can create deployment procedure templates using the Lock down feature, and save these templates to enforce standardization and consistency. Operator privileges are granted on these templates so that administrators who login as Operators can launch these templates, and run the Deployment Procedure successfully. Doing this ensures that the procedures are less error prone and more consistent.

For more information about saving deployment procedures using lock downs, see Saving and Launching the Deployment Procedure with Lock Down.

Designers are responsible for performing all the design-time activities such as:

• Creating the provisioning profiles in the Software Library.

• Creating components, directives, and images, and storing them in Oracle Software Library.

• Customizing the default deployment procedures according to the needs of the organization.

• Creating patch plans and patch templates.

The predefined Oracle role for a Designer is EM_ALL_DESIGNER, this role in turn includes fine grained roles where you can specifically set EM_PROVISIONING_DESIGNER for provisioning tasks, and EM_PATCH_DESIGNER for patching tasks. For more information about privilege grants to Designers, see Granting Roles and Privileges to Administrators.

Operators

Operators are administrators who have restricted privileges on a Deployment Procedure and Software Library. Normally, operators can view and submit a deployment procedure. The Designer user may also grant the Operator the necessary privileges on any targets or entities.

Operators use the infrastructure created by designers and perform run-time activities such as:

• Accessing the provisioning profiles present in the Software Library for provisioning procedures.

• Launching software deployments to provision software on selected targets.

• Patching software deployments using patch plans and patch templates.

The predefined Oracle role for an Operator is EM_ALL_OPERATOR, this role in turn includes fine grained roles where you can specifically set EM_PROVISIONING_OPERATOR for provisioning tasks, and EM_PATCH_OPERATOR for patching tasks. For more information about privilege grants to Operators, see Granting Roles and Privileges to Administrators.

Note:

Designers can choose to perform both design-time and run-time activities, but operators can perform only run-time activities.

2.4.2 Creating Designer User Account

To create a Designer user account, follow these steps:

1. In Cloud Control, from the Setup menu, select Security, then select Administrators.

2. On the Administrators page, click Create.

3. In the Create Administrator wizard, do the following:

   1. On the Properties page, specify the name Designer and provide a password. Leave the other fields blank, and click Next.

   2. On the Roles page, select EM_ALL_DESIGNER, and click Next.

      Note:

      You can alternately restrict the Designer access to either Provisioning or Patching domains. For granting privileges explicitly for Provisioning, select the EM_PROVISION_DESIGNER role. Similarly, for granting designer privileges explicitly for Patching, select the EM_PATCH_DESIGNER role.

   3. On the Target Privileges page, select the targets privileges that must be granted to a Designer user account. For information about the target privileges available to an Administrator with Designer role, see Granting Roles and Privileges to Administrators on the Deployment Procedure.

   4. On the Resource Privileges page, select the privileges to be explicitly granted for each of the resource types.

   5. On the Review page, review the information you have provided for this user account, and click Finish.

2.4.3 Creating Operator User Account

To create an Operator user account, follow these steps:

1. In Cloud Control, from the Setup menu, select Security, then select Administrators.

2. On the Administrators page, click Create.

3. In the Create Administrator wizard, do the following:

   1. On the Properties page, specify the name Operator and provide a password. Leave the other fields blank and click Next.

   2. On the Roles page, select EM_ALL_OPERATOR, and click Next.

      Note:

      You can alternately restrict the Operator access to either Provisioning or Patching domains. For granting privileges explicitly for Provisioning, select the EM_PROVISION_OPERATOR role. Similarly, for granting designer privileges explicitly for Patching, select the EM_PATCH_OPERATOR role.

   3. On the Target Privileges page, select the targets privileges that must be granted to an Operator user account. For information about the target privileges available to an Administrator with Operator role, see Granting Roles and Privileges to Administrators on the Deployment Procedure.

   4. On the Resource Privileges page, select the privileges to be explicitly granted for each of the resource types.

   5. On the Review page, review the information you have provided for this user account, and click Finish.

2.5 (Optional) Setting Up My Oracle Support

For Cloud Control to connect to My Oracle Support for Agent Patching, patching other targets, MOS related tasks, and for Self-Update tasks, you must ensure that you set the proxy server settings and register the details. To do so, follow the instructions outlined in Registering the Proxy Details for My Oracle Support.

Note:

Beginning with Enterprise Manager Cloud Control 12c Release 3 (12.1.0.3), My Oracle Suppot accesses support.oracle.com directly. This means that you must provide network access to this URL, or grant proxy access to it from any client that will access My Oracle Support.

2.6 (Optional) Configuring Self-Update

The Self Update feature enables you to obtain information about updates to Cloud Control components. The Self Update home page can be used to obtain information about new updates and provides a common workflow to review, download and apply the updates. The Self Update console automatically informs you whenever new updates that are applicable to your installation are made available by Oracle.

Software Library components and directives that you can use for provisioning and patching are called provisioning entities. A Provisioning bundle refers to a specific provisioning or patching area, such as database provisioning or FMW provisioning through which Cloud Control delivers updates to customers.

Note:

Ensure that the user has VIEW_ANY_SELFUPDATE privileges.

For applying Oracle-supplied updates to provisioning entities, follow these steps:

1. In Cloud Control, from the Setup menu, select Extensibility, then select Self Update.
2. Schedule to download provisioning bundle. The Self-update framework downloads the bundle to a well-defined location. For more information about Self-Update, see Oracle Enterprise Manager Cloud Control Administrator's Guide.
3. From the Actions menu, select Subscribe to ensure that you receive notification whenever a provisioning bundle is available for download.
4. In the Updates Home page, select update of Type Provisioning Bundle and from the Actions menu, select Open.
5. Apply the provisioning bundle updates manually. Follow instructions as per selected provisioning bundle to apply the update manually.
6. In the Updates Home page, verify that the update is applied.

2.7 (Optional) Setting Up E-mail Notifications

Cloud Control can send e-mail notification every time you run a Deployment Procedure. However, by default, Deployment Procedures do not have this feature enabled. To configure them to send e-mail notifications, you must customize the Deployment Procedure.

For information on how you can customize Deployment Procedures and set up email notifications, see Customizing Deployment Procedures.

2.8 (Optional) Setting Restricted Accesses for the Root Components

This section describes how you can perform certain lifecycle management tasks like Provisioning and Patching in Enterprise Manager using restricted access. In order to run some root commands, you either need to provide the restricted root access to a user (usually Management Agent user) or run the command that require root access manually.

Primarily, this section covers:

• Root Components for Patching

• Root Components for Provisioning

2.8.1 Root Components for Patching

This section covers:

• Manually Staging the Root Components

• Restricting the Root User Access

2.8.1.1 Manually Staging the Root Components

By default, the root component is automatically staged on the target host (at the location defined by %emd_emstagedir%). However, if you want to manually stage the root component at a custom location before initiating the patching process, follow these steps:

1. From the Enterprise menu, select Provisioning and Patching, then select Software Library.

2. Navigate to Patching And Provisioning, and then Components.

3. Select Root Dispatcher, and then click View.

4. Click Stage.

5. Specify the host (where you want to stage the root dispatcher), and the dispatcher location, that is, the location on the specified host where you want to stage the root dispatcher. Click Submit to manually stage the root dispatcher.

6. Navigate to Patching And Provisioning, and then Components.

7. Select Root Scripts, and then click View.

8. Click Stage.

9. Specify the host (where you want to stage the root component), and the dispatcher location, that is, the location on the specified host where you want to stage the root component. Click Submit to manually stage the root component.

   Note:

   Before you manually stage the root components at a custom location, ensure that the user has the read and execute permissions on the dispatcher location and on root_dispatcher.sh.

10. Decompress the file staged in the previous step.

Note:

After staging the root component manually, you must specify this in the patch plan that you create for applying the required Oracle patches. Access the Deployment Options page of the patch plan that you created. In the Where to Stage section, select No (already staged) for Stage Root Component, and specify the dispatcher location where you have staged the root component manually. If the dispatcher location is a shared location, select Dispatcher Location Shared.

2.8.1.2 Restricting the Root User Access

In Enterprise Manager Cloud Control, you can provide restricted root access to the Management Agent user, such that the Management Agent user can only run certain commands as root, and not all commands. You can ensure this by editing the etc/sudoers policy file or, optionally in LDAP.

To patch the Oracle database and middleware targets, the Management Agent user must be able to run the perl, root_dispatcher.sh and id entities as the root user. These entities form a part of the patching root component.

To provide restricted root access to the Management Agent user, such that this user can only run the perl, root_dispatcher.sh and id entities as the root user, edit the etc/sudoers file such that it has the following contents:

Cmnd_Alias <command_alias> = \
      <agent_home>/sbin/nmosudo DEFAULT_PLUGIN DEFAULT_FUNCTIONALITY DEFAULT_SUBACTION DEFAULT_ACTION perl *, \
      <agent_home>/sbin/nmosudo DEFAULT_PLUGIN DEFAULT_FUNCTIONALITY DEFAULT_SUBACTION DEFAULT_ACTION id, \
      <agent_home>/sbin/nmosudo DEFAULT_PLUGIN DEFAULT_FUNCTIONALITY DEFAULT_SUBACTION DEFAULT_ACTION <dispatcher_loc>/root_dispatcher.sh *
 
aime ALL=(root) <command_alias>

<agent_home> represents the Management Agent home.

Note:

If the validation of privileged credentials from the EM Patch Plan wizard is not required then do the following:

1. Set the value of check_privileged_sudo_credentials to false in the mgmt_patching_properties table in the EM Repository.

2. The /etc/sudoers can only contain the following:

   Cmnd_Alias <command_alias> = \
                   <agent_home>/sbin/nmosudo DEFAULT_PLUGIN DEFAULT_FUNCTIONALITY DEFAULT_SUBACTION DEFAULT_ACTION <dispatcher_loc>/root_dispatcher.sh *
   aime ALL=(root) <command_alias>
   

Note:

<dispatcher_loc> represents the root dispatcher location where the root component is staged. By default, the root component is automatically staged at %emd_emstagedir%. If you chose a custom location for the automatic staging, or staged the root component manually at a custom location, ensure that you specify this location for <dispatcher_loc>. Else, specify the default location, that is, %emd_emstagedir%.

Note:

For information on commands to be run as root for patching RAC and Grid Infrastructure databases, see Oracle Grid Infrastructure and Oracle RAC Configuration Support.

2.8.2 Root Components for Provisioning

This section covers the following:

• Manually Staging the Root Components

• Restricting the Root User Access

2.8.2.1 Manually Staging the Root Components

By default, the root component is automatically staged on the target host (at the location defined by %emd_emstagedir%). However, if you want to manually stage the root component at a custom location before initiating the provisioning process, follow these steps:

1. From the Enterprise menu, select Provisioning and Patching, then select Software Library.

2. Navigate to Patching And Provisioning, and then Components.

3. Select Root Dispatcher, and then click View.

4. Click Stage.

5. Specify the host (where you want to stage the root dispatcher), and the dispatcher location, that is, the location on the specified host where you want to stage the root dispatcher. Click Submit to manually stage the root dispatcher.

6. Navigate to Patching And Provisioning, and then Components.

7. Select Root Scripts, and then click View.

8. Click Stage.

9. Specify the host (where you want to stage the root component), and the dispatcher location, that is, the location on the specified host where you want to stage the root component. Click Submit to manually stage the root component.

   Note:

   Before you manually stage the root components at a custom location, ensure that the user has the read and execute permissions on the dispatcher location and on root_dispatcher.sh.

10. Decompress the file staged in the previous step.

Note:

After staging the root components manually, you must access the Select Software Locations page from the Provision Oracle Database wizard. In the Root Dispatcher Location, specify the same dispatcher location where you have staged the root components manually, and select Select this option if all the root scripts are staged to ROOT_DISPATCH_LOC already.

If you have not manually staged the root scripts component, then you can use the database provisioning workflow to specify the details. In the Select Software Locations page of the Provision Oracle Database wizard, enter a location where you want to stage the root scripts. If you do not provide the location details, then a standard enterprise manager stage location will be used to stage the root components.

2.8.2.2 Restricting the Root User Access

In Enterprise Manager Cloud Control, you can provide restricted root access to the Management Agent user, such that the Management Agent user can only run certain commands as root, and not all commands. You can ensure this by editing the etc/sudoers policy file. Since provisioning involves invoking all the commands on the target host using Management Agent, you must include nmosudo in the sudoers file with the set of commands that is possible to run. To provide restricted root access to the Management Agent user, edit the etc/sudoers file such that it has the following contents:

Cmnd_Alias <command_alias> = \
      <agent_home>/sbin/nmosudo DEFAULT_PLUGIN DEFAULT_FUNCTIONALITY DEFAULT_SUBACTION DEFAULT_ACTION perl *, \
      <agent_home>/sbin/nmosudo DEFAULT_PLUGIN DEFAULT_FUNCTIONALITY DEFAULT_SUBACTION DEFAULT_ACTION <dispatcher_loc>/root_dispatcher.sh *,\
      <agent_home>/sbin/nmosudo DEFAULT_PLUGIN DEFAULT_FUNCTIONALITY DEFAULT_SUBACTION DEFAULT_ACTION id
 
aime ALL=(root) PROVISIONING_DISPATCHER

<command_alias> represents the alias that describes the entities that can be run by aime as root.

<agent_home> represents the Management Agent home.

<dispatcher_loc> represents the root dispatcher location where the root component is staged. By default, the root component is automatically staged at %emd_emstagedir%. If you chose a custom location for the automatic staging, or staged the root component manually at a custom location, ensure that you specify this location for <dispatcher_loc>. Else, specify the default location, that is, %emd_emstagedir%.