1. Cloud Control Database Lifecycle Management Administrator's Guide
  2. Introduction to Enterprise Manager Lifecycle Management
  3. Setting Up Your Infrastructure

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

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


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.

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


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


Software Library Administration

For information on configuring Software Library, see Configuring a Software Library in 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.

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 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:
  1. Set up the Privilege Delegation as follows:
    1. Create Privilege Delegation (PDP) Template either for SUDO or PowerBroker. To do so, see Privilege Needed for Creating a Privilege Delegation in Oracle Enterprise Manager Cloud Control Security Guide.
    2. Apply the created template on the Management Agents of the target hosts.
  2. 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 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 in Oracle Enterprise Manager Cloud Control Security Guide.
  3. 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:
  1. Create Named Credentials for normal operating system user account Oracle, for more information see Creating Named Credentials 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 in Oracle Enterprise Manager Cloud Control Security Guide
  2. 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.

Creating Enterprise Manager User Accounts

This section describes the following:

Overview of User Accounts

From 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. There are three main administrator accounts Designer, Operator and a Super Administrator that oversees the previous mentioned roles.

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.

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.

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.

Deploying Agents on OCI Resources

With Enterprise Manager you can manage database assets running in a combination of on-premises data centers or in the Oracle Cloud Infrastructure (OCI) from the same user interface. The Provision Pluggable Databases now provides a unified experience to manage pluggable databases on any platform. Perform operations like create, clone, refreshable clone, relocate on-premises PDBs as well as OCI PDBs.

Prerequisites To Deploying Agents on OCI resources

Before you begin please ensure the following prerequisites that need to be performed within OCI prior to discovery in Enterprise Manager
  1. Provision a Compute Virtual Machine or Database System and then deploy an agent on the same network VCN and Subnet for target discovery and monitoring. The agent needs to use the same SSH keys that you have used for provisioning Compute Virtual Machines or Database system when deploying an agent.
    1. Open port 3872 on the VCN security list to permit connection.

      Figure 2-4 Add Security Rule


      Open port 3872 in Add Rule>Add Security Rule

  2. Log in to the node where the agent will be deployed and open the firewall port 3872.
    1. Use the following firewall rules for database systems:
      sudo iptables -I INPUT -p tcp -m state --state NEW -m tcp -s 10.0.1.0/25 --dport 3872 -m comment --comment "Required foraccess to Agent Listener" -j ACCEPT
sudo iptables -I INPUT -p tcp -m tcp --dport 3872 -j ACCEPT
sudo service iptables save
sudo service iptables reload
    2. Use the following commands for RHEL 7.7 and above:
      firewall-cmd --zone=public --add-port=3872/tcp --permanent
firewall-cmd --reload
iptables-save | grep 3872
  3. Create named credentials on Enterprise Manager with the SSH key provided during Compute VM or Database system provisioning, to do this in Enterprise Manager navigate to Setup>Security and click on Named Credentials.
    1. Credential Name: OCI_SSH_Key
    2. Credential Type: SSH Key Credentials
    3. Scope: Global
    4. Username: opc
    5. Run Privilege: sudo
    6. Run as: oracle
  4. Set up Privilege Delegation. Navigate to Setup>Security>Privilege Delegation. Select the installed agent and make sure Privilege Delegation is set for the agent.

    Figure 2-5 Privilege Delegation Setting


    Make sure the selected agent has Privilege Delegation set.

  5. For single node deployments add the agent hosts IP and host name to the Enterprise Manager hosts file and add Enterprise Manager details on the Agent machines host file:

    Note:

    This step is not required for Multi Node environments as all communication goes through the load balancers.
    1. Example of setup needed for an OMS host in a Single Node environment:
      [opc@oms1 ~]$ cat/etc/hosts
10.0.1.3 <oms node 1>
10.0.1.4 <oms node 2>
10.0.1.6 <db host 1>
10.0.1.7 <db host 2>
    2. Example of setup needed for an agent deployed on a Compute VM in a Single Node environment:
      [opc@dbhostt1 ~]$ cat/etc/hosts
10.0.1.6 dbhost1.sample.com dbhost1
192.168.16.18 dbhost1-priv.sample.com dbhost1-priv
10.0.1.8 dbhost1-vip.sample.com dbhost1-vip
10.0.1.7 dbhost2.sample.com  dbhost2
192.168.16.19 dbhost2-priv.sample.com  dbhost2-priv
10.0.1.9 dbhost2-vip.sample.com  dbhost2-vip
10.0.1.3 omsnode1
10.0.1.4 omsnode2

To deploy Enterprise Management agents on OCI resources follow these steps:

  1. Add the agent using the graphical interface by navigating to: Setup>Add Target>Add Targets Manually>Add Hosts Targets. Click on Install Agent on Host and enter Installation directory, Instance directory and credentials.

    Figure 2-6 Add Host Target Installation Details


    In this screen enter the Installation and Instance directories as well as credentials to manually add a host.

  2. After the agent deployment, make sure the agent is shown on the Enterprise Manager All Targets page.
  3. Perform a target Discovery after these steps are done, this will integrate an OCI resource into Enterprise Manager. For more information see: Discovering and Adding Database Targets in Oracle Enterprise Manager Cloud Control Administrator's Guide .

Once the OCI database target has been discovered you can manage specific database actions. For more information, see Managing Pluggable Databases Using Enterprise Manager.

The following management actions can be performed on an OCI PDB:

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

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

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

(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

This section covers:

Manually Staging the Root Components for Patching
By default, the root component is automatically staged on the target host (at the location defined by %emd_emstagedir%). Before you manually stage a root component you need to consider the following critical points:
  • After picking up a Release Updates (RU) or Plug-in release, you need to stage the root scripts component into a temporary location and do the same with the pre-staged files.
  • Review the changes between versions and update the pre-stage location with the new set of files.
  • Note that the RU or Plug-in will only work with the latest files shipped with that update. Validate and, either accept the changes or defer the uptake of the RU or Plug-in until the concern is resolved as per your internal process.
  • Once the RU or Plug-in update is accepted, incorporate any custom changes made in the previous version to the new root scripts and pre-staged files.
  • Pre-stage the root scripts for production use and continue with the regular manually staging steps.

If you want to manually stage (pre-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.
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.

Root Components for Provisioning

This section covers the following:

Manually Staging the Root Components for Provisioning
By default, the root component is automatically staged on the target host (at the location defined by %emd_emstagedir%). Before you manually stage a root component you need to consider the following critical points:
  • After picking up a Release Updates (RU) or Plug-in release, you need to stage the root scripts component into a temporary location and do the same with the pre-staged files.
  • Review the changes between versions and update the pre-stage location with the new set of files.
  • Note that the RU or Plug-in will only work with the latest files shipped with that update. Validate and, either accept the changes or defer the uptake of the RU or Plug-in until the concern is resolved as per your internal process.
  • Once the RU or Plug-in update is accepted, incorporate any custom changes made in the previous version to the new root scripts and pre-staged files.
  • Pre-stage the root scripts for production use and continue with the regular manually staging steps.

If you want to manually stage (pre-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 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.

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 SR_PATCH_DISPATCHER = \       
/u01/app/oracle/agent/agent_13.4.0.0.0/sbin/nmosudo *, \       
/u01/app/oracle/agent/agent_13.4.0.0.0/sbin/nmosudo  DEFAULT_PLUGIN DEFAULT_FUNCTIONALITY DEFAULT_SUBACTION DEFAULT_ACTION  perl *, \       
/u01/app/oracle/agent/agent_13.4.0.0.0/sbin/nmosudo  DEFAULT_PLUGIN DEFAULT_FUNCTIONALITY DEFAULT_SUBACTION DEFAULT_ACTION  id, \       
/u01/app/oracle/agent/agent_13.4.0.0.0/sbin/nmosudo  DEFAULT_PLUGIN DEFAULT_FUNCTIONALITY DEFAULT_SUBACTION DEFAULT_ACTION
/tmp/fleet/dispatchLoc/root_dispatcher.sh *
oracle ALL=(root)NOPASSWD:SR_PATCH_DISPATCHER 
grid ALL=(root)NOPASSWD:SR_PATCH_DISPATCHER

<command_alias> represents the alias that describes the entities that can be run by oracle or grid 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%.

Root Components for Fleet Maintenance

This section covers:

Manually Staging the Root Components For Fleet Maintenance
By default, the root component is automatically staged on the target host (at the location defined by %emd_emstagedir%). Before you manually stage a root component you need to consider the following critical points:
  • After picking up a Release Updates (RU) or Plug-in release, you need to stage the root scripts component into a temporary location and do the same with the pre-staged files.
  • Review the changes between versions and update the pre-stage location with the new set of files.
  • Note that the RU or Plug-in will only work with the latest files shipped with that update. Validate and, either accept the changes or defer the uptake of the RU or Plug-in until the concern is resolved as per your internal process.
  • Once the RU or Plug-in update is accepted, incorporate any custom changes made in the previous version to the new root scripts and pre-staged files.
  • Pre-stage the root scripts for production use and continue with the regular manually staging steps.

If you want to manually stage (pre-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. Select Root Scripts, and then click View.
  7. Click Stage.
  8. 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.

  9. Unzip the file staged in the previous step.
  10. Select Common Root, and then click View.
  11. Click Stage.

You now have configured the options for a Pre-Staged Root Dispatcher for fleet maintenance, for more information please see: Fleet Management Software.

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.
Restricting the Root User Access For Fleet Maintenance

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

You can also restrict root access by setting the dispatchLoc flag within the input_file. This parameter has been added, to aide operations that stage and use a dispatcher location, using an existing, read-only location to use pre-staged dispatcher as well as fleet scripts.

Fleet Maintenance operations allow you to create a read-only mount point location for root-owned types of scripts. You can restrict access to root only by setting the dispatchLoc flag within the input_file. You may choose, optionally, to pre-stage all the necessary files in this location. If you pre-stage, you must include in the dispatchLoc: the Root Dispatcher, unzipped Root Scripts and common root.

For more information on the input_file please review: Fleet Management Software