Skip to content

v4.17 [August 2026]

Release Themes: Role-Based UX, Content Archive GA, Pipeline Reliability, Replication Scalability

Executive Summary

Digital Rebar v4.17 builds on the platform investments introduced in v4.16 with new capabilities across usability, packaging, and scalability.

This release introduces Role-Based UX, adding an Operator role to the Digital Rebar interface to clarify role-based responsibilities, with additional roles planned for future releases.

Content Archive, introduced as a Technical Preview in v4.16, reaches General Availability in v4.17.

Engineering continued modernizing DRP's pipeline infrastructure this cycle, further improving the reliability and flexibility of automated workflows across the platform. v4.17 introduces restartable provisioning pipelines, allowing a failed pipeline to resume from the phase where it stopped rather than restarting the machine, giving teams faster recovery at scale.

The Manager Replication Refactoring is completed in v4.17, including a shift to an on-demand, cached replication model that improves memory footprint and performance for large-scale, multi-site deployments.

Eikon, the native image deployment engine positioned to replace Curtin, reaches production readiness in v4.17, and the Curtin-based image-deploy plugin is now deprecated.

The RackN Portal receives a visual refresh in v4.17, including a new Dark Theme and general polish across the interface.

For customers using an external secret store such as Vault, AWS Secrets Manager, or Azure Key Vault, drpcli set now rotates secrets directly in that store instead of overwriting them with an inline copy, preserving the reference secret.

Overall, v4.17 rounds out the usability, packaging, and scalability investments introduced in v4.16.

Important Notices

Note

Note

drpcli <object> list and the Python SDK (drppy_client) list_* methods now default to a page size of 1000 (previously unlimited). Pass --limit -1 on the CLI or limit=-1 in the SDK to restore the prior unlimited behavior. See List Command Default Limit for details.

Note

The bootenvs deprecated in v4.16 have been removed. Audit any workflow, profile or linux/install-bootenv value pinned to a specific OS point release before upgrading. See Deprecated OS Version Removals.

Note

Claim matching is now open-world: a scope or action DRP does not recognise matches nothing, rather than being satisfied by any claim at all. Behaviour changes for one scope -- jobArchive -- and for event subscriptions to tftp, webhook and trigger, which now require a grant and are filtered silently if absent. A grant of action:<cmd> no longer authorizes a different command. Claim content is no longer rejected at role save. See Open-World Claim Matching.

Note

The image-builder content pack is now OS-agnostic: the seven per-OS build workflows are removed in favor of a single image-builder-universal workflow that selects the OS via linux/install-bootenv. Update automation referencing the old workflow names. See Image Builder: OS-Agnostic Build Workflow.

Note

aggregate=true on an object GET no longer decrypts secure parameter values. Decryption now follows the decode flag alone, which requires the getSecure action. Callers that read secure values out of an aggregated response must add decode=true and hold getSecure. See Secure Parameter Authorization.

Note

Roles that name a scope or action which was previously unregistered may now be refused where they were silently permitted. Audit custom roles that reference consensus, content_archives, connections, debug, events, logs or static, or that grant getSecure/updateSecure on objects other than machines, clusters, resource brokers, plugins, profiles or stages. Roles granting * are unaffected. See Scope and Action Registration.

Note

SAML no longer signs in a username that already exists as a non-SAML user, and a user's auth-method metadata can no longer be changed after the user is created. Deployments that pre-create local users and expect SAML to adopt them must let SAML create the user instead. See User Authentication Method Is Fixed At Creation.

Release Information

New for this release:

See other release notes for previous Release Information. All the incremental fixes to previous releases. See Change History

Vulnerabilities

Golang Updates

In order to reduce and attempt to prevent supply-chain attacks, RackN watches that golang security streams and updates the components that have issues. This release continues those updates.

Secure Parameter Authorization

Several routes allowed a principal that could write a secure parameter to read it back, or allowed a secure value to be returned decrypted without the getSecure action. All of them are closed in this release.

  • Secure values are no longer converted to plaintext without authorization. The routine that reconciles a stored value against its parameter definition's Secure flag guarded only the plaintext-to-sealed direction. The reverse direction -- which both writes and reveals plaintext -- now requires updateSecure and getSecure on the object, and additionally only converts a value that was already stored as a secure value. The second check is independent of any claim, so a caller can no longer hand the endpoint an arbitrary sealed blob and have it decrypted with the target object's key.
  • aggregate=true no longer implies decryption. The generic object GET decrypted whenever aggregate or decode was set, while only decode is authorized -- making aggregate=true an unauthorized decode. Decryption now follows decode alone. This matches the /<prefix>/<id>/params route, which has always behaved this way.
  • A token minted for a user no longer counts as that user when reading that user's own secure parameters. users:token:<name> produces a token carrying <name>'s identity, so ownership now additionally requires that the token was obtained by that user, which only a sign-in produces.

Operators reading secure values out of an aggregated response need to add decode=true and hold getSecure. See the note in Important Notices.

Scope and Action Registration

Asking whether a principal is allowed an action that was not registered for its scope returned true rather than false, so any authorization check written against an unregistered scope or action was satisfied by any claim at all. This affected two groups:

  • Seven scopes guarded live routes without being registered: connections, consensus, content_archives, debug, events, logs and static. The most significant is consensus, which gates the cluster membership APIs.
  • getSecure and updateSecure were registered for only a subset of object types, so the secure parameter checks above were inert on the remainder -- including users, subnets, blueprints, reservations and work_orders.

Both are now registered, and the secure actions are derived from whether an object can carry parameters at all, so a new object type is covered automatically.

Because a role granting * expands to whatever actions exist, superuser and wildcard roles are unaffected. Roles that enumerate actions, or that name one of the seven scopes above, should be audited: a grant that was silently permitted may now be refused. Note also that these grants could not previously be saved at all -- role validation rejected them -- so registering them is what makes the correct grant expressible.

User Authentication Method Is Fixed At Creation

A user's auth-method metadata records how the account came into being -- saml, ad-auth, or absent for a local user -- and is consulted when deciding whether a superuser is exempt from the last-local-superuser deletion guard and whether to consult an authentication plugin. It was freely writable, so a principal able to edit a user could mark the last local superuser as externally managed and then delete it.

It is now set when the user is created and cannot be changed afterwards. Relatedly, SAML now refuses to sign in a username that already exists as a non-SAML user, matching the behavior authentication plugins have always had. A username belongs to exactly one authentication method.

Deployments that pre-create local users and expect SAML to adopt them on first sign-in must let SAML create the user instead. A SAML-adopted account had its roles replaced from group mapping in any case, so pre-creation contributed only the name.

Deprecations

OS Version Deprecation

Support for many of the operating system versions that are referenced in the various content packs are being marked as deprecated and will be removed in a future release.

These deprecations are based upon unsupported minor releases or end-of-life statements by the vendors.

OS Deprecated Versions
AlmaLinux 9.5–9.7, 10.0, 10.1
Debian 11
Fedora 42
Oracle Linux 9.4–9.7, 10.0, 10.1
Rocky Linux 9.4–9.7, 10.0, 10.1
Ubuntu 20.04, 24.04.2, 24.04.3
RHEL 9.4–9.7, 10.0, 10.1
SLES 15-SP5-GM, 15-SP5-QU4, 15-SP6-GM, 15-SP6-QU3, 15-SP7-GM, 15-SP7-QU2, 15-SP7-QU3, 16.0-GM, 16.0-QU0, 16.0-QU2
VMware ESXi 7.0.x

The bootenvs are annotated in their documentation and descriptions.
See more information at RackN Provided Bootenv Lifecycle.

Image-deploy Plugin

The image-deploy plugin (Curtin) is deprecated as of v4.17 and will be removed in a future release, with no removal version set yet. With Eikon now production-ready, it's the recommended engine for all new image deployments, and operators should start planning their move rather than waiting for a removal announcement -- migration is a simple, reversible application profile swap, and RackN continues to collect feedback on Eikon usage and issues.

Removals

Deprecated OS Version Removals

Support for the operating system versions deprecated in v4.15 (see OS Version Deprecation) have been removed, covering superseded point releases and vendor end-of-life OS versions.

FEATURES

Role-Based UX

Digital Rebar v4.17 introduces the Operator Role into the Digital Rebar interface. This marks an important step in maturing DRP's user experience, giving organizations clearer separation of responsibilities and more granular control over platform access and configuration. Additional roles are planned for future releases.

Content Archive - General Availability

The Content Archive packaging format, introduced in v4.16 as a Technical Preview, reaches General Availability in v4.17. Content Archives simplify packaging and distribution by bundling object definitions, artifacts, and plugin extensions into self-contained, atomically upgradable packages while reducing on-disk overhead. This release completes full integration with the Content Catalog, UX interface, and Manager tools, building on operator feedback gathered since the v4.16 Technical Preview.

Pipeline Enhancements

With v4.17, DRP introduces restartable provisioning pipelines. A machine moves through the full pipeline in distinct phases for prepare, discover, hardware, operating system, and application, and if a pipeline fails, it resumes from the phase where it stopped rather than starting the machine over. Every run is queued and tracked phase by phase, so as teams adopt it, they gain faster recovery and less manual intervention when provisioning at scale.

Manager Replication Refactoring - Frontend Completion

Building on the backend redesign delivered in v4.16, v4.17 completes the corresponding frontend improvements for Manager Replication. This work directly addresses scalability requirements for RackN's largest enterprise deployments, extending the robustness and performance gains of the refactored replication backend to the operator-facing experience.

Multi-site manager (MSM) replication has been inverted, switching from an eager, streamed database model to an on-demand, cached model. This vastly improves the memory footprint in MSM systems of all sizes and is carefully optimized to ensure similar (or better) performance and latency for common operations, such as UX navigation, making MSM a much more tangible feature for large-scale systems.

Eikon - Production Ready

Eikon, the native image deployment engine positioned to replace Curtin, reaches production readiness in v4.17 and is now the recommended engine for image deployment. Additional information is available in Eikon Image Deploy and Eikon Architecture.

Major improvements to Eikon include:

  • Deploys vendor cloud images -- including QCOW2 -- as either a whole-disk image or a rootfs archive onto a declarative storage layout with LVM, software RAID, and stable device identifiers
  • Generates a UUID-based /etc/fstab so deployments boot reliably regardless of disk enumeration
  • Consolidated bootloader handling across Debian and RHEL (UEFI and BIOS)
  • Version-agnostic Windows deployment across Server 2019-2025 and Windows 10/11
  • Support for airgap and authenticated (basic-auth/mTLS) image sources

Because Eikon shares Curtin's image-deploy parameters within the same workflow, switching engines -- or rolling back -- is simply a profile swap. With Eikon production-ready, the image-deploy plugin (Curtin) is deprecated in v4.17 and will be removed in a future release.

Portal Visuals Refresh

Sport the new Dark Theme while enjoying cleaner visuals across the RackN Portal. Theming options are available in the UX Config view, including high contrast and primary color preferences. This upgrade also includes new polish to the Catalog, the License Manager, and Notifications.

Writable External Secrets

Setting a secure parameter that resolves to a LookupUri now writes the value into the external store -- Vault, AWS Secrets Manager, or Azure Key Vault -- instead of replacing the reference with an inline-encrypted value. Rotating an externally stored secret via the normal drpcli set now works, and the reference stays intact. The reference can live on the object or be inherited from a profile; either is followed. Pass --no-write-through to write the object's own copy instead.

Open-World Claim Matching

Role Claims are now matched as patterns rather than looked up against a fixed registry of known scopes. A request is allowed only if some Claim in a single role positively covers it, and anything not positively covered is denied.

Previously an unrecognised scope or action was silently satisfied by any claim at all, because it compiled to an empty requirement that every claim vacuously met. The same scopes could not be granted either -- they were rejected at role save -- so there was no way to author a Claim that closed the gap.

What changes for an existing deployment. Three things, and only one narrows access anyone currently holds:

Change Effect
jobArchive now requires a real grant Previously readable by any authenticated principal holding any claim. Grant jobArchive with actions get, list or update to restore access.
action:<cmd> no longer authorizes a different command A grant of action:foo used to also authorize the command foo,bar. It now authorizes only foo.
A padded wildcard now means wildcard A Specific of " *" -- a star with surrounding whitespace -- previously matched nothing at all. It is now read as the * its author intended.
Event subscriptions for tftp, webhook and trigger now require a grant These three event types were checked but never declared, so they were delivered to any subscriber holding any claim at all. A subscriber watching them -- TFTP serves during a boot debug, webhook trigger failures, trigger firings -- now needs a Claim naming the event type as its scope, for example scope tftp, action event. Events are filtered silently: nothing is returned to the subscriber to say the stream was narrowed, so a websocket that goes quiet after upgrading is the symptom to look for.

The event-type row is the one most likely to be met as a mystery rather than an error, because event delivery has no way to report a filtered subscription. drpcli info get | jq .scopes does not list these three either -- whether an event type should be an object scope at all is under review in rackn/product-backlog#1673 -- so grant them by name if a subscription stops arriving.

Most of this transition arrived earlier in the v4.17 line, which registered seven scopes that were checked but never declared -- connections, consensus, content_archives, debug, events, logs and static. Those began requiring real grants at that point. jobArchive is the one that remained.

Claim content is no longer validated. A Role saves even if a scope or action is unrecognised; the server reports an advisory diagnostic instead. Nothing about a Claim's content can make a Role unusable, which also removes a startup hazard: a Role naming a scope that a plugin registers later is no longer invalid before that plugin loads.

drpcli info get reports a more accurate scope list. It is generated from the authorization checks the server actually performs rather than a hand-maintained table, and covers substantially more scopes and actions than before. It remains advisory -- a Claim naming something absent from it still saves and is still enforced. The web UI's scope and action pickers offer these values while also accepting free-form entry, so a scope the endpoint has not advertised can still be granted.

See How Claims Are Matched for the full semantics.

Other Items of Note

None known

List Command Default Limit

To prevent accidental full-table scans on large systems, drpcli <object> list commands and the Python SDK (drppy_client) list_* methods now default to a page size of 1000 instead of unlimited (-1).

  • CLI: drpcli machines list returns up to 1000 machines by default; pass --limit -1 to retrieve all.
  • SDK: api.list_machines() returns up to 1000 machines by default; pass limit=-1 to retrieve all.

Operators relying on full-set returns from list commands or SDK calls should audit their scripts and explicitly set --limit -1 / limit=-1 (or paginate) where required.

References: provision-server#646, provision!1394, drppy_client!14.

Image Builder: OS-Agnostic Build Workflow

The image-builder content pack now ships a single image-builder-universal workflow that builds a gold image of any supported Linux distribution, replacing the seven per-OS workflows. Select the OS at runtime by setting linux/install-bootenv (for example alma-9.8-min, rocky-10, or ubuntu-24.04) — the same linux-selector mechanism used by universal-linux-install.

Update any automation referencing the removed workflow names (image-builder-alma8, -centos8, -centos, -rhel8-server, -rhel-server, -rocky8, -ubuntu-bionic). RHEL images that need subscription registration inject redhat-subscription-register via image-builder/pre-builder-flexiflow.

References: product-backlog#1615.

Bug Fixes and Minor Improvements

Each component's version will move independently of other components. See Change History for more details.