Home > Veritas Storage Foundation™ Volume Manager Manual Pages

GRIDCLI (1M)

Maintenance Commands

NAME
SYNOPSIS
DESCRIPTION
COMMANDS
OPTIONS
NOTES
EXAMPLES
SEE ALSO
COPYRIGHTS

NAME

gridcli - a Veritas Provider Access Layer (VxPAL) command-line utility to the Centralized Command Grid (CCG). gridcli calls the VxPAL agents that securely distribute files and run commands across a domain of heterogeneous hosts.

SYNOPSIS

gridcli [--domain name][--host name][--allhosts] list files

gridcli [--domain name][--host name][--allhosts] list runs

gridcli [--domain name][--host name][--allhosts] list declarations

gridcli [--domain name][--query string] list hosts

gridcli [--domain name][--host name] pull file remotefile localfile

gridcli [--domain name][--host name][--allhosts][--query string] push file remotefile localfile

gridcli [--domain name][--host name][--allhosts][--query string] push cmd localcommand commandname

gridcli [--domain name][--host name][--allhosts][--noprompt][--query string][--nowait] [--keep][--schedule timespec][--format {simple | std | xml}] run commandname[ arg1 arg2 arg3 ]

gridcli [--domain name][--allhosts][--host name][--wait][--keep][--format {simple | std | xml}] getresults commandname

gridcli [--domain name][--host name] trigger commandname

gridcli [--domain name][--host name][--allhosts] reschedule commandname timespec

gridcli [--domain name][--host name][--allhosts] pause commandname

gridcli [--domain name][--host name][--allhosts] resume commandname

gridcli [--domain name][--host name][--allhosts] delete file filename

gridcli [--domain name][--host name][--allhosts] delete run commandname

DESCRIPTION

gridcli is a Veritas Provider Access Layer (VxPAL) command-line utility to the Centralized Command Grid (CCG). gridcli calls the VxPAL agents (gridnode and gridcentral) that securely distribute files and run commands across a domain of heterogeneous hosts.

CCG comes in two incarnations. One incarnation is the gridnode agent running on the target hosts that is responsible for file I/O and forking (or spawning) commands. The other incarnation is the gridcentral, a central coordinator responsible for distribution of requests and collecting results. Both incarnations are tolerant of failures, such that scheduled work resumes after central is failed over, or a gridnode is restarted or rebooted. When a gridnode rejoins the domain, it will receive whatever files, commands, and execution requests that it has missed.

gridcli and the agents are both involved in distributing. The gridnode agent is always the end_point target of a pushing a file, and it is always initiated by the gridcli. For example, when you push to all hosts, it goes through the gridcentral. The gridcentral agent remembers what is pushed. When a new host is configured (or a host's gridnode rejoins the domain) the gridnode receives what is stored previously on the gridcentral.

COMMANDS

list files, runs, declarations, hosts: Shows files, commands, or declarations currently stored, declared, or scheduled for run and names of hosts in grid. Declarations are commands that are installed with Storage Foundation products and can be run without being pushed, some of which are product internal interfaces. Declarations are configured to be stored in the /opt/VRTSccg/etc/declare directory.
pull file: Pulls a file from a remote server to localfile.
push cmd: Pushes localfile to hosts in domain and can set remotefile to commandname and set runnable permissions. remotefile may contain slashes to specify directories.
run commandname [ arg1 arg2 arg3 ... ]: Runs a previously pushed or a declared command.
getresults commandname: Retrieves output from previously executed commands.
trigger commandname: Cause a command running with a schedule to run immediately.
reschedule commandname: Change the scheduled run times for a command.
pause commandname
resume commandname: Prevents or allows a scheduled command to run at scheduled time. Allows a scheduled command to run at scheduled time.
delete file filename
delete run commandname: Delete file or command. The request ID may be used to disambiguate names if necessary.

OPTIONS

--domain name

Identifies the host running the Domain Controller. (This is the Storage Foundation Manager.) Domain name can be short name or fully-qualified host name. --domain name is optional as gridcli uses the value specified in csf_resolv.conf as the default Domain Controller.

--host name

Identifies the target host. Host name can be short name, IP address, or fully-qualified host name. On HP-UX systems, the etc/hosts file needs to be configured correctly. The first entry after the IP address must be the name assigned to the host. Invoke the --host name to see the name for the host. The --hostname must be the first entry after the IP address. Thereafter, user aliases must be specified.

--allhosts

Identifies all hosts in the grid. A registry setting must be added to run this command option. The following command adds the registry setting: /opt/VRTSobc/pal33/bin/vxregctl /etc/vx/isis/Registry setvalue Software/VERITAS/VRTSobc/pal33/Agents/gridcentral/Providers/gridcentral "enable_run" REG_SZ "on" /opt/VRTSobc/pal33/bin/vxpalctrl -a gridcentral -c restart If the registry setting value is missing, it is interpreted as "off."

--noprompt

Overrides the Yes/No prompt when running the gridcli --allhosts run commandname command. This would be primarily useful in scripts, for example.

--query string

Alternate mechanism to identify hosts. Queries can be run on partial or exact strings. and and or expressions are allowed. The following host properties are allowed: OS_FRIENDLY_NAME, OS_NAME, OS_PROCESSOR, and OS_VERSION. For example, the mycommand command will be pushed on all Solaris 8 hosts running on Sparc processors:

gridcli --query 'OS_FRIENDLY_NAME == "Solaris" and 
OS_NAME == "SunOS" and OS_PROCESSOR == "sparc" and 
OS_VERSION == "5.8"' push cmd myprogram myprogram

--user username

A valid user name for logging on to the target host(s).

--format simple|std|xml

Specifies the output format. std returns standard console output. xml returns extensible markup language format. simple returns a name=value type of output. For example, output similar to the following:

requestid= 
host=foobar 
locale=za_CH.UTF-8 
exitcode=0

--keep

Keep a copy of results on server after retrieving them.

--locale name

Locale to be used when a command is run. locale name can be one of the following values (case insensitive): en, en_us, zh, zh_cn, zh_tw, ja, ko, fr, and de. locale names are defined in: /opt/VRTSccg/config/locales.txt

--schedule timespec

Time in minutes or cron style specification. For more information, see crontab(1).

--nowait

When running direct (for example, with a --host) the calling semantics are to wait for the command to complete and print output. --nowait overrides that, in which case the user should use getresults to reap the process and results. When calling to a domain, or direct with a --schedule option, --nowait is the default behavior.

--wait

Wait for command to complete and print output.

NOTES

By default, gridcli resides in: /opt/VRTSccg/bin

Log files for the gridnode agent reside in: /var/vx/isis/vxisis33_gridnode.log

gridcli can be used interactively or with scripts. All operations supported by the grid are accessible via this command, which simply converts the argv parameters to calls to the grid. Some operations call to the gridcentral, others are dispatched directly to the gridnode. The pull option is an example of an option that calls directly, as there is no need to go through the central host to get this data.

A set of options identify the target agents for an operation. First, all of the operations require a domain name. Some have an additional --host name. This allows a user to run a command directly on one host, or to pull a file from a specified host.

The following shows an example usage pattern:

The gridcli command is invoked to push a file. The gridcli first transmits the file data to the gridcentral agent, which in turn schedules the distribution throughout the domain.
The gridcli command is invoked to run the file. Once again the request is first transmitted to the gridcentral agent, which in turn schedules the distribution of the execution request throughout the domain.
Results are produced by each execution on each host. The results (standard output and exit code) are returned to the gridcentral where they are stored.
The user examines the results using gridcli, which are downloaded from the gridcentral to the file system where the gridcli is running.
The request to push the file and run it remain in the gridcentral. As new hosts join the domain, the steps will be repeated for that host. The user can remove the file and the command as needed.

There are variations to this. Once pushed, the command can be run directly, not involving the gridcentral or its repository of results. This might be used in situations where the command configures something local to that node.

Another variation is that the command can also be run periodically. Here there is a choice in dealing with the command output. The data could be sent to the gridcentral, this might be used in situations where data is needed even if the system is down. Storage Foundation Manager periodically processes command output as a source for database transactions.

EXAMPLES

This section provides some usage examples for gridcli.

EXAMPLE 1:

The following command pushes a script (myscript) to a host (myhost):

gridcli --host myhost.mydomain.com push cmd localscript 
myscript

EXAMPLE 2:

The following command executes a script (myscript) with arguments (myarg1, myarg2) on a host (myhost):

gridcli --host myhost.mydomain.com run myscript --myarg1 
--myarg2

EXAMPLE 3:

The following command deletes a script (myscript) on a host (myhost):

gridcli --host myhost.mydomain.com delete file myscript

GRIDCLI (1M)

Table of contents