Guidelines for Writing SM Command Scripts

Below are some basic guidelines for the management of your systems via written scripts for remote execution on one or more Service Processors.

Shell Scripts
You should be familiar with standard shell scripting. To create your scripts, use the examples provided in the NSV under the commands/sample_scripts/scripts directory as a starting point.

SSH
You must currently use an SSH (Secure Shell) client to execute automated SM command scripts.

Authentication
To avoid a password prompt each time you run a script on a Service Processor, upload a public key or trusted host key to each Service Processor.

Authorization Levels
User groups define standard privileges. Access changes (such as adding users or uploading keys) typically requires manager-level access while most other management tasks can be performed by an administrator-level user.

Return Codes
Every subcommand returns one or more return codes when it completes.

Nowait Argument
Most commands complete quickly and are performed synchronously. For some longer operations (such as rebooting the platform) a --nowait option is provided so that a script can initiate the operation without waiting for it to return.

Quiet Argument
The delete and update operations (such as access delete user, sp delete event) accept multiple targets. To ensure that a certain set of targets is deleted on a set of Service Processors, you can use the --quiet argument to suppress errors if one of the targets is not found or to suppress interactive warning messages from the platform command.

Command Output
Common, general output is detailed below:

Commands that complete successfully return 0 with no success return string. Some exceptions are commands that also return vital information.
Table output, interactive warnings, and any other non-error messages are directed to standard output.
Commands that return errors display the return codes and a descriptive error string.

Common characteristics of table output are detailed below:

Heading columns are provided by default for output with more than one column.
Single column output does not include a heading.
To suppress headings, use the -H argument.
Data for each column is left-aligned with at least one space between columns. Numeric data is right-aligned.
The -D argument allows you to specify a delimiter character when scripting. This is very useful in parsing fields with white space.
If all lines have the same number and type of data values, each row is printed to a separate line so variable data can be parsed easily. For example, excuting access get users -g monitor returns a list of monitor users each on a separate line.
Commands that return multiple columns (such as inventory get hardware) can have a minimal default set of columns and a --verbose argument to display all columns. Some commands include arguments that allow you to select specific columns to output.

Other Tips

Consider placing your scripts in a subdirectory under the commands/sample_scripts/scripts folder in the NSV to centralize your development.
Externalize the set of Service Processor IP addresses into a file to be shared across all of your scripts.
Consider using a script to create the initial manager account and upload its public key on your Service Processors.
Test the output and return codes of each command manually by using SSH to log in to the Service Processor and run the commands individually.
Test your scripts on a single staging machine before applying them to your remaining machines.
To configure all of your Service Processors in the same manner, consider configuring a single Service Processor, then using the sp load settings command to synchronize that configuration on the remaining machines.
If running the script from the Service Processor, there are a limited number of commands (not a full bash environment).