Oracle Enterprise Manager Ops Center provides numerous ways to deploy content, such as through OS Update Profiles, or as part of an OS Provisioning plan or combinations of those and other "Install Software" capabilities of Deployment Plans. This short "how-to" blog will highlight an alternative way to deploy content using Operational Profiles.
Usually we think of Operational Profiles as a way to execute a simple "one-time" script to perform a basic system administration function, which can optionally be based on user input; however, Operational Profiles can be much more powerful than that. There is often more to performing an action than merely running a script -- sometimes configuration files, packages, binaries, and other scripts, etc. are needed to perform the action, and sometimes the user would like to leave such content on the system for later use.
For shell scripts and other content written to be
generic enough to work on any flavor of UNIX, converting the same scripts and configuration files into Solaris 10 SVR4 package, Solaris 11 IPS package, and/or a Linux RPM's might be seen as three times the work, for little appreciable gain. That is where using an Operational Profile to deploy simple scripts and other generic content can be very helpful. The approach is so powerful, that pretty much any kind of content can be deployed using an Operational Profile, provided the files involved are not overly large, and it is not necessary to convert the content into UNIX variant-specific formats.
The basic formula for deploying content with an Operational Profile is as follows:
Begin with a traditional script header, which is a UNIX shell script that will be responsible for decoding and extracting content, copying files into the right places, and executing any other scripts and commands needed to install and configure that content.
Include steps to make the script platform-aware, to do the right thing for a given UNIX variant, or a "sorry" message if the operator has somehow tried to run the Operational Profile on a system where the script is not designed to run. Ops Center can constrain execution by target type, so such checks at this level are an added safeguard, but also useful with the generic target type of "Operating System" where the admin wants the script to "do the right thing," whatever the UNIX variant.
Include helpful output to show script progress, and any other informational messages that can help the admin determine what has gone wrong in the case of a problem in script execution. Such messages will be shown in the job execution log.
Include necessary "clean up" steps for normal and error exit conditions
Set non-zero exit codes when appropriate -- a non-zero exit code will cause an Operational Profile job to be marked failed, which is the admin's cue to look into the job details for diagnostic messages in the output from the script.
That first bullet deserves some explanation. If Operational Profiles are usually simple "one-time" scripts and binary content is not allowed, then how does the actual content, packages, binaries, and other scripts get delivered along with the script? More specifically, how does one include such content without needing to first create some kind of traditional package? All that is required is to simply encode the content and append it to the end of the Operational Profile. The header portion of the Operational Profile will need to contain the commands to decode the embedded content that has been appended to the bottom of the script. The header code can do whatever else is needed, and finally clean up any intermediate files that were created during the decoding and extraction of the content.
One way to encode binary and other content for inclusion in a script is to use the "uuencode" utility to convert the content into simple base64 ASCII text -- a form that is suitable to be appended to an Operational Profile. The behavior of the "uudecode" utility is such that it will skip over any parts of the input that do not fit the uuencoded "begin" and "end" clauses. For that reason, your header script will be skipped over, and uudecode will find your embedded content, that you will uuencode and paste at the end of the Operational Profile. You can have as many "begin" / "end" clauses as you need -- just separate each embedded file by an empty line between "begin" and "end" clauses.
Example: Install SUNWsneep and set the system serial number
Script: deploySUNWsneep.sh ( <- right-click / save to download)
Highlights:
#!/bin/sh
# Required variables:
OC_SERIAL="$OC_SERIAL" # The user-supplied serial number for the asset
...
Above is a good practice, showing right up front what kind of input the Operational Profile will require. The right-hand side where $OC_SERIAL appears in this example will be filled in by Ops Center based on the user input at deployment time.
The script goes on to restrict the use of the program to the intended OS type (Solaris 10 or older, in this example, but other content might be suitable for Solaris 11, or Linux -- it depends on the content and the script that will handle it).
A temporary working directory is created, and then we have the command that decodes the embedded content from "self" which in scripting terms is $0 (a variable that expands to the name of the currently executing script):
# Pass myself through uudecode, which will extract content to the current dir
uudecode $0
At that point, whatever content was appended in uuencoded form at the end of the script has been written out to the current directory. In this example that yields a file, SUNWsneep.7.0.zip, which the rest of the script proceeds to unzip, and pkgadd, followed by running "/opt/SUNWsneep/bin/sneep -s $OC_SERIAL" which is the command that stores the system serial for future use by other programs such as Explorer. Don't get hung up on the example having used a pkgadd command. The content started as a zip file and it could have been a tar.gz, or any other file. This approach simply decodes the file. The header portion of the script has to make sense of the file and do the right thing (e.g. it's up to you).
The script goes on to clean up after itself, whether or not the above was successful. Errors are echo'd by the script and a non-zero exit code is set where appropriate.
Second to last, we have:
# just in case, exit explicitly, so that uuencoded content will not cause error
OPCleanUP
exit
# The rest of the script is ignored, except by uudecode
#
# UUencoded content follows
#
# e.g. for each file needed,
# $ uuencode -m {source} {source} > {target}.uu5
# then paste the {target}.uu5 files below
# they will be extracted into the workding dir at $TDIR
#
The commentary above also describes how to encode the content.
Finally we have the uuencoded content:
begin-base64 444 SUNWsneep.7.0.zip
UEsDBBQAAAAIAPsRy0Di3vnukAAAAMcAAAAKABUAcmVhZG1lLnR4dFVUCQADOqnVT7up
...
VXgAAFBLBQYAAAAAAgACAJEAAADTNwEAAAA=
====
That last line of "====" is the base64 uuencode equivalent of a blank line, followed by "end" and as mentioned you can have as many begin/end clauses as you need. Just separate each embedded file by a blank line after each ==== and before each begin-base64.
Deploying the example Operational Profile looks like this (where I have pasted the system serial number into the required field):
The job succeeded, but here is an example of the kind of diagnostic messages that the example script produces, and how Ops Center displays them in the job details:
This same general approach could be used to deploy Explorer, and other useful utilities and scripts.
Please let us know what you think? Until next time...\Leon--
Leon Shaner | Senior IT/Product ArchitectSystems Management | Ops Center Engineering @ Oracle
The
views expressed on this [blog; Web site] are my own and do not
necessarily reflect the views of Oracle.
For more information, please go to Oracle Enterprise Manager web page or follow us at :
Twitter | Facebook | YouTube | Linkedin | Newsletter
