15 Using a Software Library

This chapter describes the Software Library feature of Enterprise Manager and contains the following sections:

15.1 Overview of Software Library

The Software Library serves as a repository to store certified software images (for example Oracle Database, operating system, Oracle Real Application Clusters, third party softwares) and other related entities. These can then be automatically mass deployed to provision software, software updates and servers using Oracle Enterprise Manger in a reliable and repeatable manner. These provisioning operations, which are unattended and can be scheduled, lead to substantial cost savings.

Software Library can store the following types of entities:

  • Components: These entities represent the primary building blocks of the provisioning framework. A component can represent Operating system software, Oracle software or any third party software and applications. Software components are individually maintained within the Software Library and versions, states and maturity levels can be associated with each component.

  • Directives: 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. Directives encapsulate the script, the command line used to invoke the script, and the script configuration properties. Directives are contained within a file that are stored in the 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, and Storage Templates: These entities are associated with the Bare Metal Provisioning application of the Oracle Enterprise Manager and are used to provision software on bare metal and live servers. Briefly, an Image can be described as a collection of components along with the necessary directives that create a deployable configuration for a single or set of target machines. Network templates, Hardware templates and Storage templates are used to define the network, hardware and disk layout configuration of the target machines respectively. Versions, states and maturity levels can be associated with each of these entities.

15.2 Setting up the Software Library

Software library can be created using any mounted filesystem that is readable and writeable from the Oracle Management Service (OMS). If one is using a single OMS in the EM infrastructure then one can even use directory a local directory on the OMS host for creating the Software library. One has to make sure that there is enough space available for the storage of software binaries, and associated scripts for the entities that one wants to create and store.

In case there are multiple OMSes deployed for high availability and fail over, then Software Library should be located in a directory accessible by all OMSes. For multiple OMS environments, the directory can be on a Network File Server 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 and other entities.

15.3 Configuring the Software Library For Use With Oracle Enterprise Manager

To configure the Software library follow these steps:

  1. Access the Oracle Enterprise Manager's Provisioning Application by navigating to the Deployments tab.

  2. Under the Deployments tab go to the Provisioning tab. There are a number of tabs here for creating components, directives etc. One can access some or all of the tabs depending on the privileges assigned to the user.

  3. Access the Administration tab. This requires superuser privileges. Refer to section 3.1 "Creating Super Administrator For Enterprise Manager" of the Oracle Bare Metal Provisioning Best Practices document. This is available at:

    http://www.oracle.com/technology/products/oem/pdf/bmp_best_practice.pdf

  4. In the Software Library Configuration section of the Administration tab, press the Add button.

  5. On the Add Software Library Location page, enter the directory location of the software library being created and then click OK.

15.4 Creating and Deleting Entities in the Software Library

The graphical user interface of the Provisioning application has various tabs for creating Components, Directives, Images, Network and Hardware Templates, which are created and stored in the software library. One can create various subdirectories for storing the entities in the Software Library. Same tabs allow a user to delete and edit an entity stored in the Software Library. They also allow a user to view metadata information for an entity.

Refer to section 4.2 "Creating Directives, Components, Network Profiles for RAC-CRS Image" of the Bare Metal Provisioning Best Practices document as an example of how to create various entities. This is available at:

http://www.oracle.com/technology/products/oem/pdf/bmp_best_practice.pdf

15.5 Exporting and Importing Software Library Entities Across Enterprise Manager Deployments

Creating an entity (for example, components or directives) involves the following steps:

  • Creation of meta-data. As a part of the creation process a user enters information like name, type, version and other information associated with the entity. This information serves as the meta-data of the entity and is entered into the necessary tables in the Management Repository. Metadata for software library entities is stored in the following tables of EM Management Repository:

    MGMT_SWLIB_DIRECTORIES

    MGMT_SWLIB_ENTITIES

    MGMT_SWLIB_MATURITY_STATUS

    MGMT_SWLIB_ENTITY_REVISIONS

    MGMT_SWLIB_ENTITY_REFERENCES

    MGMT_SWLIB_ENTITY_DOCUMENTS

    MGMT_SWLIB_ENTITY_DATA

    MGMT_SWLIB_ENTITY_PARAMETERS

    MGMT_SWLIB_REVISIONS_PARAMETERS

    MGMT_SWLIB_ENTITY_PLATFORMS

    MGMT_SWLIB_DATA_DIRECTORIES

  • Optionally storing a file (for example user uploading executable binaries for a operating system component or script for a directive, tar files containing cloned oracle homes created and stored by the Enterprise Manager in the Software library, etc.). This file is stored under a top-level directory of the file system specified while configuring the Software Library.

    An entity is thus possesses two types of information, meta-data and associated files, which are stored in Oracle Enterprise Manager Management Repository (Management Repository) and Software Library respectively.

15.6 Exporting and Importing Entities Across Oracle Enterprise Manager Deployments

Components and Directives can be exported and imported across different Software Libraries used by different EM deployments. The deploymentLibrabryExport deploymentLibrabryImport scripts used for importing and exporting the software library entities respectively. These scripts are present in the bin directory of the OMS Oracle Home and provide the flexibility to transfer entities from a test to production or between different production environments.

The scripts support the following import/export use cases:

  • Exporting all directives and importing the same.

  • Exporting all components and importing the same.

  • Exporting all entities in the software library (including Network profiles, Images etc.) and importing the same.

15.6.1 How the Importing and Exporting Scripts Funtion

When invoked the export scripts generate an xml file which encapsulates the meta-data and relationships between the entities, and two directories called binaries and documentation. The xml file and the directories are created under the location provided while invoking the script. This location can be mounted filesystem wrtieable by the OMS. The xml and the two directories can then be transferred to a different EM deployment for consumption by the import script.

15.6.1.1 Export Script

The export script can be located at the following location:

  • For OMS on Linux: <OMS HOME>/bin/deploymentLibraryExport.sh

  • For OMS on Windows: <OMS HOME>/bin/deploymentLibraryExport.bat

Sample usage is:

<OMS HOME>/bin//deploymentLibraryExport.sh <conn string> <user> <passwd> <dir loc> <-metadata|-full> [-dir|-comp]

Where the following is true:

<conn string> is of form: "jdbc:oracle:thin:@dbhost:dbport:sid" where dbhost, dbport and sid to be replaced appropriately with the hostname, database port and database SID for the Management Repository.

<user> is Management Repository username. This has to be the SYSMAN user or any other user with higher privileges to access the Software Library tables in the Management Repository database.

<passwd> is password for the username supplied for the Management Repository.

<dir loc> is the directory location where entity xml file, binaries directory and documentation directory would be created.

<-metadata|-full> if used with -full, then binary associated with the components also gets exported, else only metadata is exported.

[-dir|-comp] is optional; use -dir to export all directives and -comp to export all components. If nothing is used, all entities will be exported.

15.6.1.2 Import Script

The import script can be located at the following location:

  • For OMS on Linux: <OMS HOME>/bin/deploymentLibraryImport.sh

  • For OMS on Windows: <OMS HOME>/bin/deploymentLibraryImport.bat

Sample usage is:

<OMS HOME>/bin/ /deploymentLibraryImport.sh <conn string> <user> <passwd> <basedir> <filename> [-force]

Where the following is true:

<conn string> is of form: "jdbc:oracle:thin:@dbhost:dbport:sid" where dbhost, dbport and sid to be replaced appropriately with the hostname, database port and database SID for the Management Repository.

<user> is Management Repository username. This has to be the SYSMAN user or any other user with higher privileges to access the Software Library tables in the Management Repository database.

<passwd> is password for the username supplied.

<basedir> is absolute directory location where entity xml file created after the export operation is present

<filename> is the name of the xml file created after the export operation

[-force] is optional; and used when an entity to be imported is already present in the repository. This will create a new revision of the entity in the repository.

Note:

If the -force option is not used then the import operation will be aborted if there are existing entities in Software library with the same name and under the same directory structure as the ones being imported. When the import script aborts then none of the entities would be imported.

15.6.2 Use Cases for Import and Export

The following examples are use cases for the Import and Export scripts.

  1. Use Case 1: Exporting all directives

    Sample usage of the export script for transferring all directives is shown below:

    <OMS HOME>/bin//deploymentLibraryExport.sh <conn string> <user> <passwd> <dir loc> -dir

  2. Use Case 2: Exporting all components

    Sample usage of the export and import scripts for transferring all directives is shown below.

    For exporting only the meta-data of all the components the export script can be used as follows:

    <OMS HOME>/bin//deploymentLibraryExport.sh <conn string> <user> <passwd> <dir loc> -metadata -comp

    For exporting both meta-data and associated files of all the components the export script can be used as follows:

    <OMS HOME>/bin//deploymentLibraryExport.sh <conn string> <user> <passwd> <dir loc> -full -comp

  3. Use Case 3: Exporting all entities (for example, images and network profiles) along with components and directives)

    Sample usage of the export and import scripts for transferring all directives is shown below:

    For exporting only the meta-data of all the entities the export script can be used as follows:

    <OMS HOME>/bin//deploymentLibraryExport.sh <conn string> <user> <passwd> <dir loc> -metadata

    For exporting both meta-data and associated files of all the entities the export script can be used as follows:

    <OMS HOME>/bin//deploymentLibraryExport.sh <conn string> <user> <passwd> <dir loc> -full

  4. Use Case 4: Importing all entities or all directives or all components

    Sample usage of the scripts for transferring all directives, all components or all entities is shown below:

    <OMS HOME>/bin/ /deploymentLibraryImport.sh <conn string> <user> <passwd> <basedir> <filename> [-force]

15.7 Alternate Approach for Transferring a Software Library Across Different Oracle Enterprise Manager Deployments

Using Software Library export and import scripts is the Oracle recommended method for transferring the contents of a Software library. However, a Software Library can also be transferred across EM deployments by following the given steps:

  1. Archiving the Software Library:

    1. Export and archive the metadata for the entities in the EM Management Repository using database export feature.

    2. Archive the base directory of the Software Library that was configured while setting up the Software Library.

  2. Restoring the Software Library:

    1. Import the archived metadata into the Management Repository of the other EM deployment using the database import feature.

    2. Restore the archived base directory by either copying or mounting it to a location accessible by the OMS/OMSes of the other EM deployment.

    3. Configure the Software Library for use with the Enterprise Manager if it is not done already.

15.8 De-Configuring a Software Library

Go to the Administration tab, Software Library section, choose the Software Library entry and then press the Remove button to de-configure a Software Library.

15.9 Deleting Entities and Purging the Contents of the Software Library

The entities can be deleted from the relevant tabs provided by the provisioning application. But it is to be noted that deleting the entity does not purge the files associated with it from the software library file system.

To clean up and delete entities completely from the file system of the Software Library, one needs to run the purgeDeploymentLibrary script. The script is located at the following location:

For OMS on Linux: <OMS HOME>/bin/ purgeDeploymentLibrary.sh

Sample usage of purgeDeploymentLibrary

<OMS HOME>/bin/purgeDeploymentLibrary.sh <conn string> <username> <password> [-job <oms_host>]

Where the following is true:

<conn string> is of form: "jdbc:oracle:thin:@dbhost:dbport:sid" where dbhost, dbport and sid to be replaced appropriately with the hostname, database port and database SID for the Oracle Management Repository.

<username> is Oracle Management Repository username. This has to be the SYSMAN user or any other user with higher privileges to access the Software Library tables in the Management Repository database.

<password> is password for the username supplied.

-job <oms_host> is optional; if provided a job would be submitted (schedule is immediate). User can see the status of the job by navigating to the Jobs tab on Enterprise Manager console. <oms_host> is OMS hostname. In case there are multiple OMSes then host name of any one OMS can be used along with the -job option.

Note:

The -job option is optional though recommended by Oracle as the purge operation could be a time intensive operation.

15.10 Software Library Issues

Component creation sometimes fails with "Cannot create under the software library, please contact your administrator". This may happen if the Software Library is not configured with the Enterprise Manager. Please follow the Configuring Software Library section. Create the components once the software library is configured.

Metadata for entities is intact in the Management Repository but file system of the Software library where the associated files are stored has been corrupted. Restoring the file system should be fine but one will loose the entities that were created since the last backup. These entities will still show up in the Provisioning UI but errors will be encountered while accessing them or attempting to deploy them.

There is no support for purging Software Library entities from a Windows OMS.

Additional references concerning Oracle Bare Metal Provisioning Best Practices are available at the following location:

http://www.oracle.com/technology/products/oem/pdf/bmp_best_practice.pdf