2 Things to Know

Provisioning

Provisioning is the first phase of the software lifecycle that deals with installation and configuration of software, applications, or servers across different platforms, environments, and locations. Enterprise Manager Grid Control offers provisioning Deployment Procedures that help you seamlessly deploy software across your enterprise configuration.

Patching

Patching is one of the phases of the software lifecycle that helps you maintain the software over a period of time and always keep it updated with the latest features offered by the software vendor. It is a process that deals with migrating from one version of the software product to another, higher, much-improved version. Enterprise Manager Grid Control offers patching Deployment Procedures that help you seamlessly patch Oracle software across your enterprise configuration.

Oracle releases patches periodically to help you migrate to a newer version of the software product and reap the benefits of an improved version. These patches contain critical enhancements and bug fixes that make the product better and offer more value to your organization.

For example, for the Oracle Database 10g Release 1 (10.2.0.1) base release, Oracle has released patches that help you migrate to either Oracle Database 10g Release 2 (10.2.0.2), Oracle Database 10g Release 3 (10.2.0.3), or Oracle Database 10g Release 4 (10.2.0.4); the last one being the most recent patch.

Patching Versus Upgrading

As described in the previous section, Patching refers to the process of migrating from one version to another, newer version of the software product within a particular release. For example, if Oracle Database 10g is the release, then Patching refers to migrating from Oracle Database 10g Release 1 (10.2.0.1) to Oracle Database 10g Release 2 (10.2.0.2). Here, Release 2 (10.2.0.1), Release 2 (10.2.0.2), and so on are different versions of the 10g release.

Upgrading refers to the process of upgrading from one release to another, newer release of the software product. For example, if Oracle Database 10g is one release and Oracle Database 11g is another release, then Upgrading refers to upgrading Oracle Database 10g to Oracle Database 11g. Here, 10g, 11g, and so on are different releases of the Oracle Database product.

Patches

Patches are periodic software updates released by Oracle. They contain bugs fixes only, and they must be applied on the software product to maintain a bug-free and improved version of the software. Patches can be one-off patches, interim patches, or critical patch updates (CPU). Some of these may even be requirement-specific and released only to a few customers. Patches can be stored as generic components in Oracle Software Library. For information about Oracle Software Library, see Oracle Software Library.

Patch Sets

Patch Sets are new releases of the software product released by Oracle. They contain a collection of patches, important enhancements, and bug fixes. They are much larger in size, and are released for all customers. They must be applied on the base or existing release of the software product to maintain an up-to-date version of the software. Patch Sets can be stored as generic components in Oracle Software Library. For information about Oracle Software Library, see Oracle Software Library.

Deployment Procedures

A Deployment Procedure is a procedure that contains a hierarchal sequence of provisioning or patching steps, where each step may contain a sequence of other steps. In other words, the workflow of all tasks that need to be performed for a particular lifecycle management activity is encapsulated in a Deployment Procedure. For example, imagine a Deployment Procedure to be the "Coffee" button on the coffee vending machine. So, every time you need a cup of coffee, you press the "Coffee" button and it automatically adds the required ingredients and serves coffee through its nozzle.

You select a Deployment Procedure in the Enterprise Manager Grid Control console to perform a particular provisioning or patching task. The Deployment Procedure contains a set of predefined steps that run one by one automatically to complete the entire task.

Enterprise Manager Grid Control comes with a set of default Deployment Procedures that help you accomplish common provisioning and patching-related tasks. Each Deployment Procedure is unique, and is designed to perform a particular operation according to the source being provisioned or target being patched. For example, the Deployment Procedure to patch a single instance database differs from the one to patch an Oracle RAC environment or an application server.

Understandably, your provisioning and patching-related requirements may vary from one environment to another, or from a test installation to a production installation. You can use the default Deployment Procedures and customize them according to your needs.

Understanding Phases and Steps

Deployment Procedures comprise various phases and steps that run serially or in parallel to perform a particular provisioning or patching operation.

A phase contains steps or more phases. The different types of phases are:

• Rolling Phase

  Rolling phase is a phase where steps are run serially across targets.

  
  

• Parallel Phase

  Parallel phase is a phase where steps are run in parallel across targets.

  
  

A step is an abstraction of a unit of work. For example, starting the database is a step. It is either part of a phase or independent. The different types of steps are:

• Manual Step

  Manual step is a task that requires user interaction and cannot be automated. Typically, Enterprise Manager Grid Control displays the instructions that need to be performed by you. After you perform those operations, you proceed to the next step. For example, logging in to a system and updating the kernel parameter, rebooting a system, providing special privileges to the user, and so on.

  
  

• Computational Step

  Computational step is a task whose operations are performed within Enterprise Manager Grid Control and they do not require any user intervention. This step gathers additional information for running a procedure. This step cannot be manually inserted by you. For example, running an SQL query against a schema to gather more data for other steps to run, retrieving target properties from the repository and updating the runtime information, and so on.

  
  

• Action Step

  Action step is a task that performs some operations run on one or more targets. They must be enclosed within a phase. The Deployment Procedure maps the Action Step and target pair to a job in the Enterprise Manager Job System. The Deployment Procedure can schedule, submit, and run a job per Action Step per target. For example, running a script, applying a patch, upgrading an Oracle home, and so on.

  Also note that an Action Step is said to have completed successfully only when all its associated jobs have completed successfully. If a job fails, then the Action Step also fails. You may then manually restart the job in question or ignore and instruct the Deployment Procedure to proceed.

  The different types of Action Steps include:

  • Job

    Job Step is a special type of Action Step that executes a predefined job type on a target. This is used if you want to execute a job type as a part of a Deployment Procedure. You need to pass job parameters for a step.

    
    

  • Directive

    Directive step is a special type of Action Step to deploy a directive alone. This is useful when users want to store their custom scripts in Oracle Software Library (Software Library) and reuse them in a Deployment Procedure.

    
    

  • Component (Generic or Registered)

    Generic component step is a special type of Action Step to deploy a Software Library component and the associated Directive. Deployment Procedure Manager executes the directive with respect to the component. Components used for Generic Component Step generally have one directive associated with them. This association is done by selecting both the component and directive while creating the step. All directives that you associate with the component while uploading to the Software Library are ignored while running the step.

    
    

  • Host Command

    Host Command Step is a special type of Action Step that encapsulates simple host commands. This step allows the user to enter a command line or a script (multiple commands) to be executed on the target host.

    
    

Activities Involved in Deployment Procedures

The activities involved in Deployment Procedures are design-time activities and run-time activities.

• Design-time activities include creating components, directives, and images, and storing them in Oracle Software Library; and sometimes even customizing the default Deployment Procedures according to the needs of the organization.

• Run-time activities include using these Deployment Procedures to actually provision or patch software, applications, or servers.

Users of Deployment Procedures

In a typical data center, the main users of Deployment Procedures are Designers (Lead Administrators) and Operators.

	Designers (Lead Administrators) are users who perform design-time activities described in Activities Involved in Deployment Procedures. Essentially, they are responsible for setting up the infrastructure for running Deployment Procedures.
	Operators are users who perform run-time activities described in Activities Involved in Deployment Procedures. Essentially, they are responsible for running the Deployment Procedures to provision or patch a target.

Viewing Details of Deployment Procedures

To view the default configuration settings of a Deployment Procedure and the steps involved in it, follow these steps:

1. In Grid Control, click Deployments.

2. On the Deployments page, in the Deployment Procedure Manager section, click Deployment Procedures.

3. On the Deployment Procedure Manager page, in the Procedures tab, from the table, select the Deployment Procedure for which you want to view details, and click View.

   Enterprise Manager Grid Control displays the View Procedure page that shows the default configuration settings and steps involved in the selected Deployment Procedure.

Patching Deployment Procedures

The following are the patching Deployment Procedures offered by Enterprise Manager Grid Control.

Understanding Patching Modes

Using Deployment Procedures, you can apply a patch or patch set in either online mode or offline mode.

Online Patching Mode helps you if the host that runs Enterprise Manager Grid Control has an Internet connection to connect to My Oracle Support. Using Enterprise Manager Grid Control, you can schedule a job that will run periodically and connect to My Oracle Support, check for the latest patches and patch sets, and automatically download them. This relieves you of the manual effort involved in searching the latest patches and patch sets, and downloading them whenever they are available.

Offline Patching Mode helps you if the host that runs Enterprise Manager Grid Control does not have an Internet connection to connect to My Oracle Support. In this case, you must manually download the patch and patch sets from My Oracle Support using another host that has an Internet connection. Using Enterprise Manager Grid Control, you can manually upload these patches and patch sets to the Patch Cache so that they can be applied later.

Understanding Patching Methodologies

For Oracle RAC Database and Oracle Clusterware, you can patch all instances of the cluster either in a rolling or parallel mode. The parallel manner is called All Nodes in Enterprise Manager Grid Control.

• Rolling mode refers to the patching methodology where the nodes of the cluster are patched individually, that is, one by one.

  For example, if you are patching a clusterware that has five nodes, then the first node is shut down, patched, and restarted, and then the process is rolled over to the next node until all the nodes are patched successfully.

  This methodology is best suited for the following use cases:

  • When you are applying one-off patches that support this methodology.

    Note:

    Although most one-off patches support this methodology, there are some one-off patches that can be applied only using the All Nodes methodology. You can identify the supported methodology while downloading the one-off patches from My Oracle Support.

  • When you want to maintain high availability of your targets, so when one node is being patched, the other nodes are available for service.

  Note:

  You cannot use this methodology to patch shared Oracle homes. If you want to patch a shared Oracle home, then use the All Nodes methodology.

• All Nodes (or parallel) mode refers to the patching methodology where all the nodes are patched at a time, collectively. In this methodology, all the nodes are shut down and the patch is applied on all of them at the same time.

  This methodology is best suited for the following use cases:

  • When you are applying patch sets, or one-off patches that support this methodology.

  • When you want to patch a shared Oracle home clusterware. In case of a shared Oracle home, all the nodes are shut down, but the patch is applied only on one of the nodes.

    For example, if you are patching a shared Oracle home clusterware that has five nodes, the patch and the scripts within it are run only once on the shared Oracle home, and the other nodes are ignored or skipped. This saves time as the patching operation is performed only once, that is, only on the shared Oracle home, and not on all the nodes.

  Note:

  Patching of shared Oracle homes is supported only for Oracle Clusterware 10g Release 2 (10.2.0.1) or higher.

Oracle Software Library

Oracle Software Library (Software Library) is a repository that stores certified software images (for example, Oracle Database, operating system, Oracle Real Application Clusters, third party software, and so on) and other related entities. These can then be automatically mass-deployed to provision software, software updates, and servers using Enterprise Manger Grid Control in a reliable and repeatable manner. These provisioning operations, which are unattended and can be scheduled, lead to substantial cost savings. For example, imagine Software Library to be the container inside the coffee vending machine that has smaller compartments for storing milk, coffee powder, and sugar. So, before you press the "Coffee" button, you would ideally stock milk, coffee powder, and sugar in those smaller compartments of the container inside the vending machine.

The Software Library is part of and within Enterprise Manager Grid Control. It is not a separate, add-on product that needs to be installed separately. You can use the Enterprise Manager Grid Control console to access the Software Library and create components, images, directives, and store metadata and binary content.

For information about components, images, and directives, see Components, Directives, and Images, Network Templates, Hardware Templates, Disk Layouts, respectively.

For information about setting up the Software Library, see Setting Up Oracle Software Library. For information about using other options offered by the Software Library, see Appendix C, "Using Oracle Software Library".

Components

Components are entities in the Software Library that represent the primary building blocks for Deployment Procedures. A component can represent operating system software, Oracle software, or any third-party software and applications. For example, imagine a Component to be an ingredient, such as milk, coffee powder, or sugar stored in the container inside a coffee vending machine. Without these, the vending machine cannot prepare a cup of coffee.

Components are individually maintained within the Software Library, and you can associate versions, states, and maturity levels with each component. They may also be combined with other components as needed, to specify the complete software configuration or image that is provisioned on target hosts.

Directives

Directives are entities in the Software Library that represent a set of instructions to be performed. These are constructs used to associate scripts with software components and images. These scripts contain directions on how to interpret and process the contents of a particular component or an image. For example, imagine a Directive to be the program that runs inside the coffee vending machine to automate the process of preparing coffee. The program essentially instructs the vending machine to add the ingredients one by one, and then serve the drink through its nozzle.

Directives encapsulate the script, the command line used to invoke the script, and the script configuration properties. They capture everything required for invoking the script on a machine during a provisioning operation.

Directives are usually categorized based on the provisioning life cycle phases they are targeted for, or the actions they perform. Imagine Directives as set of executable instructions that run from a supported shell (for example, borne-again, Perl, Python), programming language (for example, Java), or execution framework or interpreter (such as “make” or “ant”).

Directives are contained within a file stored in the Oracle Software Library and referenced from the software components that employ them. Versions, states and maturity levels can be associated with each directive.

Images, Network Templates, Hardware Templates, Disk Layouts

Images are entities that represent a collection of components along with the necessary directives that create a deployable configuration for a single or set of target hosts. Network Templates, Hardware Templates, and Disk Layouts are used to define the network, hardware, and disk layout configuration of the target hosts, respectively. For example, imagine an Image to be a cappuccino flavored drink readily available in a paper carton. In this case, you do not prepare the coffee; the drink already contains milk, cappuccino coffee powder, and sugar, and it's all mixed and readily available for consumption.

Images are stored in the Oracle Software Library and versions, states, and maturity levels can be associated with them.

Assignments

Assignment is the activity to select an image and provision them on hardware servers. Assignments allow specifying properties (such as image properties, file system, root password, network profiles, port, IP address, etc.) that will be used during the provisioning of hardware servers. Assignments also allow for setting of advanced parameters like NTP, NIS, NFS and kernel parameters.

Terms Used in Virtualization

The following describes the terms used in virtualization:

Oracle VM

Oracle VM is server virtualization software. Installing Oracle VM on a bare metal box allows for the creation of multiple guest virtual machines on it. Just like Oracle databases and Oracle Fusion Middleware, Oracle VM is available for download on Oracle Technology Network (OTN).

Virtual Server

Virtual Server is a generic term used to describe a physical box running virtualization software (hypervisor) on it. A new virtual server can be provisioned by installing Oracle VM server software on a bare metal physical box. "Virtual Server" is a target type in Enterprise Manager that represents the Oracle VM targets.

Every Oracle VM server can perform one or more of the functions described below:

• Master Server

  The Master Server is the core of the server pool operations. It acts as the contact point of the server pool to the outside world, and also as the dispatcher to other servers within the server pool. The load balancing is implemented by the Master Server. For example, when you start a guest virtual machine, the Master Server will choose a Guest VM Server with the maximum resources available to run the guest virtual machine. There can be only one Master Server in a server pool. The state of a virtual server pool is equivalent to the state of the master virtual server.

• Utility Server

  The Utility Server is responsible for I/O intensive operations such as copying or moving files. Its function focuses on the creation and removal operations of guest virtual machines, virtual servers, and server pools. There can be one or more Utility Servers in a server pool. When there are several Utility Servers, Server Pool Master chooses the Utility Server with the maximum CPU resources available to conduct the task.

• Guest VM Server

  The primary function of the Guest VM Server is to run guest virtual machines, thus acting as a hypervisor. There can be one or more Guest VM Servers in a server pool. When there are several Guest VM Servers, Master Server chooses the Guest VM Server with the maxhmum resources available (including memory and CPU) to start and run the virtual machine.

Monitoring Server

The monitoring server monitors the virtual server remotely. Multiple virtual servers are monitored by one agent. Enterprise Manager agent must not be installed on virtual servers. The Monitoring Server agent (Enterprise Manager agent that monitors Oracle VM servers) should be upgraded to version 10.2.0.5.0.

Virtual Server Pool

A Server Pool is a logical grouping of one or more virtual servers that share common storage. A virtual server can belong to only one virtual server pool at a time. Guest virtual machines and resources are also associated with server pools. Oracle VM Server Pool is an aggregate target type in Enterprise Manager to represent the server pool of Oracle VM Servers.

When the Oracle VM Server Pool is created, the user is asked to provide the details of the Master Server for that pool. By default, this Oracle VM Server also performs the functions of the Utility Server and Guest VM Server.

The user can later change the Utility Server and Guest VM Server functions using the Edit Virtual Server action.

Guest Virtual Machine

Guest Virtual Machine (also known as Guest VM) is the container running on top of a virtual server. Multiple guest virtual machines can run on a single virtual server. Guest virtual machines can be created from Oracle VM templates. Oracle VM templates provide pre-installed and pre-configured software images to deploy a fully configured software stack. Oracle VM templates can be downloaded from OTN at the following location:

http://www.oracle.com/technology/products/vm/templates.html

A guest virtual machine monitored by an Enterprise Manager agent is treated like any other Host target. This type of guest virtual machine is referred to as a "Managed Guest VM".

A guest virtual machine that is not monitored by any Enterprise Manager agent is referred to as an "Unmanaged Guest VM". Only limited monitoring and configuration information is available for such a guest virtual machine.

Privileges Required for Administrative and Provisioning Operations

Table 2-1 lists the privileges required to perform administrative and provisioning tasks on server pools, virtual servers, and guest virtual machines.

Overview of the Bare Metal Provisioning Environment

The deployment environment in the data center needs to be setup in a certain manner in order to support the provisioning application. Besides the Oracle Management Server (OMS) which hosts Enterprise Manager and Provisioning Application, the following need to be setup and configured before using the provisioning application.

Software Library and its Entities

For information about Software Library and its entities, see Oracle Software Library.

Boot Server

One of the key requirements of application is the ability of the hardware server to boot up over the network (rather than from a local boot device). A boot server must be set up so that it is able to service the requests from the designated hardware servers in order for them to boot over the network. Boot server must be an Enterprise Manager target and should be able to receive the BOOTP and TFTP (Trivial File Transfer Protocol) requests over the network from the hardware server. Refer to Setting Up Boot Server for setting up a boot server with DHCP/TFTP combination. Also refer to section Configuring Boot Server. It is also recommended that the users read about DHCP, PXE, and Redhat Kickstart technology before going through the boot server setup. Refer to Appendix G, "PXE Booting and Kickstart Technology" for a detailed discussion on PXE.

Stage Server

During provisioning of an image on hardware servers, the required binaries and files are first transferred to a stage server. This is known as Staging phase and is responsible for preparing images to be installed over the network, and exposing installable or executable software elements over the network to the target hardware server being provisioned.

The Provisioning application requires at least one stage server on which all the activities related to staging can be performed. From the networking perspective, you are advised to keep the stage server as close to the target machines as possible. It will help in bringing down the installation time drastically, by reducing the time taken to transfer image data from the stage server to the hardware servers. If you have multiple hardware server groups residing at physically different locations, it would be better to have one stage server for each of these locations. Stage server should again be an Enterprise Manager target. Refer to section Setting Up Stage Server for setting up a stage server. Also refer to section Configuring Stage Server.

Reference Host

A Reference Host (also called a gold machine) is the machine that the Provisioning application uses as a reference to create the Linux operating system component. The Provisioning application picks up the list of RPMs (along with their versions) installed on the reference host, and fetches those RPMs from a RPM repository to create an Linux OS component that represents the operating system installed on the reference host. The reference host must be an Enterprise Manager target.

RPM Repository

The Provisioning application picks up the RPMs for the operating system from the RPM repository. At least one repository needs to be setup for use by the Provisioning application. Refer to section Setting Up the RPM Repository for setting up a RPM repository. Also refer to section Configuring RPM Repository.

Overview of the Bare Metal Provisioning Process

The provisioning process consists of the following two high-level tasks:

Setting Up Provisioning Environment ( Setting Up Infrastructure for Bare Metal Provisioning):

• Setting up Boot/DHCP server and Stage server, setting up RPM repository and Software Library

• Configuring above entities in Enterprise Manager

Provisioning Linux using Bare Metal Provisioning Application ( Provisioning Bare Metal Boxes):

• Creating Linux "Default Image" by creating an image and associating the image with a particular network subnet or MAC address

• Staging the image on the Stage server

• Powering up the bare metal machine on the network to begin the PXE-based OS boot and install process

Provisioning Linux Using Bare Metal Provisioning Application

The following sections outline the steps to provision Linux. See Chapter 11, "Provisioning Linux Operating System" for more information.

Figure 2-1 User Flow for Creating Deployable Images for Hardware Servers

Creating Linux Default Image

Enterprise Manager allows the user to create a Linux "Default Image" from Linux installation on a reference machine. The default image consists of an OS binary component along with directives required to stage and provision the image. Once an image is created, it can be associated with a subnet prefix or a set of MAC addresses. Doing this ensures that the image gets provisioned on bare metal machines in the specified subnet or having specified MAC address. See Chapter 11, "Creating a Default Image" for more information.

Staging the Image on the Stage Server

The user is required to stage the contents of the image, namely the binaries associated with the components, directives and other templates, on the stage server. This caches the image in the staging area in the subnet for improved performance and prepares the image to be provisioned. See Chapter 11, "Staging the Default Image" for more information.

Powering up the Bare Metal Machine on the Network to Begin the PXE-based OS Boot and Install Process

Once the image is staged, it is ready to be provisioned on bare metal machines that are powered on in the subnet. When a bare metal machine is connected to the subnet, the Bare Metal Provisioning Application discovers the machine and boots it over the network using the PXE protocol. It then installs the operating system and the Enterprise Manager management agent on the server. Installing the agent makes the server a managed target in the Enterprise Manager console. See Chapter 11, "Ready to Go" for more information.

Figure 2-2 explains the sequence in the PXE process:

Figure 2-2 PXE Process

See Chapter G, "PXE Booting and Kickstart Technology" for a description of the PXE boot process.

Patches and Updates

From the Enterprise Manager Grid Control console, the Patches and Updates tab allows you to view and download recommended patches and updates for your Oracle products.

Patch Plans

A patch plan is a collection of patches which you might want to consider applying as a group. A patch plan could equate to a maintenance window (you can set a date for the plan), could contain patches for a single target, a collection of similarly configured targets (the same key patches applied to all of your databases, for example), or all of the patches for a system or group of systems, such as all patches for the current month for production databases.You can include a patch for any target in a plan. The plan also supports validation of the patches against your environment by looking for conflicts with existing (installed) patches, missing pre-requisites for patches you want to install (a candidate patch), as well as looking for conflicts between patches within the plan itself. Currently, the validation process works for products such as Oracle Database, Fusion Middleware and Enterprise Manager. More Oracle products will be added in future release.Patch plan is only available when using the configuration manager.

Patch Recommendations

Patch recommendations are proactive notifications of potential system issues and recommendations that help you improve system performance and avert outages. My Oracle Support's Patch Recommendations region provides a portal to all recommended patches. From the bar graph, you can drill down to a list of recommended patch, view details about those patches, download the patches, or add them to a patch plan. A bar graph summarizes the number of issues found (one issue = one recommendation for one target). The Recommended Patches region appears by default on the Patch and Updates page and can also be added to the Dashboard. You can edit this region to filter its contents.

Validation

When My Oracle Support validates a plan, it checks for conflicts using patch information from Oracle, the inventory of patches on your system (gathered by the configuration manager) and information from the candidate patches. In addition to checking patch merge conflicts between patches listed in the plan, the validation function also checks for conflicts between the listed plan patches and patches that have already been applied.

Not all Oracle products and platforms support validation, but those that do (such as the Oracle Database, Oracle Fusion Middleware , and Oracle Enterprise Manager) will help you later when you want to deploy the patches. The validation process will catch a variety of problems which are easier to resolve now then when you are trying to deploy the patches. It catches patches that conflict and require a replacement patch (also referred to as a Merged Patch, or MLR), missing pre-requisites, patches not intended for a specific release, and other conditions that would cause problems at installation time.

Merge Requests

When patching complex heterogeneous IT environments, enevitably conflicts may arise between specific patch versions. Conflicts occur when two or more patches attempt to update/change the same files. Because individual files cannot be applied as one-offs, they must be "merged" together in a single patch containing all changes/updates to the file(s) in question so that the file(s) are updated only once with all the fixes.

Merge Requests are also known as Merge Label Requests (MLRs).

Provisioning Archive (PAR) Files

Provisioning Archive files or PAR files contain Deployment Procedures and/or components and directives from the Software Library. These are default Deployment Procedures offered by Enterprise Manager Grid Control. When you import or export Deployment Procedures using the default PARDeploy utility, you technically import or export PAR files. For information on PARDeploy utility and how you can use it to import or export PAR files, see Appendix B, "Using emctl partool Utility".

Oracle Patch Advisories

Oracle Patch Advisories describe critical software patches for Oracle products. To help ensure a secure and reliable configuration, all relevant and current critical Oracle patches must be applied. To promote critical patch application, Enterprise Manager Grid Control performs an assessment of vulnerabilities by examining the host configurations collected for your enterprise to determine the Oracle homes that require one or more critical patches to be installed.

Staging Area

Staging Area is a temporary location on the target host where the generic component from the Software Library or the reference installation used for cloning will be staged for a short period, and then extracted and used for deployment. The generic component or the reference installation may be in the form of a ZIP file. After it is placed in the staging area, once the Deployment Procedure is ready for deployment, the contents of the ZIP file are extracted and then deployed. You must always ensure that the staging area has write permission so that the Deployment Procedure can stage the ZIP file.

Support for SUDO, PAM, and Privilege Delegation

All the Deployment Procedures offered by Enterprise Manager Grid Control require administrator privileges to run. While most steps within a Deployment Procedure can be run as a normal user, there are some steps that require special permissions and privileges, and unless you provide the administrator's credentials, you cannot proceed with the deployment.

Under such circumstances, you can do one of the following:

• Customize the Deployment Procedure to disable the steps that require special privileges, run the other steps as a normal user, and have the administrator run the disabled steps later.

• Customize the Deployment Procedure to use authentication utilities for running some steps within the Deployment Procedure with the privileges of another user. The authentication utilities supported by Enterprise Manager Grid Control are SUDO, PowerBroker, and Privilege Delegation.

For information on how you can customize Deployment Procedures and how Privilege Delegation scores over other two utilities, see Chapter 30, "Using Privilege Delegation".

Tracking the Status of Deployment Procedures

After you have submitted a Deployment Procedure, you can track its status from the Procedure Completion Status page. To access this page, follow these steps:

1. In Grid Control, click Deployments.

2. On the Deployments page, from the Deployment Procedure Manager section, click Procedure Completion Status.

3. On the Deployment Procedure Manager page, click the Procedure Completion Status tab.

4. On the Procedure Completion Status page, you can view the status of the Deployment Procedures.

   Table 2-2 Deployment Procedure Status

   Status	Description
   Scheduled	implies that the Deployment Procedure is scheduled to be executed at the date and time that you have specified.
   Running	implies that the Deployment Procedure is currently being executed.
   Action Required	Implies that the Deployment Procedure has stopped running as user interaction is required.
   Suspended	Implies that the Deployment Procedure has been temporarily stopped from execution. You can resume from the paused step later.
   Failed	Implies that the Deployment Procedure has failed and cannot execute the further steps. You can also ignore the error and proceed further.
   Completed	Implies that the Deployment Procedure has successfully completed its execution.
   Stopped	Implies that the Deployment Procedure has been permanently stopped from execution by the user.
   Saved	Implies that the Deployment Procedure has not been given for execution, and has been saved.
   Completed with Errors	Indicates that the Deployment Procedure completed, but completed with errors possibly because some of the steps within it might have failed and the steps might have the Skip target/Continue on Error flag enabled.

   
   

   You can also perform the following actions:

   1. Search for a particular Deployment Procedure using the Search section. Click Search to refine your search criteria.

   2. View the status of all Deployment Procedures. You can also manually refresh the page and view the updated status by clicking Refresh.

   3. View real-time status information based on a particular refresh period such as 30 seconds, 1 minute, or 5 minutes.

   4. Stop or suspend any Deployment Procedure by selecting them and clicking Stop or Suspend, respectively. You can resume at any point by clicking Resume or Retry.

   5. Delete any Deployment Procedure by selecting them and clicking Delete.