Skip to content

v1.0.0

Latest
Latest

Choose a tag to compare

View all tags
@github-actions github-actions released this 29 Jul 06:57
v1.0.0
71dd58c
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

raptor 1.0.0 — a hawkBit-compatible OTA update server in Rust. One binary, one config file.

What 1.0.0 means

The hawkBit compatibility surface is now a contract rather than a moving target. Stock DDI clients — SWUpdate, RAUC hawkbit-updater, Zephyr's hawkBit module, hawkbit-rs — work against raptor unchanged, and the wire format they depend on is frozen for the 1.x series: JSON field names, the paging envelope, error bodies, and the DDI link structure. Everything still on the roadmap is additive.

If you are already running 0.9.0, this release is a version bump plus the changes below. There are no breaking changes and no manual migration steps — schema migrations run at startup as usual.

Since 0.9.0

DDI compatibility pass (#39–#44). Six fixes found by running Zephyr's hawkBit client against raptor:

  • the confirmation flow no longer strands clients that don't implement confirmationBase — they would otherwise poll forever without installing. The flow stays off by default, and auto_confirm_default auto-confirms newly registered targets when you do turn it on
  • configData is advertised only until the device has reported its attributes, instead of on every poll (Zephyr was re-uploading every cycle)
  • artifact download-http links carry plain HTTP rather than inheriting the request's scheme
  • the device address (ipUri) is recorded from controller polls, so the target list shows where a device last called from
  • the DEFAULT-tenant constraint in emitted links is documented and guarded
  • a Zephyr integration guide with a per-feature compatibility matrix

All four hawkBit action types (#4). forced, soft, downloadonly, and timeforced. A timeforced action starts soft and escalates when its deadline passes; downloadonly forces the download and never asks the device to install. Operators can escalate a running action with PUT /rest/v1/targets/{controllerId}/actions/{actionId} and force-quit an unresponsive one with DELETE …/actions/{actionId}?force=true. Rollouts carry an action type too.

Server-side dashboard statistics (#38). The web console's counter tiles read GET /rest/v1/system/statistics instead of tallying a page of targets and actions in the browser, so they stay correct on fleets larger than the old 500-target fetch. The dashboard also gained a read-only System configuration card showing the tenant config devices see — polling interval, confirmation flow, and the enabled authentication modes.

Dependencies. SeaORM 2.0, base64 0.23, and the usual minor/patch sweep.

Installing

Download raptor_1.0.0-1_amd64.deb below:

$ sudo dpkg -i raptor_1.0.0-1_amd64.deb
$ printf 'yourpassword\n' | raptor hash-password   # put the hash in /etc/raptor/config.toml
$ sudo systemctl start raptor

The package does not auto-start on install: the shipped config carries a placeholder password hash, so edit /etc/raptor/config.toml first. The packaged binary includes the embedded web console at /ui.

From source:

$ cargo build --release                    # server only
$ cargo build --release --features embed-ui   # with the web console (needs `dx build --release --package raptor-ui` first)

What's in the box

DDI v1 in full — polling, deploymentBase, the feedback state machine, cancelAction, configData, installedBase, resumable Range downloads, .MD5SUM, auto-registration, and the confirmation flow. On the Management API: targets, software modules with multipart artifact upload, distribution sets, actions, rollouts with deploy groups, target filters with auto-assignment, types, tags, metadata, and FIQL q= filtering across the list endpoints. SQLite or Postgres, a content-addressed artifact store, optional OpenTelemetry export, and an optional embedded web console.

Not in 1.0

Tracked as issues and additive when they land: maintenance windows (#7), multi-assignment with action weights (#10), rollout approval (#17) and dynamic rollouts (#18), S3 artifact storage (#20), multi-tenancy (#12), mTLS/OIDC and multiple operator accounts (#13), quotas and action cleanup (#14), and the DMF/AMQP device path (#11). The web console also still trails the API in a few areas (#25, #34–#37).

Full documentation is in docs/ as an mdbook — start with hawkBit compatibility for the authoritative feature matrix.

Full changelog: v0.9.0...v1.0.0

Assets 3
Loading