redfishpower(8)

redfishpower 💖 (section 8, bestie)

okay so. you opened the man page for redfishpower, part of the System Manager's Manual, and honestly? iconic choice. this is the girlies-who-run-clusters page. let's get into it ✨

---

✨ NAME ✨

redfishpower — talk to redfish service processors in parallel 🦋

---

🌸 SYNOPSIS 🌸

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

---

💅 DESCRIPTION 💅

so redfishpower is a little helper program for powerman that lets it go chat with redfish service processors all at once, in parallel, no waiting in line 💁‍♀️. it gets run interactively by the powerman daemon — so like, the daemon is the one holding the aux cord here. 🎀

---

⭐ OPTIONS ⭐

• -h, --hostname hostname(s) — set the legal hostnames that redfishpower is allowed to talk to. host ranges are totally acceptable, slay. 🫶 heads up tho: the max number of hosts you can set at the same time is limited by the file descriptor limit of the select(2) system call. no cap.
• -H, --header string — set an extra HEADER to use. typically it's Content-Type:application/json. 💌
• -A, --auth user:pass — authenticate with the given user and password, written in the form "user:pass". 🚨 if you set it on the command line, you cannot also set it at the prompt with the auth command. pick a lane bestie.
• -S, --statpath string — set the Redfish path for grabbing power status. typically redfish/v1/Systems/1. 📊
• -O, --onpath string — set the default Redfish path for doing a power on. typically redfish/v1/Systems/1/Actions/ComputerSystem.Reset. 🔥
• -F, --offpath string — set the default Redfish path for doing a power off. typically redfish/v1/Systems/1/Actions/ComputerSystem.Reset. 💀
• -P, --onpostdata string — set the default Redfish postdata for performing power on. typically {"ResetType":"On"}. 🌞
• -G, --offpostdata string — set the default Redfish postdata for performing power off. typically {"ResetType":"ForceOff"}. 🌙
• -m, --message-timeout seconds — set the message timeout, which is the timeout most notably associated with connection timeouts or name resolution timeouts. default is 10 seconds. ⏰ and yes, this is different than the command timeout specified by settimeout below — that one is the total command timeout, which can involve multiple messages and a polling of power status. two different timers, two different vibes.
• -o, --resolve-hosts — resolve the host and pass the IP address to libcurl instead of the hostname. this works around a DNS race in libcurl versions less than 7.66. if you're hitting that DNS race you may see "Timeout was reached" errors. 😭 note that all resolved host lookups will be permanently cached — it's assumed the IP address of hosts will never change. so like, forever-forever.
• -v, --verbose — increase output verbosity. can be specified multiple times. 📢📢📢

---

🎀 INTERACTIVE COMMANDS 🎀

these are the commands accepted at the redfishpower> prompt (yes, the prompt is main character energy):

• auth user:pass — authenticate to the base URL with the specified user and password, using ``basic'' HTTP authentication, which sends the user and password over the network in plain text. 🙈 (plain text! over the network! know that before you do it, bestie.)
• setheader [string data] — set an extra HEADER to use. don't specify data if you want to clear it.
• setstatpath <path> — set the default path to obtain power status.
• setonpath <path> [postdata] — set the default path and optional post data to turn on plug. 💡
• setoffpath <path> [postdata] — set the default path and optional post data to turn off plug. 🌑
• setplugs plugnames hostindices [parentplug] — 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 the "setpath" command below).
• setpath <plugnames> <cmd> <path> [postdata] — set the path for a 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. 🪄
• settimeout <seconds> — set command timeout in seconds.
• stat [plugs] — get the power status of all plugs, or a specified subset of plugs.
• on [plugs] — turn on all plugs, or a specified subset of plugs. will return "ok" after confirmation "on" has completed. ✅
• off [plugs] — turn off all plugs, or a specified subset of plugs. will return "ok" after confirmation "off" has completed. ✅

---

🦋 UPDATING REDFISHPOWER DEVICE FILES 🦋

ngl, users often need to modify redfishpower device files for other systems, because URI paths can be slightly different from box to box. it's giving "every server is unique and special." 💫

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 part 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 the device file (via settimeout). ⏳

note that the powerman timeout should account for the combined time of an off and an on for the cycle operation. like, do the math bestie, both of those take time. 😮‍💨

---

👑 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. 💀 (yes, "ared." we don't fix the ancestors' typos, we respect them.)

---

🍓 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

---

and that's the whole page bestie, you ate that 🫶 this was powerman-2.4.4, dated 1 October 2021, and it's the redfishpower(8) page — go forth and parallel-power your service processors, mwah 💖✨🎀