1. Manuals
  2. Tumbleweed
  3. powerman
  4. redfishpower(8)

Scroll to navigation

redfishpower(8) System Manager's Manual redfishpower(8)

NAME

redfishpower - communicate with redfish service processors in parallel

SYNOPSIS

redfishpower <--hostname hostname(s) | --hostsfile file> [OPTIONS]

DESCRIPTION

redfishpower is a helper program for powerman which enables it to communicate with redfish service processors in parallel. It is run interactively by the powerman daemon.

OPTIONS

Set legal hostnames that redfishpower can communicate with. Host ranges are acceptable. Note that the maximum number of hosts that can be set simultaneously is limited by the file descriptor limit of the select(2) system call.
Set extra HEADER to use. Typically is Content-Type:application/json.
Authenticate with the specified user and password, specified in the form "user:pass". If specified on the command line, it cannot be set at the prompt with the "auth" command.
Set Redfish path for obtaining power status. Typically is redfish/v1/Systems/1.
Set default Redfish path for performing power on. Typically is redfish/v1/Systems/1/Actions/ComputerSystem.Reset.
Set default Redfish path for performing power off. Typically is redfish/v1/Systems/1/Actions/ComputerSystem.Reset.
Set default Redfish postdata for performing power on. Typically is {"ResetType":"On"}
Set default Redfish postdata for performing power off. Typically is {"ResetType":"ForceOff"}
Set message timeout, the timeout most notably associated with connection timeouts or name resolution timeouts. Default is 10 seconds. Note that this different than the command timeout specified by settimeout below. The latter is the total command timeout, which may involve multiple messages and a polling of power status.
Resolve host and pass IP address to libcurl instead of hostname. This works around a DNS race in libcurl versions less than 7.66. Users hitting the DNS race may see "Timeout was reached" errors. Note that all resolved host lookups will be permanently cached, it is assumed the IP address of hosts will never change.
Increase output verbosity. Can be specified multiple times.

INTERACTIVE COMMANDS

The following commands are accepted at the redfishpower> prompt:

Authenticate to the base URL with specified user and password, using ``basic'' HTTP authentication which sends the user and password over the network in plain text.
Set extra HEADER to use. Do not specify data to clear.
Set default path to obtain power status.
Set default path and optional post data to turn on plug.
Set default path and optional post data to turn off plug.
Associate a plug name with one of the hostnames specified on the command line, referred to by its zero origin index. Optionally set a parent to the plug, which must have its power status queried first. See HIERARCHY CONFIGURATION below for more details. Can be called multiple times to configure all possible plugs. In most cases the number of plugs should equal the number of indices. Multiple plugs can be mapped to a single host index, which is typically used along with plug substitution (see "setpath" command below).
Set path for specific plug power command ("stat", "on", "off") and optional post data. The plug name can be substituted into the URI path by specifying "{{plug}}" in the path.
Set command timeout in seconds.
Get power status of all plugs or specified subset of plugs.
Turn on all plugs or specified subset of plugs. Will return "ok" after confirmation "on" has completed.
Turn off all plugs or specified subset of plugs. Will return "ok" after confirmation "off" has completed.

UPDATING REDFISHPOWER DEVICE FILES

Users may often need to modify redfishpower device files for other systems, as URI paths may be slightly different.

To find the URI paths on your system, a good starting point is to use curl(1) to discover the correct paths at the following standard location. Note that the output can be easier to read if piped to jq(1), but that is optional.

# curl -s -u USER:PASS -k -X GET https://<node>/redfish/v1/Systems | jq

Information in the response will point you on how to dig further. Several paths the authors have seen include:

# curl -s -u USER:PASS -k -X GET https://<node>/redfish/v1/Systems/1

# curl -s -u USER:PASS -k -X GET https://<node>/redfish/v1/Systems/Node0

# curl -s -u USER:PASS -k -X GET https://<node>/redfish/v1/Systems/Self

Internally within redfishpower, an on or off command will not return until the on/off is confirmed to complete. i.e. stat returns the expected status.

This can sometimes take awhile and on some systems may push the timeout limit specified in the device file (typically 60 seconds). If necessary, it should be increased at the top of the specification file (via timeout) and the login section of device file (via settimeout).

Note that the powerman timeout should account for the combined time of an off and on for the cycle operation.

HIERARCHY CONFIGURATION

Users of redfishpower can configure power control dependencies within the hosts specified on the command line. This is typically necessary for bladed environments where a chassis must be powered on before any power control operations can be done on a blade. For example, assume a chassis that has two blades, and each blade has two nodes underneath it. These hosts might be configured via the --hostnames option like --hostnames chassis,blades[0-1],nodes[0-3] .

The power control dependency hierarchy could be configured in redfishpower via:



      script login {


              send "setplugs Root 0\n"


              expect "redfishpower> "


              send "setplugs Parent[0-1] [1-2] Root\n"


              expect "redfishpower> "


              send "setplugs Leaf[0-1] [3-4] Parent0\n"


              expect "redfishpower> "


              send "setplugs Leaf[2-3] [5-6] Parent1\n"


              expect "redfishpower> "


      }

In the above example the plugname "Root" is used for the root node (index 0 of configured hosts), "Parent[0-1]" is used for the blades (the indexes 1-2), the nodes are assigned the plugnames "Leaf[0-3]" (index 3-6). "Root" is assigned no parent, "Parent[0-1]" are assigned parent "Root", and leaves are assigned parents of "Parent0" or "Parent1" depending on the node.

Redfishpower will handle the following when dealing with power control dependencies:

When checking power status, the status of a parents/ancestors will always be checked first. If an ancestor is "off", "unknown", or "error", all descendants will be defined as "off", "unknown", or "error" respectively. If all ancestors are "on", the power status of the targeted children can be checked accordingly.

When powering on, the status of parents/ancestors will be checked first. If an ancestor is not "on", descendants cannot be powered on and an appropriate message is output as a result. If all ancestors are "on", the power on to the child can be completed.

When powering off, the status of parents/ancestors will be checked first. If all ancestors are "on", the power off to the child can be completed. If any ancestor is "off", the power off is assumed to be successful.

Note that redfishpower does not allow both parents and children to be powered on at the same time. This "phased" power on is highly dependent on hardware implementation and has shown itself to be unreliable. However both parents and children can be powered off. When the ancestor completes its power off, it is assumed all children ared powered off as well.

FILES

/usr/sbin/redfishpower
/etc/powerman/powerman.conf

ORIGIN

PowerMan was originally developed by Andrew Uselton on LLNL's Linux clusters. This software is open source and distributed under the terms of the GNU GPL.

SEE ALSO

powerman(1), powermand(8), plmpower(8), vpcd(8), powerman.conf(5), powerman.dev(5).

http://github.com/chaos/powerman

1 October 2021 powerman-2.4.4