Skip to main content

The Out-of-Band Wrangler

Copr build status Codecov Container image on Quay Tox Lint License: GPL v3 Code style: black

Badfish

Badfish is a Redfish-based API tool for managing bare-metal systems via the Redfish API

You can read more about badfish at the QUADS website.

Scope

Right now Badfish is focused on managing Dell, SuperMicro and HPE systems, but can potentially work with any system that supports the Redfish API. Functionality may vary depending on the vendor Redfish implementation with Dell systems having the most functionality.

We're mostly concentrated on programmatically enforcing interface/device boot order to accommodate TripleO based OpenStack and OpenShift deployments while simultaneously allowing easy management and provisioning of those same systems via The Foreman. Badfish can be useful as a general standalone, unified vendor IPMI/OOB tool however as support for more vendors is added.

Features

  • Toggle and save a persistent interface/device boot order on remote system
  • Support for BIOS and EFI modes for interface/device boot operations
  • Perform one-time boot to a specific interface, mac address or type listed for PXE booting
  • Enforce a custom interface boot order with rack/U-location/blade overrides
  • Check current boot order
  • Power on/off/cycle, reboot and query power state and power consumption
  • Reset BMCs (Dell iDRAC --racreset, Supermicro/HPE --bmc-reset)
  • BIOS factory reset
  • View, check and clear BMC job queues
  • Check, mount, unmount and boot to virtual media
  • Dell OpenManage OS deployment remote ISO support (check, boot, detach)
  • Check and set SRIOV mode (Dell only)
  • Get and set BIOS attributes, including bulk changes and BIOS/UEFI mode switching
  • Set and remove BIOS passwords
  • Get and set NIC attributes via FQDD (Dell only)
  • Take a remote screenshot of server KVM console activity (Dell only)
  • Get firmware inventory and delta between two hosts
  • Obtain limited hardware information (CPU, Memory, Interfaces, GPU, Serial/Service Tag)
  • Export and import server configuration profiles with Dell iDRAC SCP
  • Support tokenized authentication
  • Use environment variables for credentials
  • Bulk actions via plain text file with list of hosts for parallel execution
  • JSON or YAML formatted output
  • Request timeout, retry and TLS certificate verification controls
  • Logging to a specific path
  • Built-in Redfish emulator (mock iDRAC) for development and testing
  • Containerized Badfish image

Requirements

  • (Dell) iDRAC7,8,9 or newer
  • (Dell) Firmware version 2.60.60.60 or higher
  • Any Redfish IPMI 2.0 support on non-Dell systems
  • BMC administrative account
  • Python >= 3.10 or podman as a container.
  • python3-devel >= 3.10 (If using standalone or RPM package below).

Setup

Badfish RPM package

dnf copr enable quadsdev/badfish  -y
dnf install badfish -y

Active RPM releases:

  • All current Fedora releases
  • Some older Fedora releases, check the RPM releases here

[!NOTE] RHEL and derivatives (Rocky, Alma, etc) should use containers instead due to missing libs/dependencies.

Badfish Standalone CLI

git clone https://github.com/quadsproject/badfish && cd badfish
python3 -m venv bf
source bf/bin/activate
python3 -m pip install --upgrade build
python3 -m build
python3 -m pip install dist/badfish-*.tar.gz

[!TIP] This will allow Badfish to be called from the terminal via the badfish command

This requires python3-devel if you see errors about missing Python.h.

Badfish Container

Perhaps the easiest way to run Badfish is with Podman, you can see more usage details below on using the Badfish container with Podman. You can substitute Docker for Podman as well though not all functionality may be actively tested as we prefer Podman.

podman pull quay.io/quads/badfish

Run straight from the repository

Running Badfish straight from a git checkout is the least recommended way to use it, but you can if you prefer. You need Python >= 3.10 and all the libraries from requirements.txt installed, either in a virtualenv or as system packages:

  • With a virtualenv:
git clone https://github.com/quadsproject/badfish && cd badfish
python3 -m venv bf
source bf/bin/activate
pip install --upgrade pip
pip install -r requirements.txt
  • Or with RPM system packages (or satisfied by your package manager/distribution):
sudo dnf install python3-pyyaml python3-aiohttp python3-async-lru python3-rich python3-setuptools python3-build openssl

You can then invoke Badfish straight from the repository by pointing PYTHONPATH at the source tree:

PYTHONPATH="./src" python3 src/badfish/main.py -h
PYTHONPATH="./src" python3 src/badfish/main.py -H mgmt-your-server.example.com --power-state

[!NOTE] openssl is only needed by the Redfish emulator to generate its TLS certificate, and python3-setuptools/python3-build are only needed to build or install the package. The badfish console command is only available after a full install (see Badfish Standalone CLI).

Usage

Badfish can be consumed in several ways after successful installation. Either via the standalone cli tool or as a python library. For an extensive use of the cli tool check the Common Operations section of this file.

[!TIP] Badfish operates optionally against a YAML configuration file to toggle between key:value pair sets of boot interface/device strings. You just need to create your own interface config that matches your needs to easily swap/save interface/device boot ordering or select one-time boot devices.

As Python Library

If Badfish has been properly installed in the system (RPM package install, setuptools), then the library should be available under your python path therefore it can be imported as a python library to your python project.

from badfish.main import badfish_factory

badfish = await badfish_factory(
    _host=_oob_mgmt,
    _username=_username,
    _password=_password,
)
await badfish.get_boot_devices()
success = await badfish.boot_to(badfish.boot_devices[0]['Name'])
if success:
    print("Change boot device success")
result = await badfish.reboot_server()
if not result:
    print("Failed to reboot system")

[!IMPORTANT] Badfish relies heavily on asyncio for executing multiple tasks. If you will be using badfish from outside an async function you will have to provide an async event loop and run via run_until_complete

Via Podman

Badfish happily runs in a container image using Podman or Docker (likely, but not actively tested).

podman pull quay.io/quads/badfish
export BADFISH_USERNAME="my_username"
export BADFISH_PASSWORD="my_password"
podman run -it --rm --dns 1.2.3.4 quay.io/quads/badfish -H mgmt-host01.example.com --reboot-only

If you want to pass your user/pass variables only in podman:

BADFISH_USERNAME=my_username BADFISH_PASSWORD=my_password \
   podman run -it --env BADFISH_USERNAME --env BADFISH_PASSWORD --rm --dns 1.2.3.4 \
   quay.io/quads/badfish -H mgmt-host01.example.com --reboot-only

[!IMPORTANT]

If you are running Badfish against a host inside a VPN to an address without public resolution you must specify your VPN DNS server ip address with --dns

If you would like to use a different file for config/idrac_interfaces.yml you can map a volume to your modified config with -v idrac_interfaces.yml:config/idrac_interfaces.yml:Z

[!TIP] If you want to run any actions that would have output files like --screenshot you can map the container root volume to a directory on your local machine where you would like to have those files stored like -v /tmp/screens:/badfish:Z

[!IMPORTANT] When mapping a volume to a container make sure to use the :Z suffix for appropiate labeling

Via Virtualenv

Virtualenv is a wonderful tool to sandbox running Python applications or to separate Python versions of components from your main system libaries. Unfortunately it can be problematic with running Badfish directly from the Git repo inside a virtualenv sandbox.

While we strongly recommend using the podman method of calling Badfish inside a virtual environment you can still do it directly from the repository via virtualenv but you would need to prepend the call to Badfish with the setting of the PYTHONPATH environment variable pointing at the path of your Badfish repository.

virtualenv venv
source venv/bin/activate
pip install --upgrade pip
pip install -r requirements.txt
  • You'll need to set PYTHONPATH to the BADFISHREPO/src to run this way:
PYTHONPATH="./src" python3 src/badfish/main.py -h

Via RPM System Package

If you choose to install Badfish via RPM package then it'll be located in /usr/bin/badfish and you don't need to do much else beyond know the correct command syntax for your required operations.

[!NOTE] If you plan on using the idrac_interfaces.yml file to further customize or define pre-made boot orders you'll want to model your own based on the repo example file.

This file serves as an example but is specific to our internal environments so you'd most likely want to modify it to match your environment and naming conventions.

You can always retrieve our example idrac_interfaces.yml file via:

curl  https://raw.githubusercontent.com/quadsproject/badfish/master/config/idrac_interfaces.yml --output idrac_interfaces.yml

Common Operations

Use Environment Variables for Secrets

[!IMPORTANT] While you can pass -u and -p for user and password env variables are more secure.

export BADFISH_USERNAME="my_username"

export BADFISH_PASSWORD="my_password"

Enforcing an OpenStack Director-style interface order

In our performance/scale R&D environments TripleO-based OpenStack deployments require a specific 10/25/40GbE NIC to be the primary boot device for PXE, followed by disk, and then followed by the rest of the interfaces.

badfish -H mgmt-your-server.example.com  -i config/idrac_interfaces.yml -t director

Enforcing a Foreman-style interface order

Foreman and Red Hat Satellite (as of 6.x based on Foreman) require managed systems to first always PXE from the interface that is Foreman-managed (DHCP/PXE). If the system is not set to build it will simply boot to local disk. In our setup we utilize a specific NIC for this interface based on system type.

badfish -H mgmt-your-server.example.com  -i config/idrac_interfaces.yml -t foreman

Enforcing a Custom interface order

Badfish allows you to supply your own interface order type in addition to director and foreman modes as defined in idrac_interfaces.yml

  • Supply your own distinct string in the first part of the key value (split by _)
  • Refer to it via the string name
  • Consequently host type overrides can also be leveraged

We will use the custom interface order called ocp5beta as an example.

Example any system you want to boot with a certain custom interface order.

ocp5beta_fc640: NIC.Slot.2-4,NIC.Slot.2-1,NIC.Slot.2-2,NIC.Slot.2-3

Example a rack of systems you want to boot with a certain custom interface order.

ocp5beta_f21_fc640: NIC.Slot.2-4,NIC.Slot.2-1,NIC.Slot.2-2,NIC.Slot.2-3

Example a specific system you want to boot with a certain custom interface order

ocp5beta_f21_h23_fc640: NIC.Slot.2-4,NIC.Slot.2-1,NIC.Slot.2-2,NIC.Slot.2-3

Now you can run Badfish against the custom interface order type you have defined, refer to the custom overrides on further usage examples.

badfish --host-list /tmp/hosts -u root -p password -i config/idrac_interfaces.yml -t ocp5beta

Forcing a one time boot to a specific device

To force systems to perform a one-time boot to a specific device on the next subsequent reboot you can use the --boot-to option and pass as an argument the device you want the one-time boot to be set to. This will change the one time boot BIOS attributes OneTimeBootMode and OneTimeBootSeqDev and on the next reboot it will attempt to PXE boot or boot from that interface string. You can obtain the device list via the --check-boot directive below.

badfish -H mgmt-your-server.example.com --boot-to NIC.Integrated.1-3-1

Forcing a one time boot to a specific mac address

To force systems to perform a one-time boot to a specific mac address on the next subsequent reboot you can use the --boot-to-mac option and pass as an argument the device mac address for a specific NIC that you want the one-time boot to be set to. This will change the one time boot BIOS attributes OneTimeBootMode and OneTimeBootSeqDev and on the next reboot it will attempt to PXE boot or boot from that interface.

badfish -H mgmt-your-server.example.com --boot-to-mac A9:BB:4B:50:CA:54

Forcing a one time boot to a specific type

To force systems to perform a one-time boot to a specific type on the next subsequent reboot you can use the --boot-to-type option and pass as an argument the device type, as defined on the interfaces yaml, that you want the one-time boot to be set to. For this action you must also include the path to your interfaces yaml. This will change the one time boot BIOS attributes OneTimeBootMode and OneTimeBootSeqDev and on the next reboot it will attempt to PXE boot or boot from the first interface defined for that host type on the interfaces yaml file.

badfish -H mgmt-your-server.example.com  -i config/idrac_interfaces.yml --boot-to-type foreman

Note --boot-to, --boot-to-type, and --boot-to-mac require you to manually perform a reboot action, these simply just batch what the system will boot to on the next boot. For this you can use either --power-cycle or --reboot-only.

Forcing a one-time boot to PXE

To force systems to perform a one-time boot to PXE, simply pass the --pxe flag to any of the commands above, by default it will pxe off the first available device for PXE booting. This is equivalent to the ipmitool command chassis bootdev pxe options=persistent and should be used with SuperMicro/HPE systems or non-Dell systems that support a minimal IPMI 2.0 specification.

For Dell systems please use either --boot-to, --boot-to-mac or --boot-to-type for temporary PXE to a specific interface or change the boot order permanently to achieve your desired effect.

badfish -H mgmt-your-server.example.com  -i config/idrac_interfaces.yml --pxe

Rebooting a system

In certain cases you might need to only reboot the host, for this case we included the --reboot-only flag which will force a GracefulRestart on the target host. Note that this option is not to be used with any other option.

badfish -H mgmt-your-server.example.com --reboot-only

Power cycling a system

For a hard reset you can use --power-cycle flag which will run a ForceOff instruction on the target host. Note that this option is not to be used with any other option.

badfish -H mgmt-your-server.example.com --power-cycle

Power State Control

You can also turn a server on or off by using options --power-on and --power-off respectively.

badfish -H mgmt-your-server.example.com --power-on

Check Power State

For checking the current power state of a server you can run badfish with the --power-state option.

badfish -H mgmt-your-server.example.com --power-state

Partial Output:

- INFO     - Power state for mgmt-your-server.example.com: On

Get Power Consumed

This displays the current power usage for Dell / Supermicro server(s).

badfish -H mgmt-your-server.example.com --get-power-consumed

Partial Output:

- INFO     - Current watts consumed: 213

Resetting Dell iDRAC

For the replacement of racadm racreset, the optional argument --racreset was added. When this argument is passed to badfish, a graceful restart is triggered on the iDRAC itself.

badfish -H mgmt-your-server.example.com --racreset
  • You can also specify --racreset --wait and Badfish will poll the iDrac for it to complete and keep you updated on progress.

[!NOTE] Dell specific command, for Supermicro servers there is an equivalent of --bmc-reset

Resetting BMC

For the replacement of ipmitool bmc reset or ipmiutil reset, the optional argument --bmc-reset was added. When this argument is passed to badfish, a graceful restart is triggered on the BMC itself.

badfish -H mgmt-your-server.example.com --bmc-reset

[!NOTE] Supermicro specific command, for Dell servers there is an equivalent of --racreset

BIOS factory reset

[!CAUTION] Use this carefully, vendor defaults differ and may be disruptive. Do not use this in the Scale Lab or ALIAS.

You can restore BIOS default settings by calling Badfish with the option --factory-reset.

badfish -H mgmt-your-server.example.com --factory-reset

Check current boot order

To check the current boot order of a specific host you can use the --check-boot option which will return an ordered list of boot devices. Additionally you can pass the -i option which will in turn print on screen what type of host does the current boot order match as those defined on the interfaces yaml.

badfish -H mgmt-your-server.example.com  -i config/idrac_interfaces.yml --check-boot

Toggle boot device

If you would like to enable or disable a boot device you can use --toggle-boot-device argument which takes the device name as input and will toggle the Enabled state from True to False and vice versa.

badfish -H mgmt-your-server.example.com --toggle-boot-device NIC.Integrated.1-3-1

Variable number of retries

At certain points during the execution of badfish the program might come across a non responsive resources and will automatically retry to establish connection. We have included a default value of 30 retries after failed attempts but this can be customized via the --retries optional argument which takes as input an integer with the number of desired retries.

badfish -H mgmt-your-server.example.com  -i config/idrac_interfaces.yml -t foreman --retries 20

Set request timeout

By default every Redfish REST call waits up to 120 seconds to answer (TIMEOUT in src/badfish/config.py). You can override that with the --timeout option, which takes a positive integer number of seconds.

badfish -H mgmt-your-server.example.com --power-state --timeout 60

Skip TLS certificate verification

For development and testing against hosts that present self-signed certificates, including the bundled Redfish emulator, you can pass --insecure to disable SSL/TLS certificate verification. Do not use this flag with production BMCs.

badfish -H mgmt-your-server.example.com --insecure --power-state

Firmware inventory

If you would like to get a detailed list of all the devices supported by the BMC you can run badfish with the --firmware-inventory option which will return a list of devices with additional device info.

badfish -H mgmt-your-server.example.com --firmware-inventory

Delta of firmware inventories

If you would like to get a delta between firmware inventories of two servers, you can do so with the --delta option. This option takes a second host address as its argument. Only the firmware that's on both servers and has different versions will get displayed.

badfish -H mgmt-your-server.example.com --firmware-inventory --delta mgmt-your-other-server.example.com

Clear Job Queue

If you would like to clear all the jobs that are queued on the remote BMC you can run badfish with the --clear-jobs option which query for all active jobs in the job queue and will post a request to clear the queue.

badfish -H mgmt-your-server.example.com --clear-jobs

You can also force the clearing of Dell iDRAC job queues by passing the --force option.

badfish -H mgmt-your-server.example.com --clear-jobs --force

List Job Queue

If you would like to list all active jobs that are queued on the remote BMC you can run badfish with the --ls-jobs option which query for all active jobs in the job queue and will return a list with all active items.

badfish -H mgmt-your-server.example.com --ls-jobs

Check Job Status

If you would like to the status of an existing LifeCycle controller job you can run badfish with the --check-job option and passing the job id which can be obtained via --ls-jobs. This will return a detail of the specific job with status and percentage of completion.

badfish -H mgmt-your-server.example.com --check-job JID_340568202796

Set Bios Password

If you would like to set the bios password you can run badfish with the --set-bios-password option and passing the new password with --new-password. If a password is already set you must pass this with --old-password otherwise optional.

badfish -H mgmt-your-server.example.com -u root --set-bios-password --new-password new_pass --old-password old_pass

Remove Bios Password

If you would like to remove the bios password you can run badfish with the --remove-bios-password option and passing the existing password with --old-password.

badfish -H mgmt-your-server.example.com -u root --remove-bios-password --old-password old_pass

List Network Interfaces

For getting a list of network interfaces with individual metadata for each you can run badfish with the --ls-interfaces option.

badfish -H mgmt-your-server.example.com --ls-interfaces

List Memory

For getting a detailed list of memory devices you can run badfish with the --ls-memory option.

badfish -H mgmt-your-server.example.com --ls-memory

List Processors

For getting a detailed list of processors you can run badfish with the --ls-processors option.

badfish -H mgmt-your-server.example.com --ls-processors

List GPUs

For getting a detailed summary and list of GPU's on the host you can run badfish with the --ls-gpu option.

badfish -H mgmt-your-server.example.com --ls-gpu

List Serial Number or Service Tag

For getting the system's serial number or on Dell servers the service tag (equivalent to racadm getsvctag) you can run badfish with the --ls-serial option.

badfish -H mgmt-your-server.example.com --ls-serial

Check Virtual Media

If you would like to check for any active virtual media you can run badfish with the --check-virtual-media option which query for all active virtual devices.

badfish -H mgmt-your-server.example.com --check-virtual-media

Mount Virtual Media

If you would like to mount an ISO from network you can run badfish with the --mount-virtual-media option which post a request for mounting the ISO virtual media (Virtual CD). Full address to the ISO is needed as an argument.

badfish -H mgmt-your-server.example.com --mount-virtual-media http://storage.example.com/folder/linux.iso

Unmount Virtual Media

If you would like to unmount all active virtual media you can run badfish with the --unmount-virtual-media option which post a request for unmounting all active virtual devices.

badfish -H mgmt-your-server.example.com --unmount-virtual-media

Boot to Virtual Media

If you would like to boot to virtual media (Virtual CD) you can run badfish with the --boot-to-virtual-media option which sets the onetime next boot device to virtual CD.

badfish -H mgmt-your-server.example.com --boot-to-virtual-media

Check Remote Image

If you would like to check the attach status of a remote ISO in DellOSDeployment service you can run badfish with the --check-remote-image option.

badfish -H mgmt-your-server.example.com --check-remote-image

[!NOTE] This is only supported on DELL devices.

Boot to Remote Image

If you would like to boot to a remote ISO on NFS with DellOSDeployment service you can run badfish with the --boot-remote-image option which will attach the image and reboot the server to it. Expects the NFS path to the ISO as the argument.

badfish -H mgmt-your-server.example.com --boot-remote-image nfs-storage.example.com:/mnt/folder/linux.iso

[!NOTE] This is only supported on DELL devices.

Detach Remote Image

If you would like to detach an ISO from DellOSDeployment service you can run badfish with the --detach-remote-image option.

badfish -H mgmt-your-server.example.com --detach-remote-image

[!NOTE] This is only supported on DELL devices.

Get SRIOV mode

For checking if the global SRIOV mode is enabled you can use --get-sriov

badfish -H mgmt-your-server.example.com --get-sriov

[!NOTE] This is only supported on DELL devices.

Set SRIOV mode

For changing the mode of the SRIOV global BIOS attribute, we have included 2 new arguments. In case the setting is in disabled mode, you can enable it by passing --enable-sriov

badfish -H mgmt-your-server.example.com --enable-sriov

On the contrary, if you would like to disable the SRIOV mode, you can now pass --disable-sriov

badfish -H mgmt-your-server.example.com --disable-sriov

[!NOTE] This is only supported on DELL devices.

Get FQDDs for all nics

To get a list of all FQDDs for all NICs on the server you can run badfish with --get-nic-fqdds.

badfish -H mgmt-your-server.example.com --get-nic-fqdds

[!NOTE] This is only supported on Dell devices.

Get NIC attributes

To get a list of all NIC attributes we can potentially modify (some might be set as read-only), you can run badfish with --get-nic-attribute passing the desired FQDD and this will return a list off all NIC attributes with their current value set.

badfish -H mgmt-your-server.example.com --get-nic-attribute NIC.Integrated.1-1-1

[!NOTE] This is only supported on Dell devices.

Set NIC attribute

[!WARNING] This action will trigger a reboot of the server to apply the changes. Changes will be reflected after the reboot is completed.

To change the value of a NIC attribute you can use --set-nic-attribute with the desired FQDD, passing both --attribute and desired --value.

badfish -H mgmt-your-server.example.com --set-nic-attribute NIC.Integrated.1-1-1 --attribute LegacyBootProto --value PXE

[!NOTE] This is only supported on Dell devices.

Get BIOS attributes

To get a list of all BIOS attributes we can potentially modify (some might be set as read-only), you can run badfish with --get-bios-attribute alone and this will return a list off all BIOS attributes with their current value set.

badfish -H mgmt-your-server.example.com --get-bios-attribute

Get specific BIOS attribute

In case you would like to get a more detailed view on the parameters for a BIOS attribute you can run --get-bios-attribute including the specific name of the attribute via --attribute.

badfish -H mgmt-your-server.example.com --get-bios-attribute --attribute ProcC1E

Set BIOS attribute

To change the value of a bios attribute you can use --set-bios-attribute passing both --attribute and --value.

badfish -H mgmt-your-server.example.com --set-bios-attribute --attribute ProcC1E --value Enabled

Set multiple BIOS attributes

To set multiple BIOS attributes in one call, repeat --attribute-value with an attribute=value pair each time. All attributes are applied in a single operation and one reboot.

badfish -H mgmt-your-server.example.com --set-bios-attribute --attribute-value ProcC1E=Enabled --attribute-value BootMode=Uefi

[!NOTE] You can get the list of allowed values you can pass for that attribute by looking at the attribute details via --get-bios-attribute for that specific one.

Change between BIOS and UEFI modes

  • Building on the get/set bios attribute commands above here's how you can manage BIOS and UEFI modes on supported servers.

[!NOTE] This is only supported on Dell devices.

Querying bootmode

  • First determine what bootmode state your server is using before proceeding.
badfish -H mgmt-your-server.example.com --get-bios-attribute --attribute BootMode

Setting UEFI mode

badfish -H mgmt-your-server.example.com --set-bios-attribute --attribute BootMode --value Uefi

Setting BIOS mode

badfish -H mgmt-your-server.example.com --set-bios-attribute --attribute BootMode --value Bios

[!IMPORTANT] Like all batch-driven actions this takes a reboot and time to process so be patient. You should also give it time to process before checking result via --get-bios-attribute --attribute BootMode as it could be cached for a minute or two after processing.

Get server screenshot

If you would like to get a screenshot with the current state of the server you can now run badfish with --screenshot which will capture this and store it in the current directory in png format.

badfish -H mgmt-your-server.example.com --screenshot

[!NOTE] This is only supported on Dell devices.

Targets for server configuration profile

If you want to get a list of allowed targets for SCP export or import you can get that with the --get-scp-targets command, pass either Export or Import as an argument.

badfish -H mgmt-your-server.example.com --get-scp-targets Export

[!NOTE] This is only supported on Dell devices.

Export server configuration profile

If you would like to export a SCP as a JSON file for either some specific targets or all of them, you can run badfish with --export-scp and specify a path where the config should be saved to with its argument. Targets can be specified with --scp-targets flag that takes a comma separated list of targets as an argument. Read only arguments can be included with the --scp-include-read-only flag.

badfish -H mgmt-your-server.example.com --export-scp "./" --scp-targets IDRAC,BIOS --scp-include-read-only

[!NOTE] This is only supported on Dell devices.

Import server configuration profile

If you would like to import a SCP in a JSON file for either some specific targets or all of them, you can run badfish with --import-scp. Targets can be specified with --scp-targets flag that takes a comma separated list of targets as an argument. Command will reboot the server and return it to a state at the launch start of import.

badfish -H mgmt-your-server.example.com --import-scp "./example_export.json" --scp-targets IDRAC,BIOS

[!NOTE] This is only supported on Dell devices.

Bulk actions via text file with list of hosts

In the case you would like to execute a common badfish action on a list of hosts, you can pass the optional argument --host-list in place of -H with the path to a text file with the hosts you would like to action upon and any addtional arguments defining a common action for all these hosts.

badfish --host-list /tmp/bad-hosts --clear-jobs

Verbose output

If you would like to see a more detailed output on console you can use the --verbose option and get a additional debug logs.

[!NOTE] --log uses the same log level: INFO by default, DEBUG with --verbose.

badfish -H mgmt-your-server.example.com  -i config/idrac_interfaces.yml -t foreman --verbose

Log to file

If you would like to log the output of badfish you can use the --log option and pass the path to where you want badfish to log it's output to.

badfish -H mgmt-your-server.example.com  -i config/idrac_interfaces.yml -t foreman --log /tmp/bad.log

Formatted output

If you would like to easier query some information listed by badfish, you can tell badfish to output in either JSON or YAML. Formatted output is also supported for bulk actions with --host-list. Supported commands that list some information are:

  • --ls-*
  • --firmware-inventory
  • --get-bios-attribute (also works with specified attribute by --attribute after)
  • --check-boot
  • --check-virtual-media
  • --power-state.
badfish -H mgmt-your-server.example.com --output json --firmware-inventory

Redfish emulator (mock iDRAC)

Badfish ships a built-in Redfish emulator that acts like a Dell-flavored iDRAC for development and testing, so most badfish commands can be exercised without bare metal.

Run the emulator as a persistent server:

badfish --redfish-emulator --port 8443

It serves HTTPS on 127.0.0.1:8443 using a self-signed certificate generated on first run (never committed to the repo or shipped in the wheel/RPM; see src/badfish/emulator/certs/README.md). The keypair lives in $XDG_CACHE_HOME/badfish/emulator/ by default; point BADFISH_EMULATOR_CERTS at a directory containing emulator.crt/emulator.key (or where they should be created) to relocate it. Point a second badfish instance at the emulator like any BMC, and pass --insecure to skip certificate verification, the self-signed cert will not validate otherwise:

badfish -H 127.0.0.1:8443 -u quads -p quads --insecure --power-state
badfish -H 127.0.0.1:8443 -u quads -p quads --insecure --ls-serial
badfish -H 127.0.0.1:8443 -u quads -p quads --insecure --firmware-inventory
badfish -H 127.0.0.1:8443 -u quads -p quads --insecure --ls-jobs

Default credentials are quads / quads, the same convention quads uses for its IPMI user. Set BADFISH_EMULATOR_USER and BADFISH_EMULATOR_PASSWORD to override. --bind and --port control the listen address.

Accounts run through the Redfish AccountService: each user carries a role (Administrator, Operator, ReadOnly), users can be created, edited and removed over the API, passwords change via the ChangePassword action, and the last enabled Administrator cannot be deleted, disabled, or demoted. Accounts live in a small JSON store created at runtime (default /tmp/badfish_emulator_users.json, BADFISH_EMULATOR_USERS to relocate) with plaintext passwords: the emulator is a temporal testing fixture, not a security boundary, and state dies with the box.

Currently covered: session/token auth, user and account management with role-based authorization (roles are re-resolved live, so demotions take effect on existing sessions), power state and reset, one-shot boot overrides, boot order reads, BIOS attributes and registry, NIC attributes (DellNetworkAttributes) under both the System and Chassis trees, the jobs queue (create/check/delete) with a Running-then-Completed lifecycle, SCP import tasks that 404 when unknown (like real iDRAC), virtual media mount/eject/detach, firmware inventory, system/processor/memory/network-interface/port/network-device-function inventory, and SCP import/export. Screen capture and network ISO boot are stubbed and degrade gracefully.

[!NOTE] This is a development tool, not a security boundary. The certificate (generated at runtime, unique per install) and default credentials exist so CI and laptops can spin up a mock iDRAC with zero setup.

Resource templates live in src/badfish/emulator/templates/ and are served by URI path. The emulator does not fetch vendor mockup bundles, for example DMTF DSP2043; templates are loaded from that directory at startup.

iDRAC and Data Format

Dell Foreman and PXE Interface

Your usage may vary, this is what our configuration looks like via config/idrac_interfaces.yml

  • Note that these are BIOS mode, EFI interfaces may be different and not yet recorded everywhere for our uses.
Machine Type Network Interface
Dell fc640 NIC.Integrated.1-1-1
Dell r620 NIC.Integrated.1-3-1
Dell r630 NIC.Slot.2-1-1
Dell r930 NIC.Integrated.1-3-1
Dell r720xd NIC.Integrated.1-3-1
Dell r730xd NIC.Integrated.1-3-1
Dell r740xd NIC.Integrated.1-3-1
Dell r640 NIC.Integrated.1-1-1
Dell r650 NIC.Integrated.1-1-1
Dell r660 NIC.PxeDevice.1-1
Dell r750 NIC.Integrated.1-1-1

Host type overrides

Every other method that requires passing the -i argument, is going to parse the key strings from this and look for the most adequate candidate for the given FQDN. We format the key strings with the following criteria:

{host_type}_[{rack}_[{ULocation}_[{blade}_]]]{model}

Additionally we can do a blade only override like:

{host_type}_[{blade}_]{model}

With rack, ULocation and blade being optional in a hierarchical fashion otherwise mandatory with the exception of the blade, as we can now use the blade independently from rack and ULocation. host_type and model values are always mandatory.

By default the rack, ULocation and blade components are parsed out of the hostname (format mgmt-{rack}-{uloc}-{blade}-{model}). You can override them on the command line with --rack, --uloc and --blade when the hostname doesn't follow that layout:

badfish -H mgmt-f21-h17-000-r620.example.com -i config/idrac_interfaces.yml -t director --blade 001

The --blade override produces a blade only key (director_001_r620 in the example), while --rack and --uloc override the corresponding components when resolving hierarchical keys.

Example for director type overrides:

Keys defined on interfaces yaml FQDN Use boot order
director_r620 mgmt-f21-h17-000-r620.domain.com NO
director_f21_r620 mgmt-f21-h17-000-r620.domain.com NO
director_f21_h17_r620 mgmt-f21-h17-000-r620.domain.com YES
Keys defined on interfaces yaml FQDN Use boot order
director_r620 mgmt-f21-h18-000-r620.domain.com NO
director_f21_r620 mgmt-f21-h18-000-r620.domain.com YES
director_f21_h17_r620 mgmt-f21-h18-000-r620.domain.com NO
Keys defined on interfaces yaml FQDN Use boot order
director_r620 mgmt-f22-h17-000-r620.domain.com YES
director_f21_r620 mgmt-f22-h17-000-r620.domain.com NO
director_f21_h17_r620 mgmt-f22-h17-000-r620.domain.com NO

Contributing

Please refer to our contributing guide.

Contact

  • You can find us on IRC in #badfish (or #quads) on irc.libera.chat if you have questions or need help.
  • Click here to join in your browser.

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

badfish-1.7.0.tar.gz (145.4 kB view details)

Uploaded Source

Built Distribution

If you're not sure about the file name format, learn more about wheel file names.

badfish-1.7.0-py3-none-any.whl (86.2 kB view details)

Uploaded Python 3

File details

Details for the file badfish-1.7.0.tar.gz.

File metadata

  • Download URL: badfish-1.7.0.tar.gz
  • Upload date:
  • Size: 145.4 kB
  • Tags: Source
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/7.0.0 CPython/3.13.14

File hashes

Hashes for badfish-1.7.0.tar.gz
Algorithm Hash digest
SHA256 ddaf268bea28f1dedbef63923b32b4d68423e0007628882b3dfcda3236f1a86e
MD5 7bfa322a6bc4885b3c3a59526959fb46
BLAKE2b-256 527ea45dac6bcd9dfc6faf7a34f68d5271764e5c76377c024b413a14f55a7216

See more details on using hashes here.

File details

Details for the file badfish-1.7.0-py3-none-any.whl.

File metadata

  • Download URL: badfish-1.7.0-py3-none-any.whl
  • Upload date:
  • Size: 86.2 kB
  • Tags: Python 3
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/7.0.0 CPython/3.13.14

File hashes

Hashes for badfish-1.7.0-py3-none-any.whl
Algorithm Hash digest
SHA256 077f4b57e4709069dbac635043d2cfc1bbeb10cedded57711b660a27b0cbc444
MD5 fc4b6a16cf29ceda2cdb5c2e9f79fb4a
BLAKE2b-256 e620fee5dc895a6abd1137e7acdaa3771800da9f17eb4d5e575d8335967c12da

See more details on using hashes here.

Release history Release notifications | RSS feed

This release

1.7.0 This release

2 files

1.6.0

2 files

1.5.0

2 files

1.4.0

2 files

1.3.0

2 files

1.2.0

2 files

1.1.1

2 files

1.1.0

2 files

1.0.7

2 files

1.0.6

2 files

1.0.5

2 files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page