41 Patching Linux Hosts

This chapter explains how you can patch Linux hosts using Oracle Enterprise Manager Cloud Control (Cloud Control). In particular, this chapter covers the following:

Note:

To understand how you can use Enterprise Manager Ops Center to update or patch Linux hosts, refer to the chapter on updating operating systems in the Oracle Enterprise Manager Ops Center Provision and Update Guide.

41.1 Overview of Patching Linux Hosts

Linux Host Patching is a feature in Cloud Control that keeps the hosts in an enterprise updated with security fixes and critical bug fixes, especially in a data centre or a server farm. This feature in Cloud Control enables you to:

  • Set up Linux RPM Repository based on Unbreakable Linux Network (ULN) channels

  • Download Advisories (Erratas) from ULN

  • Set up a Linux Patching group to update a group of Linux hosts and collect compliance information

  • Allow non-compliant packages to be patched

  • Rollback/uninstall packages from a host

  • Manage RPM repositories and channels (clone channels, copy packages from one channel into another, delete channels)

  • Add RPMs to custom channels

  • Manage configuration file channels (create/delete channels, upload files, copy files from one channel into another)

The following are concepts related to Linux patching:

Linux Host A host target in Cloud Control that is running the Linux operating system.
Linux Patching Group A set of managed Linux hosts that are associated with a common list of RPM repositories. Every group is configured with an update schedule, according to which a recurring job is triggered, that will update the hosts of the group with the associated RPM repositories.
Unbreakable Linux Network (ULN) Unbreakable Linux Network (ULN) is a Web site hosted by Oracle to provide updates for Oracle Linux.
ULN Channel A channel is a group of RPM packages on ULN. For example, the el4_latest channel contains all the packages for Oracle Linux 4.
RPM Repository RPM repository is a directory that contains RPM packages and their metadata (extracted by running yum-arch and createrepo). The RPM repository is accessible via http or ftp. An RPM repository can be organized to contain packages from multiple channels.

For example, /var/www/html/yum/Enterprise/EL4/latest might contain packages from the el4_latest channel on ULN.

Custom Channel A channel that is created by the user to store a set of custom RPM packages. Custom channels can be added to the RPM repository.
Configuration Channel A channel that is created by the user to store a set of Linux configuration files. Configuration channels can be used in the Linux patching application GUI to deploy configuration files on Linux hosts.

41.2 About the Deployment Procedure for Patching Linux Hosts

Cloud Control provides the following deployment procedures for Linux patching:

  • Patch Linux Hosts

    This deployment procedure enables you to patch Linux hosts.

  • Linux RPM Repository server setup

    This deployment procedure enables you to set up a Linux RPM repository server. To set up the Linux RPM repository server, refer to Section 41.4.2.2.

41.3 Supported Linux Releases

The following releases are supported for Linux patching:

  • Oracle Linux 4

  • Oracle Linux 5

  • Oracle Linux 6

  • Red Hat Enterprise Linux 4

  • Red Hat Enterprise Linux 5

  • Red Hat Enterprise Linux 6

41.4 Setting Up Infrastructure for Linux Patching

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

41.4.1 Prerequisites for Using the Linux Patching Feature

To use the Linux Patching feature, meet the following prerequisites:

  1. Meet the basic prerequisites described in Chapter 2.

  2. Install yum on all your Oracle Linux 6 target hosts. Install yum and up2date on all your Oracle Linux 5 target hosts.

  3. Enable the following commands through SUDO:

    • /bin/cp

    • /bin/rm

    • /bin/chmod

    • /sbin/chkconfig

    • yum

    • up2date

    • sed

    • rpm

41.4.2 Setting Up the RPM Repository for Linux Patching

This section describes how you can set up the RPM repository. In particular, this section describes the following:

Note:

The RPM repository can be set up in a shared location. This configuration is supported.

41.4.2.1 Prerequisites for Setting Up the RPM Repository

Before setting up the RPM repository, meet the following prerequisites:

  • Identify a Redhat or Oracle Linux host, install a Management Agent, and point to the OMS. This host must have the sudo package installed.

  • Obtain a valid Customer Support Identifier (CSI) number from your Oracle sales representative.

    After obtaining a valid CSI number, ensure that you create a ULN account. To create a ULN account, access the following URL:

    https://linux.oracle.com/register

  • Download the up2date packages from the following URL:

    https://linux.oracle.com/switch.html">>https://linux.oracle.com/switch.html

    Upload the downloaded packages to Software Library if the host on which you plan to set up the RPM repository is running on one of the following platforms:

    • Red Hat Enterprise Linux 4 (x86_64)

    • Red Hat Enterprise Linux 4 (ia64)

    • Red Hat Enterprise Linux 5 (i386)

    • Red Hat Enterprise Linux 5 (x86_64)

    • Red Hat Enterprise Linux 5 (ia64)

    Important:

    You do not need to upload the up2date packages to Software Library if the host on which you plan to set up the RPM Repository is running on an Oracle Linux platform.

    Follow these steps to upload up2date packages to the Software Library:

    Note:

    For a multi-OMS setup, the following steps only need to be performed on one OMS.
    1. Compress up2date and up2date-gnome into a zip file, and name it as up2date_comp.zip.

    2. Copy the zip file to the <ORACLE_HOME>/sysman/metadata/swlib/patch/stageServerComponents directory present in the Oracle home of the OMS.

    3. Edit the Patch Software Library entities metadata file swlib.xml present in the Oracle home of the OMS to upgrade the ExternalID of the Software Library entity Up2date Package Component.

      To do so, follow these steps:

      (1) Open the swlib.xml file present at the following location: $ORACLE_HOME/sysman/metadata/swlib/patch/

      (2) Search for the tag <Entity name="Install up2date RPM">, which in turn has a subtag ExternalID.

      (3) Increase the values of the ExternalID by 0.1.

      For example, if the original value of the entity in the software library's ExternalID is 2.0, then update the value by 0.1 to upgrade the ExternalID to 2.1.

    4. Upload the zip file to Software Library by running the following command:

      $ emctl register oms metadata -service swlib -file $ORACLE_HOME/sysman/metadata/swlib -core

  • Ensure that the /var/www/html/ directory on the host on which you plan to set up the RPM repository has at least 60 GB of free disk space per channel.

  • Ensure that Apache is installed, and listening on port 80. To verify this, you can try connecting to the URL: http://host.

    For example: http://h1.example.com. If this works, then it is confirmed that Apache is installed and listening on port 80.

  • Ensure that the createrepo package is installed on the RPM Repository host. To obtain this package, subscribe to the el*_addon or the ol*_addon channel.

  • Ensure that the yum-arch, uln-yum-proxy, and yum-utils packages are installed on the RPM Repository host. To obtain the yum-arch and the uln-yum-proxy packages, subscribe to the add ons channel. To obtain the yum-utils package, subscribe to the latest channel.

  • If the RPM Repository host is not running on Oracle Linux 6 (OL6), but is subscribed to an OL6 channel whose name is of the format ol6_*, then you must import the OL6 public key manually. To do so, follow these steps:

    1. Download the OL 6 key from:

      http://public-yum.oracle.com/RPM-GPG-KEY-oracle-ol6

    2. Store it under the following directory on your host:

      /usr/share/rhn

    3. Run the following command:

      rpm --import /usr/share/rhn/RPM-GPG-KEY-oracle-ol6

  • Ensure that the Enterprise Manager user has the EM_LINUX_PATCHING_ADMIN role and the FULL_LINUX_PATCHING_SETUP privilege. If the Enterprise Manager user does not have these, ensure that the super user grants them.

  • Ensure that the Oracle GPG keys are installed on the host on which you plan to set up the RPM Repository.

    To install the Oracle GPG keys on a host running on the Oracle Linux 5 or Oracle Linux 6 platforms, run the following command:

    rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY

41.4.2.2 Setting Up the RPM Repository for Patching

To set up an RPM Repository that downloads the latest RPM packages and advisories from ULN, follow these steps:

  1. In Cloud Control, from the Setup menu, select Provisioning and Patching, then select Linux Patching.

  2. On the Patching Setup page, in the Linux Patching Setup tab, click Setup RPM Repository.

  3. On the Setup RPM Repository page, in the RPM Repository Server section, select the RPM Repository server by clicking the search icon. Select the host assigned for subscribing to ULN.

  4. In the Credentials section, ensure that the Normal Host Credential user has write access to the stage location, and the Privileged Host Credential user can sudo with root privilege. Click Apply.

  5. In the Deployment Procedure submission confirmation, click Linux RPM Repository Server Setup. The deployment procedure starts a job to download latest RPM packages and Advisories from the subscribed ULN channels.

  6. (Optional) If you want to change the refresh mode to 30 seconds, then from the View Data list, select Real Time: 30 Second Refresh.

  7. In the Steps tab of the Status Detail section, check the status of this step. Wait till the step Installing Up2date is completed or skipped.

  8. Click the status of the manual step Register with ULN to verify if your host has been registered to ULN.

    If you have registered your host to ULN, then select the target and click Confirm, and then click Done to go to the main flow.

    If you have not registered your host to ULN, then perform the following steps on your Linux host:

    1. Log in to the RPM Repository server machine.

    2. Check if your host can connect to ULN. If you host cannot connect to the ULN directly, you can Configure up2date to use a proxy server. To configure access to ULN using a proxy server, follow these instructions:

      https://linux.oracle.com/uln_faq.html#9
      
    3. Register the host 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">>http://linux.oracle.com
  9. Click the status of the step Subscribe to ULN channels.

    When you register a Linux server to ULN, it will be subscribed to a channel that has the latest Oracle Linux packages for the appropriate architecture. If no additional channels are needed to be subscribed to your host, then select the target and click Confirm, and then click Done to go to the main flow.

    If some additional channels are needed to be subscribed to your host, then perform the following steps:

    1. Log in to ULN:

      http://linux.oracle.com/

    2. Click on the Systems tab to manage subscriptions for each subscribed server.

    3. Subscribe to all the additional channels you need.

      Note:

      • If the createrepo package is not installed on your Linux host, subscribe to the el*_addon or the ol*_addon channel.

      • Ensure that the yum-arch, uln-yum-proxy, and yum-utils packages are installed on your Linux host. To obtain the yum-arch and the uln-yum-proxy packages, subscribe to the add ons channel. To obtain the yum-utils package, subscribe to the latest channel.

    4. Verify the list of subscribed channels on ULN.

  10. Once the deployment procedure ends successfully, from the Setup menu, select Provisioning and Patching, then select Linux Patching.

  11. On the Patching Setup page, in the Linux Patching Setup tab, click Manage RPM Repository to verify if the ULN channels are displayed in the Cloud Control console.

  12. On the Manage RPM Repository page, check if all the subscribed channels are listed and if all the packages are downloaded.

41.4.3 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 Section 41.4.2.

In particular, this section describes the following:

41.4.3.1 Prerequisites for Setting Up Linux Patching Group

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

  • Set up RPM Repository server or set a custom RPM Repository as a channel in Cloud Control.

  • Install yum on all your Oracle Linux 6 target hosts. Install yum and up2date on all your Oracle Linux 5 target hosts.

  • Install Sudo on the target hosts.

  • Ensure that the Enterprise Manager user has the EM_LINUX_PATCHING_ADMIN role and the FULL_LINUX_PATCHING_SETUP privilege. If the Enterprise Manager user does not have these, ensure that the super user grants them.

41.4.3.2 Setting Up a Linux Patching Group

To set up a Linux patching group, follow these steps:

  1. In Cloud Control, from the Setup menu, select Provisioning and Patching, then select Linux Patching.

  2. On the Linux Patching Setup page, click Setup Patching Groups.

  3. On the Setup Patching Groups page, click Create.

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

  5. On the Create Group: Package Repositories page, select the RPM Repositories that must be associated with the patching group (click the search icon to select repository).

    In the Check GPG Signatures section, select Check GPG signatures to ensure that yum or up2date performs a GPG signature check on the packages obtained from the specified repositories. Sometimes, yum or up2date may require a public GPG key to verify the packages obtained from the repositories. This key may not be previously imported into the RPM database. To ensure that this key is imported, select Import GPG key, then specify the GPG Key URL.

    In the Stage Location section, specify the location where you want the Linux patching configuration and log files to be created.

    In the Update Hosts section, 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 selected package repository.

    In the Excluded Packages section, for Excluded Packages, specify the list of packages that you do not want to update while patching the Linux hosts. If the list of packages that you do not want to update during the patching process is present in a file, click Import From File to specify the location of the file. The wizard obtains the required packages from the specified file.

    In the Rollback Last Update Session section, select Enable 'Rollback Last Update Session' to enable the Rollback Last Update Session feature for the group in the Undo Patching wizard. If this feature is not enabled here, it is not visible in the Undo Patching wizard for the group.

    In the Package Compliance section, you can choose whether to include Rogue packages in compliance reporting or not.

    In the Packages Updated on Reboot section, for Packages updated on Reboot, specify the list of packages that must be updated only when the host is rebooted.

  6. Click Next.

  7. On the Create Group: Credentials page, enter the host credentials or choose to use preferred credentials. Click Next.

  8. On the Create Group: Patching Script page, enter any pre/post patching operations to be done. This is not a mandatory step. Click Next.

    Note:

    Steps (8) and (9) will be skipped if Automatically Update Hosts was not selected.
  9. On the Schedule page, set the schedule for the update job. Click Next.

  10. On the Review page, validate all the parameters. Click Finish.

  11. From the Enterprise menu, select Provisioning and Patching, then select Linux Patching. Verify the compliance report generated. The group created will have at least one out-of-date package.

    Table 41-1 describes the jobs that are submitted for setting up a Linux patching group.

    Table 41-1 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 the yum and up2date tools on each host.

    This job is executed just once on all the hosts contained in the Linux Patching group immediately.

    Compliance Collection

    Compares the versions of the packages already installed in each machine contained in the Linux Patching group with the package versions in the selected RPM Repositories, and generates Compliance Reports for indicating which packages are outdated.

    This job is executed once every 24 hours (after the group is set up) on all the hosts contained in the Linux Patching group.

    Package Information

    Collects the metadata information of each package contained in the selected RPM Repositories.

    This job is executed daily.

    Packages Update

    Updates non-compliant packages.

    This job will update the packages installed on the hosts in the group to ensure that they are up-to-date with respect to the package repositories for that group. This job will be submitted only when the option "Update Hosts" is selected in the step "Package Repositories" of the Linux Patching group wizard, and its schedule can be customized in the step "Schedule"


41.5 Patching Linux Hosts

This section describes how to patch your Linux hosts. It consists of the following:

Important:

Before patching your Linux hosts, ensure that the Enterprise Manager user has the EM_PATCH_DESIGNER role and the OPERATOR_ANY_TARGET privilege. If the Enterprise Manager user does not have these, ensure that the super user grants them.

41.5.1 Applying Patches on a Linux Patching Group Based on Compliance

If the Linux Patching Compliance Home page reports that a particular Linux patching group is not compliant, you can choose to patch the group. To apply patches on this Linux patching group, follow these steps:

  1. In Cloud Control, from the Enterprise menu, select Provisioning and Patching, then select Linux Patching.

  2. On the Linux Patching page, in the Compliance Report section, select the Linux patching group that you want to patch, then click Schedule Patching.

  3. On the Package Repository page, in the LINUX Distribution section, select the tool that you want to use to update the RPMs. YellowDog Updater modified (yum), and up2date are two commonly used tools to patch Linux hosts.

    Note:

    If the Linux host to be patched is running on Oracle Linux 6 (OL6), then you must use the yum tool for patching. The up2date patching tool is not supported for this Linux version. If you do not use the yum tool in this scenario, the patching process fails on the Configure Host For Patching step with the following error:

    You are not selecting 'yum' as the tool to update the RPMs in this system. 'yum' is the only supported tool for updating RPMs in Oracle Linux 6 operating system

    (Only if you have selected yum as the patching tool) Ensure that you select the patching mode that you want to use. Select Package update and new package installation if you plan to update the existing packages, as well as install new packages. Select Package update only if you plan to only update the existing packages, and not install any new packages.

    In the Stage Location section, specify the location where you want the Linux patching configuration and log files to be created.

    In the Package Repository section, select the RPM repositories that you want to use.

    In the Check GPG Signatures section, select Check GPG signatures to ensure that yum or up2date performs a GPG signature check on the packages obtained from the specified repositories. Sometimes, yum or up2date may require a public GPG key to verify the packages obtained from the repositories. This key may not be previously imported into the RPM database. To ensure that this key is imported, select Import GPG key, then specify the GPG Key URL.

    In the Advanced Options section, by default, the Hide obsolete updates option is selected. Selecting this option hides the obsolete packages on the Select Updates page. If you want to view these packages on the Select Updates page, ensure that you deselect this option.

    (Only if you have selected yum as the patching tool) In the Advanced Options section, select one of the following patch application modes:

    • Most suitable architecture, if you want yum to install the latest version of the selected package, or update the existing version of the package to the latest version, for the suitable RPM architectures that are installed on the Linux hosts that you are patching.

      If you select this option, Cloud Control runs the following yum command:

      yum install|update packagename

    • Specific architecture, if you want yum to install the latest version of the selected package, or update the existing version of the package to the latest version, on only those Linux hosts that have the RPM architecture of the selected package.

      If you select this option, Cloud Control runs the following yum command:

      yum install|update packagename.arch

    • Specific version and architecture, if you want yum to install only the specific version of the package selected on the Select Updates page, or update the existing version of the package to this specific version, on only those Linux hosts that have the RPM architecture of the selected package.

      If you select this option, Cloud Control runs the following yum command:

      yum install|update epoch:packagename-ver-rel.arch

    Click Next.

  4. On the Select Updates page, select the packages to be updated.

    Note:

    If the Hide obsolete updates option was selected in the previous step, the values for Total packages available and Total packages available in this view may be different. This difference corresponds to the number of obsolete packages present in the repositories.

    Click Next.

  5. On the Select Hosts page, select the Linux hosts to be updated. You can also select a group by changing the target type to group.

    By default, every discovered Linux host is displayed on this page, and can be selected. However, if you want only those hosts that have an older version of at least one of the packages (that you selected for the update operation in the previous step) to be displayed on this page, run the following command:

    $<OMS_HOME>/bin/emctl set property -name 'oracle.sysman.core.ospatch.filter_uptodate_hosts' -value 'true'

    Click Next.

  6. On the Credentials page, enter the credentials to be used for the updates.

    Click Next.

  7. On the Pre/Post script page, enter the scripts that need to be executed before/after the patching process, if any.

    Click Next.

  8. On the Schedule page, enter the details of the patching schedule that must be used.

    Click Next.

  9. On the Review page, review the update parameters.

    Click Finish. A deployment procedure is submitted to update the selected packages. Follow all the steps of the procedure until it completes successfully.

41.5.2 Applying Ad Hoc or Emergency Patches on Linux Hosts

To quickly apply patches on your Linux hosts in an ad hoc manner, or in case of an emergency, without using a Linux patching group, follow these steps:

  1. In Cloud Control, from the Enterprise menu, select Provisioning and Patching, then select Procedure Library.

  2. On the Deployment Procedure Manager page, in the Procedure Library tab, select Patch Linux Hosts, then click Launch.

  3. On the Package Repository page, in the LINUX Distribution section, select the tool that you want to use to update the RPMs. YellowDog Updater modified (yum), and up2date are two commonly used tools to patch Linux hosts.

    Note:

    If the Linux host to be patched is running on Oracle Linux 6 (OL6), then you must use the yum tool for patching. The up2date patching tool is not supported for this Linux version. If you do not use the yum tool in this scenario, the patching process fails on the Configure Host For Patching step with the following error:

    You are not selecting 'yum' as the tool to update the RPMs in this system. 'yum' is the only supported tool for updating RPMs in Oracle Linux 6 operating system

    (Only if you have selected yum as the patching tool) For the tool operation mode, ensure that you select Package update and new package installation. Since this method of patching Linux hosts without using a Linux patching group is meant for emergencies and is not based on a compliance report, you can only use it to install new packages, and not update existing packages.

    In the Stage Location section, specify the location where you want the Linux patching configuration and log files to be created.

    In the Package Repository section, select the RPM repositories that you want to use.

    In the Check GPG Signatures section, select Check GPG signatures to ensure that yum or up2date performs a GPG signature check on the packages obtained from the specified repositories. Sometimes, yum or up2date may require a public GPG key to verify the packages obtained from the repositories. This key may not be previously imported into the RPM database. To ensure that this key is imported, select Import GPG key, then specify the GPG Key URL.

    In the Advanced Options section, by default, the Hide obsolete updates option is selected. Selecting this option hides the obsolete packages on the Select Updates page. If you want to view these packages on the Select Updates page, ensure that you deselect this option.

    (Only if you have selected yum as the patching tool) In the Advanced Options section, select one of the following patch application modes:

    • Most suitable architecture, if you want yum to install the latest version of the selected package, or update the existing version of the package to the latest version, for the suitable RPM architectures that are installed on the Linux hosts that you are patching.

      If you select this option, Cloud Control runs the following yum command:

      yum install|update packagename

    • Specific architecture, if you want yum to install the latest version of the selected package, or update the existing version of the package to the latest version, on only those Linux hosts that have the RPM architecture of the selected package.

      If you select this option, Cloud Control runs the following yum command:

      yum install|update packagename.arch

    • Specific version and architecture, if you want yum to install only the specific version of the package selected on the Select Updates page, or update the existing version of the package to this specific version, on only those Linux hosts that have the RPM architecture of the selected package.

      If you select this option, Cloud Control runs the following yum command:

      yum install|update epoch:packagename-ver-rel.arch

    Click Next.

  4. On the Select Updates page, select the packages to be updated.

    Note:

    If the Hide obsolete updates option was selected in the previous step, the values for Total packages available and Total packages available in this view may be different. This difference corresponds to the number of obsolete packages present in the repositories.

    Click Next.

  5. On the Select Hosts page, select the Linux hosts to be updated. You can also select a group by changing the target type to group.

    By default, every discovered Linux host is displayed on this page, and can be selected. However, if you want only those hosts that have an older version of at least one of the packages (that you selected for the update operation in the previous step) to be displayed on this page, run the following command:

    $<OMS_HOME>/bin/emctl set property -name 'oracle.sysman.core.ospatch.filter_uptodate_hosts' -value 'true'

    Click Next.

  6. On the Credentials page, enter the credentials to be used for the updates.

    Click Next.

  7. On the Pre/Post script page, enter the scripts that need to be executed before/after the patching process, if any.

    Click Next.

  8. On the Schedule page, enter the details of the patching schedule that must be used.

    Click Next.

  9. On the Review page, review the update parameters.

    Click Finish. A deployment procedure is submitted to update the selected packages. Follow all the steps of the procedure until it completes successfully.

41.6 Managing Linux Configuration Files

This section describes how you can manage your Linux configuration files. It consists of the following:

41.6.1 Overview of Linux Configuration Files

The configuration file feature enables you to manage your Linux configuration files in an efficient and convenient manner. Using this feature (which is accessible from the Linux Patching home page), you can create a Linux configuration file channel, upload the required Linux configuration files present on your local host (or on a remote host that has a Management Agent deployed on it) to the created channel, then deploy the configuration files present in the channel to a large number of target hosts in a single operation.

This feature saves you the effort of manually copying the required Linux configuration files to each target host. For example, if a HTTP server configuration file that you want to copy to a large number of target hosts is present on your local host, you can use the Linux Patching home page to create a Linux configuration file channel, upload the HTTP server configuration file to this channel, then deploy the file from this channel to the target hosts.

41.6.2 Prerequisites for Managing Configuration Files

Ensure that the Software Library is already configured on the OMS.

41.6.3 Creating a Linux Configuration File Channel

To create a configuration file channel, follow these steps:

  1. In Cloud Control, from the Enterprise menu, select Provisioning and Patching, then select Linux Patching.

  2. On the Linux Patching page, click the Configuration Files tab.

  3. In the Configuration Files tab, click Create Config File Channel.

  4. On the Create Configuration File Channel page, enter a unique channel name and description for the channel, and click OK.

    You will see a confirmation message mentioning that a new configuration file channel is created.

41.6.4 Uploading Linux Configuration Files to a Particular Channel

This section describes how you can upload configuration files to a particular channel. In particular, this section covers the following:

41.6.4.1 Prerequisites for Uploading Linux Configuration Files

Before uploading configuration files to a particular channel, ensure that there exists at least one configuration file on the local host or on a remote host.

41.6.4.2 Uploading Linux Configuration Files

To upload configuration files, follow these steps:

  1. In Cloud Control, from the Enterprise menu, select Provisioning and Patching, then select Linux Patching.

  2. On the Linux Patching page, click the Configuration Files tab.

  3. In the Configuration Files tab, select the channel that you want to upload configuration files to, then click Upload Configuration Files.

  4. Select an appropriate upload mode. You can either upload files from local host (where the browser is running) or from a remote host (a Management Agent should be installed on that host and the Management Agent must be communicating with the OMS).

  5. In the File Upload section, enter the file name, path where the file will be deployed on the target host, and browse for the file on the upload host.

  6. For uploading from remote machine, click Upload from Agent Machine. Click Select Target and select the remote machine.

    Before browsing for the files on this machine, set preferred credential for this machine.

  7. After selecting the files, click OK.

    You will see a confirmation message that states that files have been uploaded.

41.6.5 Importing Linux Configuration Files from One Channel to Another

This section describes how you can import configuration files from one channel to another. In particular, this section covers the following:

41.6.5.1 Prerequisites for Importing Linux Configuration Files

Before importing configuration files, ensure that there are at least two channels.

41.6.5.2 Importing Linux Configuration Files

To import configuration files from the source channel to the target channel, follow these steps:

  1. In Cloud Control, from the Enterprise menu, select Provisioning and Patching, then select Linux Patching.

  2. On the Linux Patching page, click the Configuration Files tab.

  3. In the Configuration Files tab, select the source channel, and click Import Files.

  4. Select the target channel.

  5. From Source channel section, select the files and copy it to the target channel section. Click OK.

    You will see a confirmation message stating that the selected files have been imported successfully.

41.6.6 Deploying Linux Configuration Files From a Particular Channel

This section describes how you can deploy configuration files from a particular channel. In particular, this section covers the following:

41.6.6.1 Prerequisites for Deploying Linux Configuration Files

Before deploying configuration files, meet the following prerequisites:

  • Ensure that the privileged patching user has write permission on the target machine location where each configuration file will be staged, and has SUDO privileges too.

  • Ensure that there is at least one channel with some files uploaded.

41.6.6.2 Deploying Linux Configuration Files

To deploy configuration files from a particular channel, follow these steps:

  1. In Cloud Control, from the Enterprise menu, select Provisioning and Patching, then select Linux Patching.

  2. On the Linux Patching page, click the Configuration Files tab.

  3. In the Configuration Files tab, select the source channel, and click Deploy Files.

  4. In the wizard that appears, select the files you want to deploy, and click Next.

  5. Click Add to select the targets where you want to deploy the files.

  6. Enter the credentials for the selected targets.

  7. Enter the Pre/Post scripts you want to run before or after deploying the files.

  8. Review the deploy parameters and click Finish.

    A deploy job is submitted. Follow the job's link until it completes successfully.

41.6.7 Deleting a Linux Configuration File Channel

This section describes how you can delete configuration file channels. In particular, this section covers the following:

41.6.7.1 Prerequisites for Deleting a Linux Configuration File Channel

Before deleting a configuration file channel, ensure that there is at least one configuration file.

41.6.7.2 Deleting Linux Configuration File Channels

To delete a configuration file channel, follow these steps:

  1. In Cloud Control, from the Enterprise menu, select Provisioning and Patching, then select Linux Patching.

  2. On the Linux Patching page, click the Configuration Files tab.

  3. In the Configuration Files tab, select the channel, and click Delete. Click Yes.

    You will see a configuration message stating that the channel was successfully deleted.

41.6.8 Oracle Grid Infrastructure and Oracle RAC Configuration Support

This section describes the configurations that OPlan supports for patching GI and RAC databases of versions 11.2.0.2 or higher, on Linux X64, Solaris X64, Solaris SPARC and AIX platforms. Enterprise Manager integrates with OPlan to generate the procedure dynamically. If you use OPlan, then the commands that run as root will use the script available in the target Oracle home. The commands required to run as root depend on the version and the mode of patching. The following table lists the details:

Table 41-2 Oracle Grid Infrastructure and Oracle RAC Configuration Support

Version Mode Command

11.2

In-Place

<CRS_HOME>/crs/install/rootcrs.pl -unlock

<CRS_HOME>/rdbms/install/rootadd_rdbms.sh

<CRS_HOME>/crs/install/rootcrs.pl -patch

 

Out Of Place

mkdir -p <PARENT_FOLDER_OF_CLONE_CRS_HOME>;

cp -pR <CRS_HOME> <CLONE_CRS_HOME> /usr/bin/perl

<CLONE_CRS_HOME>/crs/install/rootcrs.pl -unlock -destcrshome=<CLONE_CRS_HOME>

<CLONE_CRS_HOME>/root.sh

mkdir -p <PARENT_FOLDER_OF_CLONE_DB_HOME>;

cp -pR <DB_HOME> <CLONE_DB_HOME> /usr/bin/perl

<CLONE_DB_HOME>/root.sh

/usr/bin/perl <CLONE_CRS_HOME>/crs/install/rootcrs.pl -patch -destcrshome=<CLONE_CRS_HOME>

/usr/bin/perl <CRS_HOME>/crs/install/rootcrs.pl -patch -destcrshome=<CRS_HOME>

12.1

In-Place

<CRS_HOME>/bin/crsctl stop crs

/usr/bin/perl <CRS_HOME>/crs/install/rootcrs.pl -prepatch (-nonrolling)

<CRS_HOME>/rdbms/install/rootadd_rdbms.sh

/usr/bin/perl <CRS_HOME>/crs/install/rootcrs.pl -postpatch (-nonrolling)

 

Out of Place

mkdir -p <PARENT_FOLDER_OF_CLONE_CRS_HOME>; cp -pR <CRS_HOME> <CLONE_CRS_HOME>

/usr/bin/perl <CLONE_CRS_HOME>/crs/install/rootcrs.pl -prepatch -dstcrshome=<CLONE_CRS_HOME>

<CLONE_CRS_HOME>/root.sh

mkdir -p <PARENT_FOLDER_OF_CLONE_DB_HOME>; cp -pR <DB_HOME> <CLONE_DB_HOME>

<CLONE_DB_HOME>/root.sh

/usr/bin/perl <CLONE_CRS_HOME>/crs/install/rootcrs.pl -postpatch -dstcrshome=<CLONE_CRS_HOME>

/usr/bin/perl <CRS_HOME>/crs/install/rootcrs.pl -prepatch -dstcrshome=<CRS_HOME>

/usr/bin/perl <CRS_HOME>/crs/install/rootcrs.pl -postpatch -dstcrshome=<CRS_HOME>

/usr/bin/perl <CRS_HOME>/crs/install/rootcrs.pl -prepatch -rollback -dstcrshome=<CRS_HOME>

/usr/bin/perl <CRS_HOME>/crs/install/rootcrs.pl -postpatch -rollback -dstcrshome=<CRS_HOME>


41.7 Additional Linux Patching Tasks You Can Perform

This section describes the additional tasks you can perform using the Linux Patching Home page:

41.7.1 Viewing Linux Patching Compliance History

This section describes how you can view the compliance history for a selected group, for a specific time period. In particular, this section covers the following:

41.7.1.1 Prerequisites for Viewing Linux Patching Compliance History

  • Ensure that you have defined at least one Linux patching group.

  • Ensure that you have View privileges on the Linux host comprising the patching group.

41.7.1.2 Viewing Linux Patching Compliance History

To view the compliance history of a Linux patching group, follow these steps:

  1. In Cloud Control, from the Enterprise menu, select Provisioning and Patching, then select Linux Patching.

  2. On the Compliance Home page, from the Related Links section, click Compliance History.

  3. On the Compliance History page, the Groups table lists all the accessible Linux patching groups and the number of hosts corresponding to each group.

  4. If there are multiple Linux patching groups, the Compliance History page displays the historical data (for a specific time period) for the first group that is listed in that table.

  5. To view the compliance history of a Linux patching group, click the View icon corresponding to that group.

Note:

By default, the compliance data that is displayed is retrieved from the last seven days. To view compliance history of a longer time period, select an appropriate value from the View Data drop-down list. The page refreshes to show compliance data for the selected time period.

41.7.2 Patching Non-Compliant Linux Packages

This section describes how you can patch non-compliant packages from the Linux Patching home page. In particular, this section covers the following:

41.7.2.1 Prerequisites for Patching Non-Compliant Linux Packages

Before patching non-compliant packages, ensure that a Linux Patching group is created and the Compliance Collection job has succeeded.

41.7.2.2 Patching Non-Compliant Linux Packages

To patch non-compliant packages, follow these steps:

  1. In the Patch Linux Hosts Wizard, provide the required details in the interview screens, and click Finish on the Review page.

  2. A deployment procedure is submitted to update the host. Check if all the steps finished successfully.

41.7.3 Rolling Back Linux Patch Update Sessions or Deinstalling Packages

This section describes how you can rollback a patch update session, or even uninstall the unstable version completely in case that patch version is found unsuitable for has a bug or security vulnerability. In particular, this section covers the following:

Note:

  • Rolling back upgrades is supported to a certain extent. When performing an upgrade such as from OEL 5.2 to OEL 5.3, many RPMs that are dependent on others are upgraded. When you apply RPMs, this dependency can be followed. However, when rolling back patch update sessions, this dependency must be followed in reverse order. This reverse operation is not supported by yum or up2date. Hence, you can use the rollback feature to rollback a patch update session, but not to completely rollback a major upgrade such as from OEL 5.2 to OEL 5.3.

  • Rolling back upgrades is not supported on hosts running on Oracle Linux 6.

41.7.3.1 Prerequisites for Rolling Back Linux Patch Update Sessions or Deinstalling Packages

Before rolling back patch update sessions or deinstalling packages, meet the following prerequisites:

  • Ensure that a Linux Patching group is created.

  • Ensure that the lower version of the packages are present in the RPM repository.

41.7.3.2 Rolling Back Linux Patch Update Sessions or Deinstalling Packages

To roll back a patch update session or uninstall packages, follow these steps:

  1. In Cloud Control, from the Enterprise menu, select Provisioning and Patching, then select Linux Patching.

  2. On the Linux Patching page, in the Compliance Report section, select a group, and click Undo Patching.

  3. On the Undo Patching: Action page, select an appropriate option:

    • Uninstall Packages, deinstalls a package.

    • Rollback Last Update Session, reverts the effects of the previous patch update session.

  4. Click Next.

  5. Provide the required details in the wizard, and on the Review page, click Finish.

  6. A job is submitted to rollback the updates done in the previous session.

  7. Examine the job submitted to see if all the steps are successful.

41.7.4 Registering a Custom Package Channel

This section describes how you can register a custom channel. In particular, this section covers the following:

41.7.4.1 Prerequisites for Registering a Custom Package Channel

Before registering a custom channel, meet the following prerequisites:

  • Ensure that the RPM Repository is under /var/www/html and is accessible through HTTP protocol.

  • Ensure that Apache is installed, and listening on port 80. To verify this, you can try connecting to the URL: http://host.

    For example: http://h1.example.com. If this works, then it is confirmed that Apache is installed and listening on port 80.

  • Ensure that metadata files are created by running yum-arch and createrepo commands.

  • Ensure that a Management Agent is installed on the RPM repository host, and ensure that Management Agent is communicating with the OMS.

  • Ensure that the Enterprise Manager User logs in with Super User privileges for registering a custom channel.

41.7.4.2 Registering a Custom Package Channel

To register a custom RPM Repository, follow these steps:

  1. In Cloud Control, from the Setup menu, select Provisioning and Patching, then select Linux Patching.

  2. On the Patching Setup page, in the Linux Patching Setup tab, click Manage RPM Repository.

  3. On the Manage Repository Home page, click Register Custom Channel.

  4. On the Register Custom Channel page, enter a unique channel name.

  5. Click Browse and select the host where the custom RPM repository was setup.

  6. Enter the path where RPM repository resides. The directory location must start with /var/www/html/.

  7. Click OK.

    A Package Information job is submitted. Follow the job until it completes successfully.

41.7.5 Cloning a Package Channel

This section describes how you can clone a channel. In particular, this section covers the following:

41.7.5.1 Prerequisites for Cloning a Package Channel

Before cloning a channel, meet the following prerequisites:

  1. Ensure that there is at least one channel already present.

  2. Ensure that there is enough space on the target channel host.

  3. Ensure that the stage location of the source host does not have a directory named createLikeSrc, and the Directory for the Target Channel does not exist.

  4. Ensure that Apache is installed, and listening on port 80. To verify this, you can try connecting to the URL: http://host.

    For example: http://h1.example.com. If this works, then it is confirmed that Apache is installed and listening on port 80.

  5. Ensure that the Enterprise Manager User logs in to the OMS with Super User privileges.

41.7.5.2 Cloning a Package Channel

To clone a channel, follow these steps:

  1. In Cloud Control, from the Setup menu, select Provisioning and Patching, then select Linux Patching.

  2. On the Patching Setup page, in the Linux Patching Setup tab, click Manage RPM Repository.

  3. On the Manage RPM Repository page, select the source channel you want to clone, and click Create Like.

  4. Enter the credentials to use for the source channel. The credentials must have both read and write access.

  5. Enter a unique target channel name.

  6. Click Browse to select the target host name.

  7. Enter the directory location of the target channel. This directory should be under /var/www/html.

  8. Enter the credentials to use for the target channel. This credential should have both read and write access.

  9. Click OK.

    A Create-Like job is submitted. Follow the job until it completes successfully.

41.7.6 Copying Packages from One Channel to Another

This section describes how you can copy packages from one channel to another. In particular, this section covers the following:

41.7.6.1 Prerequisites for Copying Packages from One Channel to Another

Before copying the packages from one channel to another, meet the following prerequisites:

  1. Ensure that there are at least 2 channels.

  2. Ensure that the target channel machine has adequate space.

  3. Ensure that the stage location of the source host does not have a directory named copyPkgsSrc,and the stage location of Target Host does not have a directory named copyPkgsDest.

  4. Ensure that Apache is installed, and listening on port 80. To verify this, you can try connecting to the URL: http://host.

    For example: http://h1.example.com. If this works, then it is confirmed that Apache is installed and listening on port 80.

  5. Ensure that the Enterprise Manager User logs in to the OMS with Super User privileges.

41.7.6.2 Copying Packages from One Channel to Another

To copy the packages from one channel to another, follow these steps:

  1. In Cloud Control, from the Setup menu, select Provisioning and Patching, then select Linux Patching.

  2. On the Patching Setup page, in the Linux Patching Setup tab, click Manage RPM Repository.

  3. On the Manage RPM Repository page, select the source channel, and click Copy Packages.

  4. Select the target channel.

  5. From the source channel section, select and copy the packages to the target channel section.

  6. Enter credentials for the source and target channels. These credentials should have read/write access to the machines.

  7. Click OK.

    A Copy Packages job is submitted. Follow the job until it completes successfully.

41.7.7 Adding Custom Packages to a Channel

This section describes how you can add custom packages to a channel. In particular, this section covers the following:

41.7.7.1 Prerequisites for Adding Custom Packages to a Channel

Before you add custom packages to a channel, meet the following prerequisites:

  1. Ensure that there is at least one channel.

  2. Ensure that the stage location of the source host does not have a directory named addPkgsSrc, and the stage location of the destination channel does not have a directory named addPkgsDest.

41.7.7.2 Adding Custom Packages to a Channel

To add custom RPMs to a channel, follow these steps:

  1. In Cloud Control, from the Setup menu, select Provisioning and Patching, then select Linux Patching.

  2. On the Patching Setup page, in the Linux Patching Setup tab, click Manage RPM Repository.

  3. On the Manage RPM Repository page, select the channel name where you want to add the RPM, and click Add.

  4. Select the source target name and the credentials to be used for the host. The credential you use must have write access on emd_emstagedir directory present on the source host.

  5. On the Upload Files section, click the search icon to browse for the RPM files.

  6. Select a normal host credential that has write access on the select channel.

  7. Select a privileged host credential that has write access on the select channel, and has SUDO as root privilege.

  8. Click OK.

    An Add Package job is submitted. Follow the job until it completes successfully.

41.7.8 Deleting a Package Channel

This section describes how you can delete a channel. In particular, this section covers the following:

41.7.8.1 Prerequisites for Deleting a Package Channel

Before deleting a channel, meet the following prerequisites:

  1. Ensure that there is at least one channel.

  2. Ensure that the Enterprise Manager User logs in to the OMS with Super User privileges.

41.7.8.2 Deleting a Package Channel

To delete a channel, follow these steps:

  1. In Cloud Control, from the Setup menu, select Provisioning and Patching, then select Linux Patching.

  2. On the Patching Setup page, in the Linux Patching Setup tab, click Manage RPM Repository.

  3. On the Manage RPM Repository page, select the channel name you want to delete, and click Delete.

  4. If you want to delete the packages from the RPM Repository machine, select the check box and enter the credentials for the RPM Repository machine. Click Yes.

  5. If you have not selected to delete the packages from RPM Repository machine, you will get a confirmation message stating Package Channel <channel name> successfully deleted. If you have selected the Delete Packages option, a job will be submitted to delete the packages from the RPM Repository machine. Follow the job until it completes successfully.