3 Infrastructure Requirements

Before you run any of the Deployment Procedures, meet the infrastructure requirements described in this chapter. This chapter is essentially for administrators or designers who create the infrastructure for provisioning and patching. The requirements described in this chapter have to be performed just once.

Creating Designer and Operator User Accounts

The main users of Deployment Procedures are Designers (Lead Administrators) and Operators. Designers are users who perform design-time activities and Operators are users who perform run-time activities. For more information about these user accounts, see Users of Deployment Procedures.

Before you begin using Deployment Procedures, create these user accounts in Enterprise Manager Grid Control so that Designers have super administrator privileges to perform advanced tasks, and Operators have basic privileges to run Deployment Procedures.

Creating Designer User Account

On the Overview of Setup page, from the vertical menu on the left, click Administrators.

On the Administrators page, click Create.

In the Create Administrator wizard, do the following:

On the Properties page, specify the name Designer, provide a password, check Super Administrator, and click Next.

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

Creating Operator User Account

To create a Operator user account, follow these steps:

In Grid Control, click Setup.

On the Overview of Setup page, from the vertical menu on the left, click Administrators.

On the Administrators page, click Create.

In the Create Administrator wizard, do the following:

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

On the Roles page, select Public, and click Next.

On the System Privileges page, select the system privileges that you want to grant to this operator user account.

On the Target Privileges page, select the targets that the operator user account will access.

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

Setting Up Oracle Software Library

Oracle Software Library (Software Library) can be configured using any mounted file system that is readable and writable from Oracle Management Service (OMS).

If Enterprise Manager Grid Control is configured as a single server setup, then local directories can be used to configure the Software Library. Ensure that there is enough space available for the storage of software binaries, and associated scripts for the entities that you want to create and store.

If Enterprise Manager Grid Control is configured as a multiple servers setup, then the directories comprising the Software Library must be accessible by all OMS instances. Ensure that there is enough space available on the shared storage to store files that hold binary data for your components and other entities.

If Enterprise Manager Grid Control is configured as a single server setup, and then moved to multiple servers setup, you can use the Check Accessibility feature in the Software Library section in the Administration page and verify that the Software Library location is accessible to all Oracle Management Servers. For more details, see Appendix C, "Using Oracle Software Library".

In the Software Library Configuration section of the Administration tab, click Add.

On the Add Software Library Location page, enter the directory location and then click OK.

Note:

When you add a Software Library location for the first time, the configuration will take some time. Subsequently, adding other Software Library locations will be quicker.

When the Software Library is configured, out-of-box Provisioning Archive files (PAR files) will be deployed. These files contain pre-build entities such as components, directives, and so on for various applications such as bare metal provisioning and patching.

Creating a Component in Oracle Software Library

To create a component in the Software Library, follow these steps:

Note:

If you want to create a component for the software binaries of Oracle Database Replay Client, then before you access the Software Library, see My Oracle Support note 815567.1. This note explains the different requirements for each OS platform prior to using the media with Grid Control Deployment Procedure.

In Grid Control, click Deployments, and select the Provisioning tab.

In the Components tab, select the folder under which you want to create the component and click Create Component. For example, Navigate to Components, Oracle Components, Host Patch, and 10.2.0.5.0.

In the Create Component: Describe page, select the type of component you are creating, the name, product/patch number, version and vendor details. You can create the following types of components:

Oracle Application Server

Oracle Enterprise Linux Operating System

Linux Disk Layout

Oracle Clusterware Clone

SuSe Linux Operating System

OVS

Oracle Database Software Clone

Hardware Profile

RedHat Linux Operating System

Generic Component

Click Next.

Follow the steps in the wizard depending on the type of component you have selected. Ensure that you associate the correct version of the component type when creating the component.

In the Create Component: Review page, review all the information you have provided and submit the component creation job.

Navigate to the directory in the Software Library where you saved the component and verify that it has been created.

Note:

Do NOT upload software binaries that are more than 2 GB of size. If you do so and try to run the Deployment Procedure, the procedure will fail. To resolve this issue, first install the software manually using the product DVD, and then create a gold image of that instance and store it in the Software Library for future deployments.

Applying Patches

Oracle released a few patches after the release of Enterprise Manager 10g Grid Control Release 5 (10.2.0.5) to further enhance the provisioning and patching functionality. Oracle strongly recommends you to apply these patches so that you gain the benefits these paches offer.

This section describes the patches you must download and apply before using any of the provisioning or patching Deployment Procedures. In particular, this section covers the following:

Applying Common Patches

Apply the patches required for provisioning and patching as described in My Oracle Support note 427577.1.

To view this note, access My Oracle Support at the following URL. On the main page (based on the classic metalink view), from the Quick Find list, select Document ID (Knowledge Base, Forum, or Bug), and quote the note number and click Go.

Applying One-Off Patch to Introduce Analyze Mode and Reports

In July 2009, Oracle released the one-off patch 8653501 that enhances the following Deployment Procedures to act as prerequisite checkers:

Patch Oracle Database

Patch Oracle RAC Database - Rolling

Patch Oracle RAC Database - All Nodes

The one-off patch introduces an Analyze Mode that helps you verify the applicability of a patch in the database environment. Oracle recommends you to run the Deployment Procedures in this mode to ensure that you meet all the necessary requirements for online and offline patching, and also resolve all operational conflicts and issues beforehand. This exercise ensures that the patching operation always runs smoothly and predictably. For information about running the patching Deployment Procedures in Analyze mode, see Chapter 14, "Running Patch Prerequisite Checker Deployment Procedures".

The one-off patch also introduces patching automation reports that help you identify the database targets suitable for a patching operation and analyze how the patching Deployment Procedures have performed in the past. For more information about the reports, see Appendix H, "About Patching Automation Reports".

The one-off patch has to be applied on Enterprise Manager 10g Grid Control Release 5 (10.2.0.5). If you have a lower version of Enterprise Manager Grid Control, then upgrade it to 10.2.0.5 before applying this one-off patch.

To apply this one-off patch, do the following:

Access My Oracle Support at the following URL and download the one-off patch 8653501:

Perform the additional steps outlined in the ReadMe file that is rolled out with the one-off patch.

Note:

After you apply the one-off patch, the version of the Deployment Procedure changes from 5.0 to 5.1. You can view this in the Version column of the Procedures table on the Deployment Procedure Manager page.

Discovering and Monitoring Hosts and Targets

Before running a provisioning-related Deployment Procedure, ensure that the target hosts are discovered and monitored in Enterprise Manager Grid Control. Similarly, before running a patching-related Deployment Procedure, ensure that the targets you want to patch are discovered and monitored in Enterprise Manager Grid Control.

For this purpose, you require Oracle Management Agent 10g Release 5 (or higher) to be installed on the target hosts where you want to run the procedure.

In the case of Oracle RAC and Oracle Clusterware, before you run the Deployment Procedures to provision them, ensure that Oracle Management Agent 10g Release 5 (or higher) is installed on every node of the cluster using the Cluster Install option available in the Agent Deploy application.

If you do not have Oracle Management Agent (Management Agent) installed on every node of the cluster, then see the instructions outlined for installing a Management Agent using the Agent Deploy application in the Enterprise Manager Grid Control Installation Guide available at:

Setting Up SUDO, PAM, Privilege Delegation Settings

Enterprise Manager Grid Control allows you to run Deployment Procedures using authentication utilities such as SUDO, PowerBroker, and Privilege Delegation. While SUDO and PowerBroker are third-party utilities supported in Enterprise Manager Grid Control, Privilege Delegation is proprietary to Oracle. Privilege Delegation is a framework that allows you to use either SUDO or PowerBroker to perform an activity with the privileges of another user (locked accounts).

The supported version of SUDO is 1.6.9.5 P5, and the supported version of PBRUN is 4.0.8.

Setting Up E-mail Notifications

Enterprise Manager Grid 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.

Setting Up Preferred Credentials

Before you run any Deployment Procedure, Oracle recommends you to register the credentials of the host on which you want to provision or the Oracle home that you want to patch, as preferred credentials in Enterprise Manager Grid Control. This section explains how you can set up preferred credentials. In particular, this section explains the following:

For setting up preferred credentials for virtual server targets, select Oracle VM Server as the target type and click the Set Credentials icon.

On the <Target Type> Preferred Credentials page, in the Target Credentials section, for the Host target on which you want to provision, specify the user name and password. If you want to use default credentials, then specify the default credentials in the Default Credentials section.

Click Apply.

Setting Up Preferred Credentials for Patching

To register the credentials of the Oracle home (that you want to patch) as preferred credentials in Enterprise Manager Grid Control, run the set_credential verb using the Enterprise Manager Command Line Interface (EM CLI).

The preferred credentials set through EM CLI are specific to the Enterprise Manager Grid Control user with which the EM CLI is set up. Therefore, Oracle recommends you to use the central Enterprise Manager Grid Control accounts for this purpose, so the Database Administrators across board or a group can use this.

For more information about EM CLI, see Enterprise Manager Command Line Interface Guide available at:

Type of target. This must be "host" in case the -oracle_homes parameter is specified.

target_name

Name of the target. Omit this argument to set enterprise preferred credentials. This must be the host name in case the -oracle_homes parameter is specified.

credential_set

Credential set affected.

user

Enterprise Manager user whose credentials are affected. If omitted, the current user's credentials are affected.

columns

Name and new value of the column(s) to set. Every column of the credential set must be specified. Alternatively, a tag from the -input_file argument can be used so that the credential values are not seen on the command line. You can specify this argument more than once.

input_file

Path of file that has the -columns argument(s). This option is used to hide passwords. Each path must be accompanied by a tag referenced in the -columns argument. You can specify this argument more than once.

oracle_homes

Name of oracle homes on the target host. Credentials will be added/updated for all specified homes.

Refreshing Host Configuration

Before you run any Deployment Procedure, Oracle recommends you to refresh the configuration of the hosts. To do so, follow these steps:

In Grid Control, click Deployments.

On the Deployments page, in the Configuration section, click Refresh Host Configuration.

On the Refresh Host Configuration: Select Hosts page, from the Available Hosts pane, select the hosts, which the Deployment Procedure will use, and move them to the Selected Hosts pane.

Click Refresh Hosts.

Setting Up Infrastructure for Online Patching

This section describes the setup requirements for online patching. In particular, this section describes the following:

Enabling Online Mode

To patch the targets in online mode, you must set the connection setting in Enterprise Manager Grid Control to Online mode.

To set the connection setting to Online mode, follow these steps:

In Grid Control, from the top-right corner of the page, click Setup. Enterprise Manager Grid Control displays the Overview of Setup page.

On the Overview of Setup page, from the vertical menu pane to the left, click Patching Setup.

Enterprise Manager Grid Control displays the Patching Setup page with multiple tabs, where My Oracle Support and Proxy Connection tab is selected by default.

On the Patching Setup page, select Online and Offline Settings tab.

On the Online and Offline page, in the Settings section, select Online.

Click Apply.

Setting Up My Oracle Support Credentials and Proxy Connection Settings

In an online patching mode, a Refresh From My Oracle Support job is run periodically to automatically download XML files that are required for generating Patch Advisories. Also, the Deployment Procedures automatically download the required patches and patch sets from My Oracle Support every time they are run. For these purposes, Enterprise Manager Grid Control requires credentials to log in to My Oracle Support.

This section provides instructions that help you set up My Oracle Support credentials and proxy server details, if there are any, in Enterprise Manager Grid Control so that it can use these settings to connect to My Oracle Support.

To set up My Oracle Support credentials and proxy connection settings, follow these steps:

In Grid Control, from the top-right corner of the page, click Setup. Enterprise Manager Grid Control displays the Overview of Setup page.

On the Overview of Setup page, from the vertical menu pane to the left, click Patching Setup. Enterprise Manager Grid Control displays the Patching Setup page with multiple tabs, where My Oracle Support and Proxy Connection tab is selected by default.

On the My Oracle Support and Proxy Connection tab, do the following:

In the My Oracle Support section, provide the credentials to be used to access the My Oracle Support site. By default, Patch Search URL displays the URL where the patches will be searched.

If you want to verify the connectivity to My Oracle Support, then click Test. If the credentials are valid and if Enterprise Manager Grid Control is able to connect to My Oracle Support successfully, then a status message is displayed to this effect.

In the My Oracle Support Connection Setting section, do one of the following:

If the host where Enterprise Manager Grid Control is running has a direct connection to Internet, that is, without any proxy server, then select Direct Connection to the Internet.

If the host where Enterprise Manager Grid Control is running has a connection to Internet through a proxy server, then select Manual Proxy Configuration. And, depending on the protocol to be used (HTTP or HTTPS), specify the name of the proxy server, port, realm (if credentials are configured for realm), and credentials (if credentials are required for authentication).

The Connection Configuration subsection shows the default values set for Timeout and Number of Retries. Timeout indicates the time in milliseconds after which it should automatically time out if the connection takes unusually long time to connect to My Oracle Support. Number of Retries indicates the number of times it should retry connecting to My Oracle Support after timing out. Change the default values to higher values only if required.

In the Agent Connection Setting section, select the settings to be considered for all Management Agent-related communications.

If you want to use the settings specified in the My Oracle Support Connection String, then select Use My Oracle Support Connection Settings.

If the host where Management Agent is running has a direct connection to the Internet, that is, without any proxy server, then select Direct Connection to the Internet. The Connection Configuration subsection shows the default values set for Timeout and Number of Retries. Change the default values to higher values only if required.

If the host where Management Agent is running has a connection to Internet through a proxy server, then select Manual Proxy Configuration. And, depending on the protocol to be used (HTTP or HTTPS), specify the name of the proxy server, port, sites for which proxy must not be used, realm (if credentials are configured for realm), and credentials (if credentials are required for authentication).

In the Test URL section, to verify whether the Management Agent is reachable, specify a valid Management Agent URL and click Test. If the URL is valid and if Enterprise Manager Grid Control is able to reach the Management Agent successfully, then a status message is displayed to this effect.

Setting Up Online Settings

In an online patching mode, a Refresh From My Oracle Support job is run periodically to automatically download XML files that are required for Patch Advisories. Also, the Deployment Procedures automatically download the required patches and patch sets from My Oracle Support every time they are run. For these purposes, Enterprise Manager Grid Control needs to know where the XML files should be stored and the size limit of patch cache up to which it can store the downloaded patches and patch sets.

This section provides instructions that help you set up these online settings.

To set up online settings, follow these steps:

In Grid Control, from the top-right corner of the page, click Setup. Enterprise Manager Grid Control displays the Overview of Setup page.

On the Overview of Setup page, from the vertical menu pane to the left, click Patching Setup.

Enterprise Manager Grid Control displays the Patching Setup page with multiple tabs, where My Oracle Support and Proxy Connection tab is selected by default.

On the Patching Setup page, select Online and Offline Settings tab.

On the Online and Offline page, do the following:

In the Settings section, retain the default connection setting, that is, Online, and set the patch cache size.

Patch Cache is a repository where all downloaded patches are stored. By default, the maximum size or capacity of patch cache is set to 700 MB, which means it can store patches only up to the limit of 700 MB. Once the patch cache reaches this size, all older patches will be automatically deleted to free up some space.

In the Patch Validation for Critical Patch Advisories for Oracle Home section, retain the default validation setting, that is, No.

Patch Validation validates the patches that must be recommended to Database Administrators on the Critical Patch Advisories page. By default, No is selected and this ensures that all patches are recommended. If you select Yes, then only those patches that are validated by the Super User are recommended. However, this does not prevent the patches from getting staged or applied.

Dump Directory is a directory where My Oracle Support metadata files can be stored. By default, the dump directory is a temporary storage location on the host where Oracle Management Service is running. The metadata files are XML files required for patch advisories and they are downloaded automatically in an online patching mode.

Click Apply.

Setting Up Infrastructure for Offline Patching

This section describes the setup requirements for offline patching. In particular, this section describes the following:

Enabling Offline Mode

To patch the targets in offline mode, you must set the connection setting in Enterprise Manager Grid Control to Offline mode.

To set the connection setting to Offline mode, follow these steps:

In Grid Control, from the top-right corner of the page, click Setup. Enterprise Manager Grid Control displays the Overview of Setup page.

On the Overview of Setup page, from the vertical menu pane to the left, click Patching Setup.

Enterprise Manager Grid Control displays the Patching Setup page with multiple tabs, where My Oracle Support and Proxy Connection tab is selected by default.

On the Patching Setup page, select Online and Offline Settings tab.

On the Online and Offline page, in the Settings section, select Offline.

Click Apply.

Applying One-Off Patch

From My Oracle Support, manually download patch 6880880 for the required platform and version of the target you are patching, and upload it to the Software Library. This is a platform-specific patch, so you will have to carefully select the platform while downloading this patch.

For example, if you are patching Oracle Database 11g Release 1 (11.1) that is running on Linux x86, then download patch 6880880 for the Linux x86 platform and for the 11.1.0.0.0 release.

To upload this patch to the Software Library, follow these steps:

In Grid Control, click the Deployments tab.

On the Deployments page, from the Patching section, click View/Upload Patch.

On the Patch Cache page, click Upload Patch.

On the Create Oracle Software Update Component page, in Patch File, specify the full path to the patch file. Alternatively, click Browse to browse your system and select the patch.

And in the Patch Attributes section, specify critical information about the patch.

IMPORTANT:

Ensure that you upload it under the product family "System Management Products and Product - Universal Installer" with the appropriate release and platform details.

Click Upload.

Identifying Affected Targets and Required Patches

The information about the targets affected by the latest patches and the patch you have to manually download is available in metadata XML files. In an offline mode, you must use another host that has internet connection and manually download these XML files from My Oracle Support.

Uploading Information Required by Oracle Patch Advisories

The information required by Oracle Patch Advisories are available in metadata XML To upload these files, follow these steps:

In Grid Control, from the top-right corner of the page, click Setup. Enterprise Manager Grid Control displays the Overview of Setup page.

On the Overview of Setup page, from the vertical menu pane to the left, click Patching Setup.

Enterprise Manager Grid Control displays the Patching Setup page with multiple tabs, where My Oracle Support and Proxy Connection tab is selected by default.

On the Patching Setup page, select Online and Offline Settings tab.

On the Online and Offline Settings page, in the Metadata Cache section, upload the metadata XML files to the Management Repository:

Click Apply.

Creating "Refresh From My Oracle Support" Job

To extract information from the metadata XML files and display them in Oracle Patch Advisories, you must schedule a job, that is, a "Refresh From My Oracle Support" job.

Although the name of the job reads "Refresh From My Oracle Support", it does not actually connect to My Oracle Support because of the offline connection setting you enabled in Enabling Offline Mode. Since it is set to Offline, the job looks for these XML files only in the Management Repository.

On the Job Activity page, from the Create Job list, select Refresh From My Oracle Support and click Go. Enterprise Manager Grid Control displays the Create 'Refresh From My Oracle Support' Job page.

On the Create 'Refresh From My Oracle Support' Job page, specify a name for this job, schedule it to run at a particular time, and grant access to roles that must have access to this job.

Click Submit.

Uploading OPatch Patches to Oracle Software Library

From My Oracle Support, manually download patch 6880880 for the required platform and the version of the target you are patching, and upload it to Oracle Software Library (Software Library). This is a platform-specific patch, so you will have to carefully select the platform while downloading this patch.

For example, if you are patching Oracle Database 11g Release 1 (11.1) that is running on Linux x86, then download patch 6880880 for the Linux x86 platform and for the 11.1.0.0.0 release.

To upload patches to the Software Library, follow these steps:

Ensure that you upload it under the product family "System Management Products and Product - Universal Installer" with the appropriate release and platform details.

On the Deployments page, from the Patching section, click View/Upload Patch. Enterprise Manager Grid Control displays the Patch Cache page.

On the Patch Cache page, for Patch File, click Browse to upload the patch. In the Patch Attributes section, specify details about the patch. Ensure that you upload it under the product family "System Management Products and Product - Universal Installer".

Identifying Patch from Oracle Patch Advisories

After the "Refresh From My Oracle Support" job completes, Oracle Patch Advisories show details about the Oracle homes that are affected by the latest patches. From here, identify the patch you have to download.

From Oracle Patch Advisories, to identify the patch you must download and apply to your targets, follow these steps:

On the Deployments page, from the Critical Patch Advisories for Oracle Homes section, view the critical patch advisories and the affected Oracle homes.

Click the number of the Patch Advisories. Enterprise Manager Grid Control displays the Critical Patch Advisories for Oracle Homes page.

On the Critical Patch Advisories for Oracle Homes page, identify the patch you have to download.

Uploading Patch to Oracle Software Library

For patching targets in offline mode, you must have already stored the patch in Software Library so that the Deployment Procedure can retrieve it from there and apply it to the affected targets. For this purpose, you must upload the patch to Software Library.

On the Create Oracle Software Update Component page, do the following:

For Patch File, click Browse and select the patch you had manually downloaded from My Oracle Support.

Note:

If you are uploading an opatch patch using Enterprise Manager 10g Grid Control Release 5 (10.2.0.5), then ensure that you upload opatch patch number 6880880 that is specific to the platform on which you want to apply the patch. For example, if you want to upload Opatch 11.1 for the Linux x86 platform, then ensure that you upload p6880880_111000_LINUX.zip.

In the Patch Attributes section, specify the attributes of the patch. You can find these details in the ReadMe file of the patch.

Click Upload.

Setting Up Infrastructure for Linux Patching

This section describes the setup requirements for Linux patching. In particular, this section describes the following:

Ensure that ULN staging host is able to communicate with the ULN network. If proxy is required, up2date from the host needs to be configured as well. The connectivity with ULN will be detrimental for up2date –register –nox command.

Patch user (OS credentials used to setup the Staging server) must have write permission under the agent home. Patch user must also have SUDO privilege.

Setting Up the RPM Repository

To set up an RPM Repository that downloads latest RPM packages and Advisories from ULN, follow these steps.

In Grid Control, from the top-right corner of the page, click Setup and select Patching Setup.

In the Linux Patching Setup tab, click the Setup RPM Repository link.

In the Setup Linux RPM Repository section, select the RPM Repository server by clicking the search icon. Select the machine assigned for subscribing to ULN.

In the Credentials section, specify the user name and password to use. Click Apply.

In the Phase Status page, click the link "Register with ULN"and do the following:

Log in to the RPM Repository server machine.

Configure up2date to use a proxy server, if any, by following the instructions at:

https://linux.oracle.com/uln_faq.html - 9

Register the machine to ULN by following the steps at:

https://linux.oracle.com/uln_faq.html - 2

Note:

While registering, you can choose the user name and password. This credential will be used to log in to http://linux.oracle.com

After registering the host, select the target and click Confirm, and then click Done to go to the main flow.

Click the link "Subscribe to ULN channels". Do the following:

When you register a server, it will be subscribed to a channel that has the latest Enterprise Linux packages for the appropriate architecture. To subscribe to additional channels, log in to http://linux.oracle.com after you register your system. Click on the Systems tab to manage subscriptions for each subscribed server.

Type the command up2date –nox –show-channels to verify the list of subscribed channels.

Once the deployment procedure completes successfully, go to Setup, select Patching Setup, and then select Manage RPM Repository to verify if the ULN channels are displayed in the Enterprise Manager Console.

In the Manage Repository Home page, check if all the subscribed channels are listed and if all the packages are downloaded.

Setting Up Linux Patching Group for Compliance Reporting

This section describes how you can set up a Linux Patching group for compliance reporting by associating the group with the RPM Repository (each subscribed ULN channel is a repository) created in Setting Up the RPM Repository.

Prerequisites for Setting Up Linux Patching Group

Before setting up the Linux Patching Group, meet the following prerequisites:

RPM Repository server must be set up or a custom RPM Repository must be set as a channel in Enterprise Manager.

Yum or up2date should be installed in the target machines.

Sudo must be installed on the target machines.

You must have Operator privileges on the hosts that you want to add to the Linux host patching group.

Patch user must have write access under the agent home. Patch user must have sudo privilege.

Setting Up a Linux Patching Group

To set up a Linux patching group, do the following:

In Grid Control, from the top-right corner of the page, click Setup and select Patching Setup.

In the Linux Patching Setup tab, click the Setup Groups link.

In the Setup Groups page, click Create.

In the Create Group: Properties page, specify a unique name for the group. Select the maturity level, Linux distribution, and Linux hosts to be added to the group. Click Next.

In the Create Group: Package Repositories page, select the RPM Repositories to be associated with the group (click the search icon to select repository).

Select Automatically Update Hosts if you want to auto-update the host, that is, to schedule an update job (schedule specified as one of the subsequent step) to update all non-compliant packages from the select package repository.

Under the "Package Compliance" section, choose whether to include "Rogue" packages in compliance reporting or not.

Click Next.

In the Create Group: Credentials page, specify the host credentials or choose to use preferred credentials. Click Next.

If Automatically Update Hosts is not selected, the steps, "Patching Scripts" and "Schedule" pages will be skipped.

In the Patching script page, you can specify any pre/post patching operations to be done. This is not a mandatory step.

In the Schedule Page, select the schedule for the "Update Job". Click Next.

Validate all the parameters in the Review page. Click Finish.

On clicking Finish, three jobs will be submitted if you have not selected the Automatically Update Hosts option. If the option is selected, then four jobs will be submitted. Table 3-3 explains the jobs submitted. Follow the jobs submitted by clicking the job's link.

Go to Deployments > Linux Patching page. Verify the compliance report generated. The group created will have at least one out-of-date package.

Table 3-3 Jobs Submitted for Setting Up Linux Patching Group

Job

Description

Patching Configuration

This job configures all the hosts for patching. It creates configuration files to be used by yum and up2date tool.

Compliance Collection

Compares the packages already installed in the machine with the packages versions in the selected RPM Repositories and generates Compliance Reports.

Package Information

Collects metadata information from the selected RPM Repositories.

Packages Update

Updates non-compliant packages.

Setting Up Infrastructure for Virtualization Systems

To start using guest virtual machines, you will need to perform the following setup activities:

Configuring Virtual Servers

The virtual server will need to be configured before it can be registered with the server pool to enable Enterprise Manager to perform monitoring, administration, and provisioning.

Create /OVS mount points for shared storage on the Oracle VM server.

No more than 24 Oracle VM servers must be registered and managed with one Oracle Management Agent.

Enterprise Manager supports only Oracle VM server version 2.1.2 or above. All Oracle VM servers version 2.1.2 or above managed by Enterprise Manager should be updated to have OVS agent of version 2.2-70 or higher.

If a user other than root is used to connect to the virtual server, /etc/sudoers file must be updated to give "sudo all" privilege to this user. To provide sudo privilege for non-root user, add the following entry:

<non-root user> ALL=(ALL) ALL

In addition, comment out the following line:

Defaults requiretty

Creating Server Pools

It is essential that you create a server pool to manage all Oracle VM servers. Server pools can be created with the high-availability option enabled or not. A server pool must have a minimum of one virtual server registered with it.

Specifies either FQDN name or IP address of the master virtual server for the server pool.

Monitoring Server Agent

Specifies the Management Agent that will monitor the virtual server.

Monitoring Server User

Specifies the operating system user that owns the Management Agent home/Management Agent install, and has read and write permission on the Management Agent home directory.

Monitoring Server Password

Specifies the password credentials for the monitoring server user.

SSH Username

Specifies the user on the virtual server who has sudo privileges.

SSH Password

Specifies the password credentials for the SSH user.

Oracle VM Agent Password

Specifies the password of the Oracle VM Agent running on the virtual server.

OVS Proxy Location

Specifies a directory on the virtual server where the scripts required for monitoring and administration are stored when the virtual server is registered with Enterprise Manager Grid Control.

Registering Virtual Servers

For Enterprise Manager Grid Control to monitor and manage a virtual server, you must register it with a server pool. Once you create a master virtual server, you can also register other virtual servers to the server pool.

In the Register Virtual Server page, specify details of the virtual servers to be registered as shown in Table 3-5. Click Add Another Row to specify multiple virtual servers details.

You can batch assign details to different virtual servers and click Assign to specify common details for multiple virtual servers.

You can add a virtual server from file by clicking Add From File. Select the file from a local machine or a host machine in Enterprise Manager. The file should contain details of the virtual servers in the following format:

Creating Super Administrator for Enterprise Manager

Only a user who is a Super Administrator for Enterprise Manager can configure various elements like stage server, boot server etc. for use with the Provisioning Application. Not only that, it is only these users who can actually create assignments for actually provisioning target machines with any image. For more information about assignments, see Assignments.

Follow the steps below to create a user who is a super administrator.

Log into the Enterprise Manager and click on the Setup link on top right hand corner as shown in the picture below.

On the Setup page, click on the Administrators link on the left hand side column.

On the Administrators page, click Create as shown below.

On the Create step that comes up fill up the necessary details as shown and select the Super Administrator check box as shown below. Click Next.

On the Review page, click Finish to complete the user creation.

Setting Up Boot Server

This section explains how to set up the boot server. Following are the prerequisites:

2 GB RAM for boot server, stage server, and RPM repository server.

Boot server and stage server must be on the same physical machine.

If boot server and stage server reside on different machines, then the boot install directory (/tftpboot/linux-install) should be mounted on the stage server.

The two servers could be running either on the same machine, or on different machines. Oracle recommends running the TFTP server on the same host machine as the DHCP server. In case the two servers are installed and configured on different machines, the machine running the TFTP server will be referred to as the boot server.

Configure the TFTP server:

Ensure that the pxelinux boot loader (pxelinux.0) exists in the directory that is configured for your TFTP server (/tftpboot/linux-install in the given examples).

The next-server option in the DHCP configuration file specifies the host name or IP Address of the machine hosting the TFTP server. Oracle recommends running the TFTP Server on the same host machine as the DHCP Server. Therefore, this address should be the IP Address or hostname for the local machine.

The filename option specifies the boot loader location on the TFTP server. The location of the file is relative to the main TFTP directory.

Any standard DHCP configuration file is supported.The sample file format above shows one entry (line 12-15) for each target host. The DHCP service must be restarted every time you modify the configuration file.

Enable the tftp service. Edit the /etc/xinetd.d/tftp file to change the disable flag as no (default=no).

Restart the following services:

service dhcpd restart
service xinetd restart
service portmap restart

Install Oracle Management Agent.

Note:

Refer to the "Installing Management Agent" chapter in Oracle Enterprise Manager Grid Control Installation Guide to install a 10.2.0.3 or higher version of Management agent on the boot server.

Setting Up Stage Server

Stage server must meet the following requirements:

Large Storage

The files related to components and directives of an image are first copied to the stage server in preparation for the network installation, and are kept there for future use. The stage server thus acts as a huge cache of files, which requires a large storage.

The stage server can also host the staging storage on Network Attached Storage(NAS). Multiple stage servers can use the same NAS.

High Memory

The stage directives associated with the components and images are directives that are executed during staging phase of a component or Image. They contain commands to unpack and layout the files in order to facilitate the network installation. Depending on the size of the components and images, these commands place high memory requirements on part of the stage server.

Sufficient Bandwidth

Staging process could be very time consuming if the network between the Stage server and software library (on Oracle Management Service or OMS Server) does not have sufficient bandwidth to enable fast transfer of files. Similarly, the link between the stage server and hardware servers should have high bandwidth to make the installation process faster.

NFS or HTTP Support

During the installation, hardware servers mount the stage directory so that all the files required for installation appear as local files. In such a scenario, the stage server functions as the NFS server and the hardware servers as its clients. If the stage server uses NAS for staging storage, the NAS server should have the NFS support.

If the stage server cannot have NFS support, it must be accessible by HTTP.

Follow the instructions listed below to set up a Linux machine as the stage server:

Create a top-level directory

Create a top-level directory on the stage server where all the files will be stored. In the following steps, STAGE_TOP_LEVEL_DIRECTORY refers to the absolute path of this top-level directory. For provisioning 32-bit and 64-bit targets, separate STAGE_TOP_LEVEL_DIRECTORY is required.

You can specify the HTTP or NFS location of agent rpms when you set up a default image in the Provisioning application. Alternatively, you can copy agent rpms to STAGE_TOP_LEVEL_DIRECTORY so that they are picked up automatically.

Oracle recommends that the stage server must have very limited access due to the criticality and sensitivity of the data it hosts. The super administrator can enforce this by creating one account on the stage server, and setting it as the preferred credential, to be used by all the provisioning users in Enterprise Manager. This preferred credential should also be a valid ORACLE_HOME credential (belonging to ORACLE_HOME owner's group).

Setting Up RPM Repository

Note:

It is recommended that you use RAM of 2 GB.

Setting UP RHEL 4 RPM Repository

RPM Repository is used as the source of Linux and application packages that need to be installed on the newly provisioned bare metal box. For example, an RPM Repository may be created to contain all the 32-bit Linux rpms and another repository may be created to contain Linux x86-64 bit rpms. Two separate Linux images can then be created each based on one of the repositories.

RHEL RPM repository to be used should have the following Red Hat Install tree structure:

There are multiple ways to create a RPM repository. If Red Hat Enterprise Linux CDs are available, do the following:

Copy all the contents of the first CD to a directory say RPM_REPOS.

Copy all rpms from other CDs to <RPM_REPOS>/Redhat/RPMS. Change directory to the RPMS directory:

cd <RPM_REPOS>/Redhat/RPMS

Add custom RPMs to the repository.

If there are custom RPMs installed on the reference host that need to be provisioned on the bare metal machine, make sure to copy them to the following repository location:

<RPM_REPOS>/Redhat/RPMS

Install anaconda-runtime RPM on the machine hosting the RPM repository. This might require other dependent packages to be installed.

This should create a headers directory. Make sure this directory contains a header.info file.

If yum is not installed then download it from the Linux Vendor's Web site.

Create a symbolic link in /var/www/html to <RPM_REPOS> directory.

The repository should now be available through http if an apache server is running.

Note:

If the Apache server that comes with Enterprise Manger Grid Control 10g is used, enable the Apache directory index page using the "Options Indexes" directive in the Apache configuration (httpd.conf) file.

Copy all the contents of the first CD to a directory say Root Directory.

Copy all contents from the Cluster, ClusterStorage, Server, and VT directories in the other CD to the respective directories.

For setting up RPM repository for OVS provisioning, copy RPMs from Oracle, Server, and VT directories to the respective directories.

Run createrepo for all four directories. For example:

createrepo <Root Directory>/cluster

Add custom RPMs to the repository as follows:

If there are custom RPMs installed on the reference host that need to be provisioned on the bare metal machine, make sure to copy them to the directory containing the RPMS, such as Cluster, VT, ClusterStorage, and Server.

Run the createrepo command on this directory. For example:

createrepo ClusterStorage

Create a symbolic link in /var/www/html to <Root Directory> directory.

The repository should now be available through http if an apache server is running.

Setting Up Software Library

Software Library should be located in a directory accessible by all OMSes. If there is one OMS the directory can be local. For multiple OMS environments, the directory can be on a Network File Server or a Netapp filer that is accessible from all the OMSes. One has to ensure that there is enough space available on the shared storage to store files that hold the binary data for one's components.

Software components that are generated as part of the default or single-server image creation during the bare metal provisioning process are stored in the Software Library. They are accessible under the Components tab in the Provisioning Application user interface.

Ensure that the shared storage is accessible through NFS mount points to all OMS servers in the environment.

Preferred credentials simplify access to managed targets by storing target login credentials in the Management Repository. With preferred credentials set, users can access an Enterprise Manager target that recognizes those credentials without being prompted to log into the target. Preferred credentials are set on a per user basis, thus ensuring the security of the managed enterprise environment.

Enterprise Manager supports two types of preferred credentials:

Normal Credentials: Are used by Enterprise Manager functions that need operating system access, but do not require administrator privileges.

Privileged Credentials: Are used by functions that need administrator privileges. Credentials for users that have sudo access on the target machine can be used as privileged credentials.

The Provisioning application requires preferred credentials to be setup for machines, which are part of the application.The preferred credentials need to be set for the following machines:

Referenced Installation Host: Privileged credentials are needed to execute the command to get all the available RPMs form this machine. The credentials should also be valid ORACLE_HOME credentials (belonging to ORACLE_HOME owner's group)

Stage Server: You must set the privileged preferred credentials for the stage server. Oracle recommends the stage server to have very limited access due to the criticality and sensitivity of the data it hosts. The super administrator can enforce this by creating one account on the stage server, and setting it as the preferred credential, to be used by all the provisioning users in Enterprise Manager. This preferred credential should also be a valid ORACLE_HOME credential (belonging to ORACLE_HOME owner's group).

Provisioning Targets: In case you are planning to provision existing target machines, ensure the privileged credentials are setup. These credentials are required to clear the boot-sector and reboot the machine.

It is recommended that you do not use root as the preferred credentials.

Accessing the Bare Metal Provisioning Application

To access the Bare Metal Provisioning Application, do the following:

Log in to Oracle Enterprise Manager.

The Provisioning application can be accessed by going to the Deployments Tab and then to Provisioning sub tab, as shown below.

The graphical user interface of the provisioning application shows various tabs for Components, Directives, and Images etc. A user can access all or some tabs shown above depending upon the privileges assigned to him. For example, in the figure below, the Administration and Assignments tabs are disabled for the user. Refer to Creating Super Administrator for Enterprise Manager for creating users that can access the Administration tab.

In this section, we will assume that the user has super user privileges and can thus access the administration tab. This tab contains different sections for configuring different elements in the environments.

Configuring Stage Server

In this section, it is assumed that the stage server has been created and the necessary setup has been done.