opachassisadmin(8)

πŸ’– opachassisadmin(8) πŸ’–

okay bestie, welcome to opachassisadmin from the IFSFFCLIRG manual pages, and no cap this is a big one. it's a Switch tool, and it does a whole bunch of multi-step chassis glow-up operations β€” initial chassis setup, firmware upgrades, chassis reboot, and a bunch of other stuff. she's the main character of chassis management fr fr. πŸ’…


✨ NAME ✨

opachassisadmin β€” (Switch) Performs a number of multi-step chassis initialization and verification operations, including initial chassis setup, firmware upgrades, chassis reboot, and others. like she literally does the whole routine, skincare and all πŸ§–


🌸 Syntax 🌸

opachassisadmin [-c] [-F  chassisfile] [-H 'chassis'] [-P  packages]

[-a  action] [-I  fm_bootstate] [-S] [-d  upload_dir] [-s
securityfiles]

operation ...

πŸŽ€ Options πŸŽ€

  • --help β€” gives you the full help text. the whole lore drop. ✨
  • -c β€” overwrites the result files from any previous run before starting this run. fresh slate energy, we love a clean start 🫢
  • -F chassisfile β€” specifies the file with chassis in cluster. the default is /etc/opa/chassis. that's her home base 🏠
  • -H chassis β€” specifies the list of chassis to execute the operation against. pick your faves, bestie πŸ’–
  • -P packages β€” specifies the filenames and directories of firmware images to install. okay so, the deets:
    • For directories specified, all .pkg, .dpkg, and .spkg files in directory tree are used. shell wild cards may also be used within quotes.
    • For fmconfig, filename of FM config file is used.
    • For fmgetconfig, filename to upload to is used. Default opafm.xml.
  • -a action β€” specifies the action for the supplied file. The default is push.

For chassis upgrade:

  • push β€” Ensures firmware is in primary or alternate.
  • select β€” Ensures firmware is in primary.
  • run β€” Ensures firmware is in primary and running.

For chassis fmconfig:

  • push β€” Ensures the configuration file is in chassis.
  • run β€” After push, restarts FM on master, stops on secondary.
  • runall β€” After push, restarts FM on all management modules.

For chassis fmcontrol:

  • stop β€” Stops FM on all management modules.
  • run β€” Ensures FM running on master, stopped on secondary.
  • runall β€” Ensures FM running on all management modules.
  • restart β€” Restarts FM on master, stops on secondary.
  • restartall β€” Restarts FM on all MM.

For chassis fmsecurityfiles:

  • push β€” Ensures FM security files are in chassis.
  • restart β€” After push, restarts FM on master, stop on slave.
  • restartall β€” After push, restarts FM on all MM
  • -I fm_bootstate β€” specifies the fmconfig and fmcontrol install options.
    • disable β€” Disables FM start at chassis boot.
    • enable β€” Enables FM start on master at chassis boot.
    • enableall β€” Enables FM start on all MM at chassis boot.
  • -d upload_dir β€” specifies the directory to upload FM configuration files to. Default is uploads. πŸ“€
  • -S β€” securely prompts for password for user on chassis. spy-movie-but-make-it-wholesome vibes πŸ”
  • -s securityFiles β€” specifies the security files to install. Default is *.pem. For Chassis fmsecurityfiles, filenames/directories of security files to install. For directories specified, all security files in directory tree are used. Shell wildcards may also be used within quotes.

For Chassis fmgetsecurityfiles, filename to upload to. Default is *.pem

  • operation β€” specifies the operation to perform. Can be one or more of:
    • reboot β€” Reboots chassis, ensures they go down and come back.
    • configure β€” Runs wizard to perform chassis configuration.
    • upgrade β€” Upgrades install of all chassis.
    • getconfig β€” Gets basic configuration of chassis.
    • fmconfig β€” FM configuration operation on all chassis.
    • fmgetconfig β€” Fetches FM configuration from all chassis.
    • fmcontrol β€” Controls FM on all chassis.
    • fmsecurityfiles β€” FM security files operation on all chassis.
    • fmgetsecurityfiles β€” Fetches FM security files from all chassis.

For more information on the operations that can be performed, see Operation Details (she's right down there, bestie πŸ‘‡)


🌈 Example 🌈

opachassisadmin -c reboot

opachassisadmin -P /root/ChassisFw4.2.0.0.1 upgrade

opachassisadmin -H 'chassis1 chassis2' reboot

CHASSIS='chassis1 chassis2' opachassis_admin reboot

opachassisadmin -a run -P '*.pkg' upgrade

πŸ¦‹ Environment Variables πŸ¦‹

The following environment variables are also used by this command:

  • CHASSIS β€” List of chassis, used if -H and -F option not supplied.
  • CHASSIS_FILE β€” File containing list of chassis, used in absence of -F and -H.
  • FF_MAX_PARALLEL β€” Maximum concurrent operations.
  • FF_SERIALIZE_OUTPUT β€” Serializes output of parallel operations (yes or no).
  • FF_TIMEOUT_MULT β€” Multiplier for all timeouts associated with this command. Used if the systems are slow for some reason. (slow systems deserve patience too πŸ’œ)
  • UPLOADS_DIR β€” Directory to upload to, used in absence of -d.

⭐ Operation Details ⭐

(Switch) All chassis operations log into the chassis as chassis user admin. Intel recommends using the -S option to securely prompt for a password, in which case the same password is used for all chassis. Alternately, the password may be put in the environment or the opafastfabric.conf file using FF_CHASSIS_ADMIN_PASSWORD.

All versions of Intel(R) Omni-Path Switch 100 Series firmware permit SSH keys to be configured within the chassis for secure password-less login. In this case, there is no need to configure a FF_CHASSIS_ADMIN_PASSWORD; and, FF_CHASSIS_LOGIN_METHOD can be SSH. Refer to the Intel(R) Omni-Path Fabric Suite FastFabric User Guide

for more information.

πŸ”₯ upgrade

Upgrades the firmware on each chassis or slot specified. The -P option selects a directory containing .pkg files or provides an explicit list of .pkg files for the chassis and/or slots. The -a option selects the desired minimal state for the new firmware. For each chassis and/or slot selected for upgrade, the .pkg file applicable to that slot is selected and used. If more than one .pkg file is specified of a given card type, the operation is undefined.

⚠️ undefined behaviour alert! more than one .pkg file for a given card type and she simply does not know what happens. do not test her, bestie 😭

The upgrade is intelligent and does not upgrade chassis that already have the desired firmware in the desired state (as specified by -a). she's smart like that πŸ’…

When the -a option specifies run, chassis that are not already running the desired firmware are rebooted. By selecting the proper FF_MAX_PARALLEL value, a rolling upgrade or a parallel upgrade may be accomplished. In most cases, a parallel upgrade is recommended for expediency.

For more information about chassis firmware, refer to the Intel(R) Omni-Path Fabric Switches GUI User Guide

and Intel(R) Omni-Path Fabric Switches Release Notes

🌸 configure

Runs the chassis setup wizard, which asks a series of questions. Once the wizard has finished prompting for configuration information, all the selected chassis are configured through the CLI interface according to the responses. The following options may be configured for all chassis:

  • Syslog server IP address, TCP/UDP port number, syslog facility code, and the chassis LogMode.
  • NTP server
  • Local time zone
  • Link CRC Mode
  • Link width supported
  • Node description

it's giving ✨interview✨ but for your chassis. iconic.

πŸ’« reboot

Reboots the given chassis and ensures they go down and come back up by pinging them during the reboot process.

By selecting the proper FF_MAX_PARALLEL value, a rolling reboot or a parallel reboot may be accomplished. In most cases, a parallel upgrade is recommended for expediency.

πŸŽ€ getconfig

Retrieves basic information from a chassis such as syslog, NTP configuration, timezone info, Link CRC Mode, Link Width, and node description. the vibe check of chassis info 🌈

πŸ¦‹ fmconfig

Updates the Fabric Manager configuration file on each chassis specified. The -P option selects a file to transfer to the chassis. The -a option selects the desired minimal state for the new configuration and controls whether the FM is started/restarted after the file is updated. The -I option can be used to configure the FM start at boot for the selected chassis.

🧚 fmgetconfig

Uploads the FM configuration file from all selected chassis. The file is uploaded to the selected uploads directory. The -P option specifies the desired destination filename within the uploads directory.

πŸ‘‘ fmcontrol

Allows the FM to be controlled on each chassis specified. The -a option selects the desired state for the FM.

The -I option configures the FM start at boot for the selected chassis.

πŸ” fmsecurityfiles

Updates the FM security files on each chassis specified. The -s option selects file(s) to transfer to the chassis. The -a option selects the desired minimal state for the new security files. In this release, push is the only supported action.

πŸ’€ only push works here. the other actions are just... not invited to the party.

πŸ“€ fmgetsecurityfiles

Uploads the FM security files from all selected chassis. The files are uploaded to the selected uploads directory. The -s option specifies the desired destination filename within the uploads directory.


πŸ“ Logging πŸ“

opachassisadmin provides detailed logging of its results. During each run, the following files are produced:

  • test.res β€” This file is appended with summary results of run.
  • test.log β€” This file is appended with detailed results of run.
  • save_tmp/ β€” This file is contains a directory per failed test with detailed logs.
  • test_tmp*/ β€” This file contains the intermediate results while the test is running.

The -c option removes all log files.


and that's part one, bestie β€” she keeps going, so stay tuned πŸ’–

πŸ”‘ ssh Keys πŸ”‘

Okay bestie, listen up, because this one is a vibe saver πŸ”₯

When you're running operations against a chassis, Intel recommends setting up SSH keys. Do it. It's the moment, it's the serve, it's the whole point.

But say you haven't set up SSH keys (no shame, it happens πŸ™ˆ)? Then every single chassis must be configured with the same admin password. All of them. Same one. No exceptions, no "well this one's different", none of that.

In that case, Intel recommends you use the -S option. And why is -S so iconic? Because it avoids the need to keep the password in configuration files. Which is the difference between "slay" and "my password is just sitting there in a file, in the open, living its truth" πŸ’€ Keep it out of the config files, bestie. Use -S.


✨ Results ✨

So the results from opachassisadmin come organized into a whole little hierarchy: test suites, test cases, and test items. Let me break it down because it's giving nesting doll energy πŸͺ†

  • A given run of opachassisadmin = a single test suite. That's the whole thing. One run, one suite.
  • Within a test suite, there are multiple test cases β€” and typically it's one test case per chassis being operated on.
  • Some of the more complex operations might have multiple test items per test case.
  • Each test item represents a major step in the overall test case.

Got it? Suite β†’ cases β†’ items. Crown, princess, little princess. πŸ‘‘


πŸ—‚οΈ the files it makes (iykyk)

Every single opachassisadmin run appends to test.res and test.log, and also creates temporary files in test_tmp$PID in the current directory. Yes, $PID is literally the process ID in there. Cute, right?

Here's what each one is doing:

  • test.res β€” gives you an overall summary of the operations performed and their results. And good news: the exact same info is also displayed while opachassisadmin is executing, so you're not staring at a blank terminal wondering if it's alive 🫢
  • test.log β€” the detailed one. It contains detailed information about what was performed, including the specific commands executed and the resulting output. Receipts. Full receipts. πŸ“
  • test_tmp directories β€” contain temporary files that reflect tests in progress (or tests that got killed πŸ™ˆ).
  • save_temp directory β€” logs for any failures get logged here, with a directory per failed test case.
Heads up bestie: if the same test case fails more than once, save_temp retains the information from the first failure. Not the latest one. The first one. So don't be confused when you go looking.

Also, subsequent runs of opachassisadmin get appended to test.log β€” nothing gets wiped on its own. So Intel recommends you review your failures and use the -c option to remove old logs before running opachassisadmin again. Clean your room before you start a new project, basically. 🧹✨


πŸƒβ™€οΈ parallel by default, no cap

opachassisadmin implicitly performs its operations in parallel. It just does. It's that girl.

But like the other tools, you can export FF_MAX_PARALLEL to change the degree of parallelism. And what's the default, you ask?

1000 parallel operations is the default. πŸ’…

A thousand. At once. Main character energy fr fr.


And that's the whole page, bestie πŸŽ€ this one came to you from Intel Corporation, copyright 2015-2019, filed under opachassisadmin(8) β€” section 8, system administration, exactly where it belongs. Go forth, set up those SSH keys, and keep your passwords out of your config files. Mwah. πŸ’–πŸ¦‹