metal-toolbox / flasher

Server firmware installer

 _______  ___      _______  _______  __   __  _______  ______
|       ||   |    |   _   ||       ||  | |  ||       ||    _ |
|    ___||   |    |  |_|  ||  _____||  |_|  ||    ___||   | ||
|   |___ |   |    |       || |_____ |       ||   |___ |   |_||_
|    ___||   |___ |       ||_____  ||       ||    ___||    __  |
|   |    |       ||   _   | _____| ||   _   ||   |___ |   |  | |
|___|    |_______||__| |__||_______||__| |__||_______||___|  |_|

Flasher - server fleet firmware install automation

Flasher is a vendor agnostic tool to automate firmware installs across a server fleet.

Flasher is currently limited to installing firmware Out of band - through the host BMC, and expects the host BMC to be reachable to install firmware.

If the given server is powered off, it will be powered on, the firmware will be install and powered off after.

When a firmware requires the server to be power cycled, flasher will perform the power cycle action and poll until the firmware install is completed.

Build

make build-linux

Run

Flasher can be run in the worker mode or to one-shot install a given firmware file.

Note: it expects to be able to reach the BMC interface for the given server.

worker command

In the worker mode flasher worker, flasher depends on NATS to accept work, a secret store for BMC secrets, a firmware file store for firmware files to install.

Check out the sandbox for steps to have it running along with its dependencies.

The sandbox README.md includes instructions to register a server, create firmware sets and install them on a server.

The diagram below depicts the services flasher depends on:

graph TB
  a((Flasher))-- 1. Query Asset BMC creds, attributes -->ss[(FleetDBAPI)]
  a((Flasher))-- 2. Query current inventory -->sb(ServerA BMC)
  a((Flasher))-- 3. Fetch firmware files -->sa(Firmware file store)
  a((Flasher))-- 4. install firmware -->sb(ServerA BMC)

Loading

install command

The flasher install command will install the given firmware file on a server, and poll until the install is complete.

flasher install --addr 192.168.1.1 \
                --user ADMIN \
                --pass hunder2 \
                --version 3.6 \
                --component bios \
                --vendor supermicro \
                --model x11dph-t \
                --force \
                --file /tmp/BIOS_X11DPH-0981_20220208_3.6_STD.bin \
                --dry-run  \

see cheatsheet.md

Supported devices

For out of band updates, Flasher leverages bmclib and so supports firmware installs on devices that are supported by the library.

As of this writing, it supports Dell PowerEdge, Supermicro X11, X12, Asrockrack updates through their BMC.

Documentation

Documentation on development and flasher implementation can be found in docs

flasher's Issues

Include condition ID in published condition update

The condition ID is required in condition update events metal-toolbox/conditionorc@a70b48f

Separate contexts for process retrieval and processing

We might consider having 2 contexts here, one for the message retrieval and one for actually processing messages.

Originally posted by @DoctorVin in #6 (comment)

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Rate-Limited

These updates are currently rate-limited. Click on a checkbox below to force their creation now.

• fix(deps): update module github.com/spf13/cobra to v1.8.1
• fix(deps): update module github.com/metal-toolbox/rivets to v1.1.0
• fix(deps): update module github.com/spf13/viper to v1.19.0
• fix(deps): update module golang.org/x/net to v0.27.0
• chore(deps): update anchore/scan-action action to v4
• chore(deps): update goreleaser/goreleaser-action action to v6
• fix(deps): update module github.com/metal-toolbox/fleetdb to v1
• 🔐 Create all rate-limited PRs at once 🔐

Pending Status Checks

These updates await pending status checks. To force their creation now, click the checkbox below.

• chore(deps): update docker/build-push-action action to v6

---

Warning

Renovate failed to look up the following dependencies: Can't find version matching v0.0.0-20240416132216-a56a09c16f4e for go package github.com/bmc-toolbox/common, Can't find version matching v0.0.0-20240416160154-fe59bbe5cc7f for go package golang.org/x/exp.

Files affected: go.mod

---

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• fix(deps): update module github.com/hashicorp/go-retryablehttp to v0.7.7 [security]
• fix(deps): update module github.com/prometheus/client_golang to v1.19.1
• chore(deps): update anchore/sbom-action action to v0.17.0
• fix(deps): update module github.com/metal-toolbox/fleetdb to v0.18.2
• fix(deps): update module go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp to v0.53.0
• fix(deps): update module golang.org/x/oauth2 to v0.21.0
• fix(deps): update opentelemetry-go monorepo to v1.28.0 (go.opentelemetry.io/otel, go.opentelemetry.io/otel/trace)
• chore(deps): update github/codeql-action action to v3
• chore(deps): update golangci/golangci-lint-action action to v6
• fix(deps): update module github.com/bombsimon/logrusr/v2 to v4
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

dockerfile

Dockerfile

github-actions

.github/workflows/codeql-analysis.yml

• actions/checkout v4
• actions/setup-go v5
• github/codeql-action v3
• github/codeql-action v3
• github/codeql-action v2

.github/workflows/push-pr-lint.yaml

• actions/checkout v4
• actions/setup-go v5
• golangci/golangci-lint-action v3
• actions/checkout v4
• actions/setup-go v5
• docker/setup-buildx-action v3
• docker/build-push-action v5
• anchore/scan-action v3

.github/workflows/release.yml

• docker/login-action v3
• actions/checkout v4
• actions/setup-go v5
• anchore/sbom-action v0.15.0
• goreleaser/goreleaser-action v5

gomod

go.mod

• go 1.22
• github.com/banzaicloud/logrus-runtime-formatter v0.0.0-20190729070250-5ae5475bae5e@5ae5475bae5e
• github.com/bmc-toolbox/bmclib/v2 v2.2.6
• github.com/bmc-toolbox/common v0.0.0-20240416132216-a56a09c16f4e@a56a09c16f4e
• github.com/bombsimon/logrusr/v2 v2.0.1
• github.com/coreos/go-oidc v2.2.1+incompatible
• github.com/emicklei/dot v1.6.2
• github.com/equinix-labs/otel-init-go v0.0.9
• github.com/google/uuid v1.6.0
• github.com/hashicorp/go-multierror v1.1.1
• github.com/hashicorp/go-retryablehttp v0.7.5
• github.com/jeremywohl/flatten v1.0.1
• github.com/jpillora/backoff v1.0.0
• github.com/metal-toolbox/fleetdb v0.17.1
• github.com/metal-toolbox/rivets v1.0.4
• github.com/mitchellh/mapstructure v1.5.0
• github.com/pkg/errors v0.9.1
• github.com/prometheus/client_golang v1.19.0
• github.com/sirupsen/logrus v1.9.3
• github.com/spf13/cobra v1.8.0
• github.com/spf13/viper v1.18.2
• github.com/stretchr/testify v1.9.0
• go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp v0.50.0
• go.opentelemetry.io/otel v1.25.0
• go.opentelemetry.io/otel/trace v1.25.0
• golang.org/x/exp v0.0.0-20240416160154-fe59bbe5cc7f@fe59bbe5cc7f
• golang.org/x/net v0.25.0
• golang.org/x/oauth2 v0.19.0

---

• Check this box to trigger a request for Renovate to run again on this repository

Explain in the README how to run the flasher in debug mode

It would nice to provide a way to have debug messages, as well as requests/responses data for the HTTP requests.

Download all firmware artifacts beforehand

Flasher currently downloads the firmware to be installed on a case by case basis - instead it should download all the relevant firmware artifacts in a firmware-set beforehand so as to ensure that all the artifacts required are available and verified for install.

This will prevent compatibility issues as described here metal-toolbox/architecture#1 (comment)