SDS Advanced Topics Guide - dellemc.com · 6 SDS Advanced Topics Guide Typographical Conventions • SDS Administrator’s Guide The central book to use when learning about SDS. It

DOC

Marimba Product Line

SDS Advanced Topics Guide

Version 5.3 March 2005

Copyright © 1994-2005 EMC Corporation

DOC

SDS Advanced Topics Guide 3

Contents

IntroductionHow to Read This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5Typographical Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

Command Logic ScriptingPurpose of Command Logic Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7Overview of the Scripting Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

Predefined Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10Control Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

Controlling the Task by Using Command Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11Using the DS Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11Command Logic Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

Sending Status from a Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Retrying Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Using a Script to Immediately Undo a Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Calling Java Methods and Classes from Within a Script . . . . . . . . . . . . . . . . . . . 16Using the setMacro Method to Pass Parameters to Commands . . . . . . . . . . . . . 17

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20

Application Packager IntegrationUsing SDS to Distribute Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21Creating and Editing Application Packager Task Groups . . . . . . . . . . . . . . . . . . . . . . . . .22Viewing Application Packager Tasks and Task Groups . . . . . . . . . . . . . . . . . . . . . . . . . .24

4 SDS Advanced Topics Guide

Index

Introduction 5

DOC

Introduction

This guide contains instructions for using advanced features, such as command logic scripting, and provides information about SDS integration modules. The advanced features and integration modules extend the basic features of SDS. Instructions for using SDS’s basic features appear in the SDS Administrator’s Guide, which is available on Marimba’s Documentation page, at www.marimba.com/doc/.

How to Read This GuideThis guide contains the following chapters:

• Command Logic Scripting on page 7

Describes how you can use SDS’s command logic scripting feature to control the order in which commands in a Deployment Manager task are executed, so that if a command fails, it can be ignored, if necessary, or it can be retried in case it failed for a transient reason.

• Application Packager Integration on page 21

Describes how you can use SDS to distribute software that has been packaged by using Marimba’s Software Distribution module.

Related DocumentationYou can find the following SDS books on the Technical Resources page for SDS, at www.marimba.com/doc/index_sm.html:

http://www.marimba.com/doc/index_sm.html

http://www.marimba.com/doc/


Typographical Conventions

• SDS Administrator’s Guide

The central book to use when learning about SDS. It provides conceptual information about the features that everyone will need to use.

• SDS Command-Line Interface

Contains syntax and usage information for the SDS command-line options. Also describes how to create a SOAP client to interact with the command-line interface (useful if you want to create a custom command-line or browser interface to Deployment Manager).

• SDS Deployment Guide

Contains instructions for installing SDS.

Typographical ConventionsThe following formatting conventions are used in Marimba documentation.

Table 1.

Example Explanation

Click Apply. Names of menus, commands, buttons, and other user interface elements appear in bold in instructional procedures.

Choose Edit > Cut This notation means (in this example) choose Cut from the Edit menu.

setup.exe File names, directory names, paths, code samples, and command-line text appear in a monospaced font.

cd \data Where necessary to differentiate it from text the computer displays, text you type appears in a bold monospaced font.

<your_file> Text variables are italic and enclosed in angle brackets. For example, if the documentation states, “Type some.exe -f <your_file>,” you might type some.exe -f mystuff.txt.

[-title] Command-line options that you can include or omit are enclosed in square brackets.

{quiet|verbose} Within braces, a vertical bar separates a choice of command-line options—in this example, either quiet or verbose. In the examples of Deployment Manager command-line commands, however, the vertical bar is used to delimit elements of the command. The vertical bar in this context is used as a delimiter, and is not surrounded by braces.

The kernel provides…

New terms appear in italics.

Command Logic Scripting 7

DOC

Command Logic Scripting

SDS command logic scripting feature enables you to associate a script with a task. You can use a script to control the order in which commands in your task are executed. The Deployment Service on the target servers processes and executes the script.

This chapter describes the syntax for creating the script. To add a command logic script to a task, you can use either the command-line interface or the graphical user interface (GUI) for Deployment Manager:

• For the command-line interface, you can use the -setCommandLogic option, as described in the SDS Command-Line Interface, available on the Technical Resources page for SDS, at www.marimba.com/doc/index_sm.html.

• For the GUI, see the procedure for creating and editing tasks and task groups in the SDS Administrator’s Guide.

Purpose of Command Logic ScriptingUsing a command logic script is optional. If you don’t use a script, each command is executed in order, and each command must be successful before the next command can be executed. In addition, without a command logic script, if a machine is rebooted, either because one of the commands explicitly reboots it or for some other external reason, the job is restarted at the same command where it left off, and that command is then executed again. This strategy addresses situations in which a command installs an application, and the application requires a reboot followed by a re-execution of the command to complete the installation.




Overview of the Scripting Language

The advantage of using command logic scripting is that it enables you to define the order in which commands are executed, so that if a command fails, it can be ignored, if necessary, or it can be retried in case it failed for a transient reason. Also, if a command failure causes an indeterminate state, a script could immediately execute a command to restore the state. Without a script, you would need to execute a different job to restore the state.

Overview of the Scripting LanguageThe command logic scripting language is essentially a subset of JavaScript. It contains the standard constructs, such as if-then-else constructions, for loops, while statements, variables, method invocations on Java objects, and functions. The main method invoked by the Deployment Service to execute a script is called executeScript. It takes a script to execute and a hash table with predefined variables that are made accessible to the script. The hash table is used by the Deployment Service to pass in a variable called DS that points to a ScriptInterface class (as described later in this chapter). This class implements all the methods on the Deployment Service that the script can invoke.

Predefined Variables

The scripting language provides three predefined variables in addition to the ones passed in when runScript is invoked:

• Class is a variable that points to the java.lang.Class class. It is useful for invoking Class.forName to link in references to other classes.

• System is a variable that points to the java.lang.System class. It is useful for invoking methods such as System.out.println to print messages and so on.

• Runtime is a variable that points to the java.lang.Runtime class. This class can be used to invoke methods such as Runtime.exec to fork processes and so forth.

• DS is a variable used to control the running task. Using the DS Interface on page 11 describes in more detail how it can be used.

Expressions

Expressions can consist of one of the following:

• A simple variable reference

• An allocation expression; the form is new <className>



• A method invocation on an object; the form is <Object>.<method>(<args>)

• An invocation of a function defined in the script itself; the form is <function>(<args>)

• An arithmetic expression; the form is <a><op>, where <a> and are expressions and <op> can be one of:

+ (addition)

- (subtraction)

/ (division)

* (multiplication)

• An array access, such as <a>[<index>]

• An assignment; the form is <var> = <expression>, where the value of <expression> is assigned to <var>

• Self-decrement or increment, using expressions such as ++i, i++, --i, and i—

• Self-assignment, using expressions such as i+=<expr>, i-=<expr>, i*=<expr>, i/=<expr>

• A Boolean expression (true or false) or <a><op> where <a> and are expressions and <op> can be one of:

&& (logical and; requires <a> and to be Boolean expressions)

|| (logical or; requires <a> and to be Boolean expressions)

< (less than)

<= (less than or equal to)

== (equal to)

> (greater than)

>= (greater than or equal to)

<var> instanceof <name> (tests whether the given variable is an instance of the class specified in <name>)

Functions

Functions can be defined in the language. A function is expressed as:

function <name>(<arglist>) {

<body>

}



A function can optionally return a value if necessary. The type can be any arbitrary type because all typing is done dynamically at runtime.

Variables

Variables are defined as:

var <name> = <expression>;

Control Flow

Various control flow statements are provided that are similar in nature to Java or C:

• if statements:

if (<boolean expression>) {

<body>

} else if (<boolean expression>) {

<body>

} else {

<body>

}

• while statements:

while (<boolean expression>) {

<body>

}

do {

<body>

} while (<boolean expression>);

• for loops:

for (<expression>; <boolean expression>; <expression>) {

<body>

}


Controlling the Task by Using Command Logic

Controlling the Task by Using Command LogicIn order to attach a script to a task, you can use the Edit Command Logic button on the Edit Task page in Deployment Manager’s graphical user interface. Another way to attach a script is by using the -setCommandLogic option in Deployment Manager’s command-line interface. When a script is attached to a task, the commands defined in the task form a list of numbered commands, starting at zero. The script is able to execute any one of these commands by invoking a method and passing in the index number of the command it wishes to execute. In this way, the script is able to execute commands from the task.

The Deployment Service on the target servers processes and executes the script. The interface to the Deployment Service is through the use of a predefined variable called DS. This variable implements a collection of static methods that are callable from the script and that enable it to control how the commands are executed. The script itself should consist of a function called start, which returns true if the deployment job run is successful; otherwise, it returns false.

Using the DS Interface

The predefined DS variable contains all of the methods needed in order to control the execution of commands:

• boolean exec(int index) — Executes the command at the given index and returns true if it is successful; otherwise, returns false.

• int nCommands() — Returns the number of commands that are available in this task.

• int previousRuns(int index, int decrement) — Returns the number of times the command at the given index has been successfully run. If decrement is given, it will be subtracted from the count. This method is useful when a script is being restarted after the machine is rebooted in the middle of a job run.

• String getMacro(String macroString) — Returns the value of the given macroString. Note that macroString needs to be specified exactly as it would be specified in actual usage. In other words, to see the value of a macro variable called MYDIR you need to pass in %MYDIR% to getMacro, since this is how you would actually use the macro. This strategy allows you to use this method not only to retrieve the value of simple variables, but also to expand a complex macro that might consist of many macro variables.



• void setMacro(String name, String value) — Changes the value of a macro variable. In this case, the name is specified as just the name of the variable you want to change without the percent delimiters. The value passed in is any arbitrary string. If it is given as an empty string, the macro variable will become undefined.

• String command(int index) — Returns the command at the given index.

• boolean sendStatus(int id, String message) — Sends a log entry back to Deployment Manager. The value id should be an integer that represents the log ID, and message is any arbitrary string to be logged.

In order to illustrate how command logic scripts work, the following example defines a simple script that mimics the default execution of commands when a script is not defined. In this case, the script needs to execute the commands sequentially and return failure as soon as one of the commands fails.

Here is the corresponding script:

function start() {

var n = DS.nCommands();

for (i=0; i < n; i++) {

if (DS.exec(i)==false) {

return false; // fail as soon as any command fails

}

}

// all commands succeeded so return true to indicate success

return true;

}

This script starts by getting the number of commands available using the nCommands method. It then iterates over all the commands and invokes the exec method on each command. If this method returns false, then that indicates the command failed, and the script immediately returns false. This causes a message to be sent back to Deployment Manager, indicating that the task failed on this particular endpoint. The next section goes into more involved applications of command logic and builds on the simple script template just presented.



Command Logic Applications

This section presents various examples of using scripts for common situations that might arise. The following examples are presented:

• Sending Status from a Script on page 13

• Retrying Commands on page 14

• Using a Script to Immediately Undo a Failure on page 15

• Calling Java Methods and Classes from Within a Script on page 16

• Using the setMacro Method to Pass Parameters to Commands on page 17

Sending Status from a Script

This script is a simple variation on the basic script. It executes the commands in order, but some calls to sendStatus are inserted in order to send back custom log entries to Deployment Manager:

function start() {

var n = DS.nCommands();

DS.sendStatus(8000, "Starting script");

for (i=0; i < n; i++) {

if (DS.exec(i)==false) {

DS.sendStatus(8001,"Command failed: "+DS.command(i));

return false; // fail as soon as any command fails

}

}

// all commands succeeded so return true to indicate success

DS.sendStatus(8002,"All commands succeeded.");

return true; }

All of the messages sent back with sendStatus will appear in the log file for the endpoint on which they’re being executed. The log ID can be any arbitrary log ID that doesn’t conflict with the log IDs in use for other channels such as Content Replicator or Application Packager.



Retrying Commands

Without a command logic script, a command failure immediately causes the task to fail. There are situations, however, in which a command might fail for transient reasons, and therefore retrying the command later might enable it to succeed. This section provides an example of a script that retries every command three times. Between each invocation, the script will sleep for three seconds.

In practice, you might want to be more selective about which commands to retry. For example, a command to create a directory will fail if there are insufficient permissions, and it will continue to fail no matter how many repetitions of the command are done. In contrast, a command that interacts with the network might fail due to transient network failures, so it would be a better candidate for retries. For simplicity’s sake, the following script retries all the commands:

function start() {

var retries = 3; // retry three times before giving up

var l = DS.nCommands();

for (i=0; i < l; i = i + 1) {

var done = false;

for (j=0; j < retries && done==false; j = j+1) {

done = DS.exec(i);

if (done==false) {

Thread.sleep(3000);

}

}

if (done==false) {

var Thread = Class.forName("java.lang.Thread");

Thread.sleep((long)3000);

return false;

}

}

return true;

}



Using a Script to Immediately Undo a Failure

In normal usage, a job executes commands and fails immediately when one of the commands fails. In the event of a job failure, it is possible to then automatically start a job that will restore the state of the failed machines. For example, if some new content was deployed to a set of machines and some of the machines failed, then a job can run that will restore the content to the previous version. With a script, it is possible to immediately undo the failure on the endpoint. This sample script assumes that the task has the following two commands:

<Rep> install -url http://mytrans/content -dir c:\\mycontent

<Rep> install -url http://mytrans/content -dir c:\\mycontent -version

previous

Note: <Rep> in the above example indicates a Content Replicator channel command. If you were using the command line, you would use the -addCommand option to add a command that begins: "http://<trans_URL>/Rep|rep=start install ...

In this example, the first command will install some content in a directory, and the second command will install the previous version of that content in the same directory. If both commands are executed, then the net result will be to leave the content as it was originally. The following script then will only conditionally execute the second command if the first one fails. The result is that the script will still return failure for this task, but before doing so, it will revert the content to its previous state. Thus the machine will be left in a consistent state.

function start() {

if (DS.exec(0)==false) {

// need to execute a command to undo


// help, undo failed!

DS.sendStatus(8000,"Undo command failed: "+DS.command(i));

return false;

}

// content has been reverted to the previous state, but the //job still failed to install the latest version, so return //failure.

return false;



}

// first command succeeded, so we are done

return true;

}

Calling Java Methods and Classes from Within a Script

It is possible not only to invoke static Java methods but also to access some standard Java functionality from within a command logic script. Use caution, however, when considering whether to use this feature. In general, it is better to put complex functionality in the commands themselves and then use command logic scripts only to affect how the commands executed.

However, there are some cases in which accessing Java APIs might be useful. In this example, the APIs are used to list the contents of a directory whose name is stored in the value of a macro variable. In the next section, this function will be reused in order to apply a command to each command in the directory. The following code snippet defines a function called readDirectory, which returns a variable that is an array of strings for representing all the files in the given directory:

function readDirectory(var dir) {

var file = new java.io.File(dir);

return file.list();

}

Notice that the full class name for File is given as java.io.File. Only classes in the standard java.* packages are available. Another useful method reads a property out of a file formatted as “key=value” pairs. The method returns an object that has a method getProperty, which returns the value of a property. An example of this method is given later in this chapter.

function loadProperties(var file) {

var file = new java.io.File(file);

var input = new java.io.FileInputStream(file);

var props = new java.util.Properties();

props.load((java.io.InputStream)input);

input.close();

return props;

}



Note that the input variable is explicitly casted to an instance of java.io.InputStream before it is passed in to the load method. In general, when a Java method expects an argument of a type other than a simple type such as String, integer, and so on, it should be explicitly casted to the type it expects.

Another useful feature is the ability to call Java objects’ static methods. When using static method calls, you must load a class as a variable, which you can do by using Class.forName(). The following example, which sleeps for a random time between 0 and 3 minutes, illustrates the way static methods can be used:

function randomSleep() { var Math = Class.forName("java.lang.Math"); var Thread = Class.forName("java.lang.Thread"); var delaySleep = (double) (1000*60*3); var randomSleep = Math.round(Math.random() * delaySleep); var sleepSec = (((int)randomSleep) / 1000); DS.sendStatus(911, "Sleeping for "+sleepSec+" seconds.."); Thread.sleep(randomSleep);

}

In this example, the first step is to pre-load Math and Thread as Java classes. This is done using the Class.forName() call. You can then use the variables as if they were Java objects, as is shown in the use of Math’s round() and Thread’s sleep() methods. Also note the casting that needs to be done for this example to work. First, delaySleep is cast as a double, because the Math.round() method requires a double. Next, randomSleep is recast as an int so that it can be divided by 1000 and eventually passed off to sendStatus to display. Notice also that you do not need to cast randomSleep into a long because Math.round() does that for you.

Using the setMacro Method to Pass Parameters to Commands

This section illustrates the use of a method called setMacro, which allows the script to change the value of a macro variable. The primary function of this method is to allow the script to pass parameters to commands in the task. A few examples are provided that will also make use of the readDirectory and loadProperties functions presented in the previous section.

The first example involves a script that executes some command on all of the files in a specified directory. The command is specified by the macro variable FILE, which holds the value of the file to be operated on:

system,true=c:\CheckFile %FILE%

In this case, the command is a remote system command that invokes a program called CheckFile on each file.



Note: The above example shows an abbreviated syntax for a remote system command. If you were using the command line, you would use the -addCommand option to add the command "system,true=c:\CheckFile %FILE%"

Here is the command logic that would invoke this command on all the files in a given directory, which is set through the use of a macro variable called DIRECTORY.

function start() {

var dir = DS.getMacro("%DIRECTORY%");

var list = readDirectory(dir);

var status = true;

for (i=0; i < list; i++) {

DS.sendStatus(8000,"Checking file "+list[i]);

DS.setMacro("FILE", dir+File.separator+list[i]);


DS.sendStatus(8001,"Check failed for "+list[i]);

status = false;

}

}

return status;

}

The function makes use of the readDirectory function, introduced in the previous section, to create an array of strings that represent all the files in the directory. It also uses getMacro to get the value of the DIRECTORY macro variable, which tells it which directory to read. Then for each file in the directory, the function calls setMacro to set the value of the FILE macro variable, and then the function executes the command. Note that if the command fails, the function merely records that one of the files failed the check, and then it continues to check all the rest of the files. At the end, the function returns false if any of the files failed the check.

The next example makes use of the loadProperties function introduced in the previous section. The scenario is that some content to be installed with a Content Replicator command needs to be placed in the same directory where a certain application was installed. The script needs to run a command that determines the location of the application and then sets the appropriate



directory where Content Replicator should install its content. A remote system command is run to determine the location of the application. This command then communicates the result back to the script by creating a file called results.txt, which contains a single key/value pair with the key dir, which holds the value of the directory. The commands for this task are as follows (syntax is abbreviated as described earlier):

system,true=c:\FindAppLocation

<Rep> install -url http://trans/mycontent -dir %LOCATION%

The script will simply invoke the first command to find the location and create a property file with the results. Then it will read the property from the file and use setMacro to communicate the result to the Content Replicator channel command:

function start() {


DS.sendStatus(8001,DS.command(0) + " failed.");

return false;

}

var props = loadProperties("results.txt");

DS.setMacro("LOCATION", props.getProperty("dir"));


DS.sendStatus(8001,DS.command(1) +" failed.");

return false;

}

return true;

}

An alternative strategy can be used if the FindAppLocation command can be written as a custom Java channel. In this case, the Java code can simply set a system property LOCATION whose value is the directory to use for installing the content. This works because the Deployment Service uses Java system properties if it can’t resolve a macro variable otherwise. It would be important, when using this strategy, to make sure that LOCATION is not otherwise defined.


Conclusion

ConclusionThis chapter illustrated the use of command logic to customize how commands are executed in a task. Although scripts are optional and, in most cases, are not required to do what is typically needed, the command logic feature provides useful extensibility to the deployment mechanism. It should be used with care, however, and then only when necessary.

Application Packager Integration 21

DOC

Application Packager Integration

The Software Distribution module (Application Packager channel) enables you to package most common applications, whether purchased off-the-shelf or developed in-house as a custom application. Once you have packaged an application into a channel, you can use Deployment Manager to deploy the application.

Using SDS to Distribute SoftwareThis chapter describes how to use the Software Distribution module to create an extended task group that automatically includes tasks for previewing, staging, installing, updating, repairing, and uninstalling applications that you have packaged by using Marimba’s Application Packager.

You would use the procedures described in this chapter after you have already used Application Packager to create channels that you now want to deploy. If you have not yet created your packaged application channels and you would like instructions for doing so, you will need to start the Application Packager channel itself and then click the Help button inside Application Packager. Alternatively, see the Application Packager Administrator’s Guide, available on Marimba’s Documentation page, at www.marimba.com/doc/.



Creating and Editing Application Packager Task Groups

Note: To find out if you have the Software Distribution module installed, go to the Settings > View Integration Module Details page in Deployment Manager’s graphical user interface (GUI), or use the -showModule option in Deployment Manager’s command-line interface. For instructions on installing integration modules, see the SDS Deployment Guide, available on Marimba’s Documentation page, at www.marimba.com/doc/.

Although Application Packager extends both task groups and commands, you should use the extended Application Packager task group and avoid using the extended Application Packager command. When you create a task group, the necessary tasks and commands are automatically created for you. The extended command type (shown on the Edit Application Packager Command page) remains in the product for purposes of backwards-compatibility only. Because using the extended command is discouraged, this chapter does not describe how to use it. Information is available, however, in the online help and the SDS Command-Line Interface.

Creating and Editing Application Packager Task GroupsWhen you create an Application Packager task group, the following tasks, and the commands that each task contains, are automatically created. The first command in each task subscribes the target servers to the packaged application channel if the targets have not yet subscribed to the channel. (The subscribe action puts the channel on the endpoint.) The second command in each task sets a property to prevent the application from being immediately installed. The other commands are task-specific:

• Install task. Use this task both for the initial installation and for updating the software. This task either installs the software or, if it has already been installed, updates the channel and then installs the updated software.

• Verify task. This task checks the software’s integrity but does not fix any errors in the software that the specified channel installed on the target server. For example, if someone inadvertently deleted some files from a particular target server, using this option would tell you which files are missing but would not restore them. If you accidentally use this task for a target server that does not already have the packaged application channel on it, the job will fail.

• Repair task. This task checks the software’s integrity and fixes any errors in the software that the specified channel installed on the target server. For example, if someone inadvertently deleted some files from a particular target server, using this option would restore the files.



Creating and Editing Application Packager Task Groups

You might want to use the install task in conjunction with the repair task. If you use the repair task by itself, no check is done to make sure that the target server has the latest version of the channel. A check is done to make sure only that the software contains the files that it originally contained when installed and that none of the files got corrupted. If some files were deleted or corrupted, the target server requests the files it needs from the transmitter. If the channel on the transmitter is a later version than that on the target server, the repair might fail. Therefore, it is safest to precede a repair task with an install task. (That is, set the corresponding repair job to run on the success of the install job.)

• Stage task. This task updates the channel, which stages the new software on the target servers, but the software is not installed.

• Uninstall task. This task removes the software that the packaged application channel previously installed on the target server. In addition, it removes the packaged application channel.

Note: The following procedure assumes you are using the GUI. For information about using the command line, see the documentation for the -create and -setPackagedAppSettings options in the Application Packager chapter of the SDS Command-Line Interface.

▼ To create an Application Packager task group and add tasks to it:

1 On the Edit Application Packager Task Group page, enter a description of the task group, if desired.

The description will appear next to the task group name on the Folder Contents page.

2 Enter the URL of the packaged application channel, or alternatively, enter a transmitter name and port number (for example: trans.acme.com:5282), and then click Browse Transmitter to find and select a channel. (If you omit the port number, it will default to 80.)

Notes: URLs are case-sensitive; therefore, be sure to use the correct capitalization. If you want to enter the URL of a channel on an SSL-enabled transmitter, be sure to use https rather than http.

Also, make sure that the URL for the packaged application channel does not include spaces. Otherwise, the packaged application channel will not install properly.

Tip: You can use macro variables in the channel URL if you have defined them. The syntax for using a macro is %MACRO_NAME%, where MACRO_NAME is the name of the macro. The syntax is the same on both Windows and


Viewing Application Packager Tasks and Task Groups

UNIX. Macro names are case-sensitive; that is, you need to use the same capitalization when specifying a macro that you used when you defined it.

3 If a subscribe password is set for accessing the transmitter, then enter the user name and password (transmitter credentials).

If the permission is set to be password-only, you can omit the user name.

4 Specify a name for the packaged application and click Generate Tasks.

The tasks that are created are listed in the “Tasks” section.

5 If desired, specify the number of minutes to use for the command response timeout.

The default is no timeout. This setting enables you to better determine when a command might be “hung” and therefore need to be stopped. To set the timeout, you need to estimate how many minutes to wait for an action to be completed. For example, if you think that installing the application might take up to an hour, you could set this option to 60. The setting you enter here will be used for all the commands in all the tasks in the group.

6 Click OK, to save the task group you just created.

You are returned to the Folder Contents page, and your newly created task group and its description appear in the list.

Note: It is not possible to edit the tasks, commands, or descriptions of tasks in an Application Packager task group. Also, it is not possible to delete any of the individual tasks in the task group. If you would like to see the details of the commands included in a task, see the next section, Viewing Application Packager Tasks and Task Groups on page 24.

Viewing Application Packager Tasks and Task GroupsThis topic gives instructions for viewing the commands and tasks in an Application Packager task group, even though you cannot edit or delete them.

Note: The following procedure assumes you are using the GUI. For information about using the command line, see the documentation for the -show /v t option (to show verbose information about a task group), described in the SDS Command-Line Interface.



▼ To view Application Packager tasks and their commands:

1 Click the Folder Contents tab and navigate to the folder in which the Application Packager task group is stored.

2 Click the view link in the row for the Application Packager task group you want to see.

The View Task Group page appears.

3 Click the name of the task whose commands you want to see.

The View Task page appears.

The first command that appears in all the tasks is a subscribe command. In order for any action to take place on the target server, the channel needs to be placed on the target, and this is what the subscribe command does. If a subscribe password has been set on the transmitter, you need to supply the user name and password so that this subscribe command can be carried out.

Other commands in the tasks set certain channel properties in order to override the channel’s current parameters. The channel parameters and their descriptions are listed alphabetically in a chapter of the SDS Reference Guide, available on Marimba’s Documentation page, at www.marimba.com/doc/.

For more information about the commands included in specific tasks, see the list of tasks provided at the beginning of the section Creating and Editing Application Packager Task Groups on page 22.




DOC

SDS Advanced Topics Guide 27

Index

AApplication Packager task groups 22

BBrowse Transmitter button 23

Cchannel parameters 25channel properties 25conventions, formatting 6

EEdit Application Packager Task Group page 22

FFolder Contents tab 25formatting conventions 6

Iinstall task 22

Mmacro variables in channel URLs 23

Pparameters, channel 25properties, channel 25

Rremoving packaged application channels 23repair task 22

SSoftware Distribution module 21stage task 23subscribe command 25

Ttask groups

creating and editing, for Application Packager 22

tasks, in an Application Packager task group 24

Uuninstall task 23URLs

for an Application Packager channel 23

Vverify task 22view link 25View Task Group page 25

© 2011 - 2013 EMC Corporation. All Rights Reserved. EMC believes the information in this publication is accurate as of its publication date. The information is subject to change

without

notice.

THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC CORPORATION MAKES NO

REPRESENTATIONS OR

WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND

SPECIFICALLY

DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.

EMC2, EMC, and the EMC logo are registered trademarks or trademarks of EMC Corporation in the United State and other

countries.

All other trademarks used herein are the property of their respective owners.

Documents

SDS Advanced Topics Guide - dellemc.com · 6 SDS Advanced Topics Guide Typographical Conventions • SDS Administrator’s Guide The central book to use when learning about SDS. It