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 π«Ά-Fchassisfile β specifies the file with chassis in cluster. the default is/etc/opa/chassis. that's her home base π-Hchassis β specifies the list of chassis to execute the operation against. pick your faves, bestie π-Ppackages β specifies the filenames and directories of firmware images to install. okay so, the deets:- For directories specified, all
.pkg,.dpkg, and.spkgfiles 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. Defaultopafm.xml.
- For directories specified, all
-aaction β specifies the action for the supplied file. The default ispush.
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
-Ifm_bootstate β specifies thefmconfigandfmcontrolinstall 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.
-dupload_dir β specifies the directory to upload FM configuration files to. Default isuploads. π€-Sβ securely prompts for password for user on chassis. spy-movie-but-make-it-wholesome vibes π-ssecurityFiles β specifies the security files to install. Default is*.pem. For Chassisfmsecurityfiles, 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-Hand-Foption not supplied.CHASSIS_FILEβ File containing list of chassis, used in absence of-Fand-H.FF_MAX_PARALLELβ Maximum concurrent operations.FF_SERIALIZE_OUTPUTβ Serializes output of parallel operations (yesorno).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 whileopachassisadminis 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_tmpdirectories β contain temporary files that reflect tests in progress (or tests that got killed π).save_tempdirectory β 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. ππ¦
π¦ where this page comes from
- centos-stream 9: opa-fastfabric 1:10.12.1.0.6-1.el9 Β· BSD or GPLv2
- debian bookworm: opa-fastfabric 10.10.3.0.11-1+b1 Β· BSD-3-clause-top
- debian trixie: opa-fastfabric 10.10.3.0.11-1+b2 Β· BSD-3-clause-top
- opensuse-leap 16.0: opa-fastfabric 10.14.4.0.20-160000.3.2 Β· BSD-3-Clause OR GPL-2.0-only
- ubuntu jammy: opa-fastfabric 10.10.3.0.11-1ubuntu1 Β· BSD-3-clause-top
- ubuntu noble: opa-fastfabric 10.10.3.0.11-1ubuntu3 Β· BSD-3-clause-top
- ubuntu questing: opa-fastfabric 10.10.3.0.11-1ubuntu3
- ubuntu resolute: opa-fastfabric 10.10.3.0.11-1ubuntu4 Β· BSD-3-clause-top
- ubuntu stonking: opa-fastfabric 10.10.3.0.11-1ubuntu5 Β· BSD-3-clause-top
- Copyright 2015-2019, Intel Corporation
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms