Recommended Read: Gartner Mitigating Firmware Security Risks

If you are a Gartner subscriber, RackN recommends reading “How to Mitigate Firmware Security Risks in Data Centers, and Public and Private Clouds” by Tony Harvey.

This excellent paper discusses why having a process for patching firmware is critical for businesses.

It goes on to add that enabling the security features of hardware (TPM, Secure Boot and Signature Validation) are quickly becoming required features for data center infrastructure.

If you have questions, please contact RackN.  We can help map these requirements into Digital Rebar capabilities.

RackN Profile by RedMonk

RackN works with RedMonk for industry analysis and advisory services.  They a consistently leading the industry is deep insights and contributions about how the industry is moving.  For example, ‘s “How to Compete with AWS” frames the remarkable competitive challenge posed by the hyperscale cloud providers in which simply out investing them will not succeed.

Below  provides a balanced 3rd party overview of RackN that explains our structure and place in the data center infrastructure market.

New Client Profile: RackN

Industry Analysis: AWS Outposts

This is the first interview of the multi-part series about AWS Outposts and it’s impact on the IT industry.  While not the first data center appliance in market, Outposts represents the most extreme version of tethered, remote managed infrastructure in market because the control plane for the system remains with AWS and the hardware itself is manufactured by AWS.

In the series, we’ll dig deeply into how the technology works and it’s impact on the broader IT market.



This week, premier CloudFoundry consultancy Stark and Wayne posed about their Digital Rebar integration for CoreOS, CloudFoundry and Kubernetes.  This work integrates with their DRP MoltenCore content pack.

Having just a plain CoreOS machine is not as useful in itself, however CoreOS can be used as a building block for building clusters. DRP exposes some powerful primitives for orchestrating common cluster patterns, through the use of shared profiles which are updated by the machines themselves. This simple primitive can be used to implement master election, rolling updates, and distribution of bootstrap token.  – Roben Koster

For more details, please see

Digital Rebar Platform v4.2 Release

These release notes span the v4.1 and v4.2 releases. The focus is on features, not the numerous fixes for bugs and minor issues.

4.1 Release Items

  • Contexts – this is a major feature that allows workflows to transition between instances of runners on the machines and other locations (such as Docker containers)
  • Run without root permissions – enables operation in highly secure environments.
  • Tasks can have expanded Role and Claim rights – allows tasks to have special scope of operations inside of DRP
  • Transactions Improvements to WAL 
  • DRPY runner –  python version of the runner for ESXi environments
  • Ansible Inventory uses Profiles – 100% mapping between DRP and Ansible groups.
  • Redfish Support – IPMI integration for later hardware models
  • ESXi Installation – VMware Integration

    UX Custom Columns – Allows user to define columns in machine view

  • UX Expand View Filters – Expand filters to leverage all API supported filtering

4.2 Release Items

  • JQ integrated into DRP CLI – eliminates the need for installing JQ as a stand alone requirement.
  • BSDTAR integrated into DRP Server – eliminates the need for installing bsdtar on the server
  • Human/table formats for DRPCLI – makes it easier to read DRP output
  • DRP CLI can install itself as a persistent agent – from script contexts makes it easier to run DRP runner as a service
  • Plugins use Websocket events – migrate for legacy event model to improve stability.
  • UX Save in Header – makes it easier to have multiple edits on the same item

    UX diff view – allow operator to compare new vs installed content (fixes regression)

  • Updated license retrieval and install process – streamline process so that multiple users do not need RackN logins if a license is installed
  • UX bulk actions for Endpoints – useful for multi-site management

Beta Items

  • Bootstrap Agent Integrated into DRP Server – allows for on DRP server operations without use of Dangerzone context (v4.2)


Server firmware is fragile! Why haven’t we fixed it? The HPE SSD patch challenge.


Last week, HPE alerted us of a critical software bug that would cause SSDs to fail after three point seven years of use. The problem is not that there was a firmware bug, those happen all the time, but how little HPE provided to fix the problem. It basically throws the fix back to the operator to run scripts on each server.

SSDs are an example of firmware that is not typically managed by vendor out of band (HPE iLO, Dell DRAC) tooling. PDU, Fan, GPU, FPGA, and NIC firmware are also examples of deep firmware that must also be managed.

When we formed RackN 5 years ago, we thought that operators would want to make sure their server firmware was patched; however, in spite of a string of critical patches, firmware continually falls under the threshold of must manage software. This is remarkable because it is a well known performance and failure point for infrastructure.

We’ve spent the last few years trying to understand why the hardware is so often ignored in the infrastructure equation and refuse to accept that “it’s too hard” as the answer.

Instead, our industry has failed to treat firmware as part of an integrated infrastructure stack. We’ve accepted poor APIs and controls from vendors. We’ve fostered a belief that virtualization shields us from hardware. We’ve accepted the cloud “your not smart enough to run a data center” marketing. We’ve allowed these fallacies to make us complacent.

We need to treat firmware patching as part of a continuously integrated data center mindset. Where we can perform source-code controlled migrations of systems that allow us to safely and quickly make deep changes as part of regular deployment cycles.

Fully integrated provisioning is not fantasy: At RackN, we’re helping operators implement exactly these processes. It’s not magic, but it does require system level processes that prioritize workflows, inventory, discovery and integration to coordinate physical and application lifecycle.  It’s time for everyone to start thinking this way because this SSD patch is just the latest in an increasingly urgent string of firmware updates.

YES – VM + Containers can be faster than Bare Metal!

Pat Gelsinger, VMware CEO, said that VM managed Containers could be 8% faster than bare metal during the VMworld keynote (@kitcolbert). On the surface, this comment defies logic: bare metal should be the theoretical limit for performance like the speed of light. While I don’t know the specifics of his test case, the claim of improved performance is credible.  Let’s explore how.

RackN specializes in bare metal workloads so let me explain how it’s possible in the right cases that containers in VMs benchmark faster than containers alone.

The crux of the argument comes down to two factors:

  1. Operating systems degrade when key resources are depleted
  2. CPUs are optimized for virtualization (see NUMA architecture)

Together, these factors conspire to make VMs a design necessity on large bare metal systems.

A large RAM and CPU core system can become saturated with container workloads even in the 10s of containers. In these cases, the performance cost for operating system to manage resources starts to take away from the performance. Since typical hypervisor hosts have a lot of resources, the risk of over saturation is very high.

The solution on high resource hosts is to leverage a hypervisor to partition the resources into multiple operating system instances. That eliminates over saturation and improves throughput for the host. We’re talking about 10 vms with 10 containers instead of 1 host with 100 containers.

In addition to simple partitioning, most CPUs are optimized for virtualization. That means that they can run multiple virtualization operating systems on the same host with minimal overhead.  The non-virtualized host does not get to leverage this optimization.

Due to these factors AND with the right tuning, it would be possible to demonstrate improved container performance for hosts that were optimized for running a hypervisor. The same would not hold true for systems that are size optimized for only container workloads. Since the container optimized machines are also much cheaper, the potential performance gain is likely an not a good ROI.

While bare metal will eventually come; this strange optimization reinforces why we expect to see hypervisors continue to be desired in container deployments for a long time.

RackN Digital Rebar v4 Release

RackN is excited to announce v4 of Digital Rebar.  In this fourth generation, we recognize the project’s evolution from provisioner into a data center automation platform.  While the external APIs and behavior are NOT changing (v4.0 and v3.13 are API compatible), we are making important structural changes that allow for significant enhancements to scale, performance and collaboration.

This important restructuring enables Digital Rebar to expand as a community platform with open content.

RackN is streamlining and inverting our license model (see chart below) by making our previously closed content and plugins open and taking commercial control of our implementation behind the open Digital Rebar APIs.  This change empowers both expanding community and sustaining commercial engagement.

Over the last 2 years, our operator community around Digital Rebar and RackN content has frequently asked for source access to our closed catalog of content and plugins while leaving core development exclusively to RackN.  We believe that providing open, collaborative access is critical for the growth of the platform; consequently, Generation 4 makes these critical components available.

RackN will curate and support foundational content packs and plugins in the open.  They include items including operating system templates, out of band management (IPMI), image deploy, classification and our server life-cycle (RAID/BIOS) components.  We will be working with the Digital Rebar community to determine the right management model for items in this broad portfolio of content.

The RackN implementation powering the Digital Rebar API will be significantly enhanced in this generation.

We are integrating powerful new capabilities like multi-site management, 10,000+ machine scale, single-sign-on and deeper security directly into the implementation.  These specialized enhancements to the platform enable an even broader range of applications. Since the community has focused on contributing to platform content instead of the core; we believe this is the right place to manage the commercial side of sustaining the platform.

Please note that our basic commercial models and pricing plans are not changing.  We are still maintaining Digital Rebar and RackN binaries free for operators with up to 20 machines.  The change also allows us to enable new classes of use such as non-profit, academic and service provider.

Thank you to the Digital Rebar community!  We are handing you the keys to revolutionized data center operations.  Let’s get started!

Generation 4 clarifies the boundary between open and proprietary
Layer Component Generation 3 Generation 4
Content Platforms, Apps, Etc Mixed Digital Rebar APLv2
Ops Best Practices RackN Digital Rebar APLv2
O/S Image Deployer RackN Digital Rebar APLv2
OOB & Firmware RackN Digital Rebar APLv2
Utility Workflows RackN Digital Rebar APLv2
O/S Install Templates Mixed Digital Rebar APLv2
Platform Agents (Runner) Digital Rebar APLv2 Digital Rebar APLv2
CLI Digital Rebar APLv2 Digital Rebar APLv2
Sledgehammer Digital Rebar APLv2 Digital Rebar APLv2
API Digital Rebar APLv2 Digital Rebar APLv2
Enterprise Extensions (Multi-Site, SSO, RBAC) RackN RackN
Web UX RackN RackN
API Implementation Digital Rebar APLv2 RackN
Commercial Support RackN RackN
%d bloggers like this: