Package Deployment with OpsCenter

There has been some discussion on Constantins blog about working around IPS' scripting limitations.

I don't want to talk about the reasons, why IPS does not have classical pre/postinstall-scripts, but I want to demonstrate how this functionality could be achieved with Oracle's Enterprise Manager OpsCenter.

If you don't know OpsCenter, it's _the_ management tool from Oracle for Solaris, Unbreakable Linux and OracleVM.


OS Updates

In OpsCenter terminology Package deployments are called "OS Updates". OS Updates consist of Update Components (Packages, Patches and Configurations), Update Policies and Update Profiles. If an OS is to be updated, so called "Update Profile"-jobs will be sent to hosts run.

Update Profiles

There are two types of Update Profiles, System-defined and User-defined. What we're looking for are user defined profiles. A user-defined profile contains components. These components can be Packages, Pre/Postinstall-Scripts and Configuration files.

They can also contain macros to be run on the target system to return information about the system. This information can then be used to dynamically create a configuration file. 

It is also possible to run probes, to check if pre-requisites are met.

Update Profiles can also contain other update profiles. (e.g. to create a Mail-Server profile or Web-Server profile)

In the picture we can see two Splunk Profiles. Below you can see some components, like the SMF Manifest or a postinstall script.




















Update Components

Update components are organised into folders:










Configuration Files carry a version number.

Uploading configuration file (-templates) or scripts is simple:
















Running OS Update Job

It is easy to run update jobs on one or several hosts. There are different options that can be set how to run the jobs...























While the job is running and after it's finished the job details can be monitored. Of course it makes sense to have good error handling in the pre/postscript.



















Summary

The examples shown are with SysV packages, as OpsCenter for obvious reasons lacks IPS support at the moment. But it shows how scripts can be run before and after package installation. As an alternative to OpsCenter, the same can be achieved using e.g. Puppet, bcfg2 or cfenginge.

The nice thing about using a management tool is, to compare different systems, find differences and keep them standardized.

Comments

Nico said…
Hab gesehen du kommst aus der Schweiz - hätte paar Fragen zu Solaris - wäre nett wenn dich bei mir melden könntest :)

Gruß
April 4, 2011 at 4:46 PM
Unknown said…
Hallo Nico

Kannst Du mir noch Deine Kontaktdaten im Kommentar zukommen lassen?

(Werde den Kommentar nicht veröffentlichen)
April 5, 2011 at 8:35 AM
Post a Comment

Popular posts from this blog

Heating up the Data Pipeline (Part 1)

Image
Pre-Processing Data I often hear the question from our customers, how data can be transformed prior to indexing in Splunk. Damien from  Baboonbones  has done a tremendous job in creating add-ons   providing custom inputs for Splunk. Most of his custom inputs provide the means to pre-process data by allowing custom event handlers to be written. Sometimes you still want to pre-process data that gets collected from Splunk's standard input types, like file monitors, Windows EventLogs, scripted inputs etc. Also, not everyone is capable of writing custom event handlers. A requirement these customers have, is that they have rolled out a large number of Splunk Universal Forwarders and they do not want to install another agent. To summarize, the solution capable of pre-processing data, should be easy to use, be easily integrated and be build on top of their existing architecture. How to plumb Splunk Pipelines Splunk has its own fittings to connect a Universal Forwar
Read more

Heating up the Data Pipeline (Part 3)

Image
Welcome back to the "Heating up the Data Pipeline" blog series. In part 1 we talked about how to route data from Splunk to a 3rd party system. In part 2 walked through a simple data flow that passes data collected from Splunk Forwarders through Apache NiFi back to Splunk over the HTTP Event Collector. In this part, we will look at a more complex use case, where we route events to an index, based on the sending host's classification. The classification will be looked up from a CSV file. We will make use of Apache NiFi's new Record-Oriented  data handling capabilities, which will look initially a bit more complicated, but once you grasp it, it will make further Use Cases easier and faster to build. High-Level Dataflow We will again start with our ListentTCP input, but this time we will send the data to another Processor Group. The Processor Group will again emit events suitable for Splunk HEC. Note that we have increased the Max Batch Size from 1
Read more

Heating up the Data Pipeline (Part 2)

Image
In Part 1 we went through how to route events from Splunk to a 3rd party system without losing metadata. Now I'll show you how events can be transformed using Apache NiFi and be sent back to Splunk into the  HTTP Event Collector . Note: The following is not a step-by-step documentation. To learn how to use Apache NiFi you should read the G etting Started Guide . Simple Pass-Through Flow As a first exercise we will create a simple flow, that only passes data through NiFi, without applying any complex transformations. The following picture shows a high-level NiFi flow, that receives events in our custom uncooked event format with a TCP listener, then sends the data further into a transformation "black box" (aka Processor Group), which emits events in a format, that can be ingested into a Splunk HTTP Event Collector input. Apache Nifi currently provides a rapidly growing number of processors (currently 266), which can be used for data ingestion, transfo
Read more