RBFS Installation

Before you start the installation process, download the RtBrick Host image. For details on downloading the RtBrick Host image, see the RBFS Image Download section.

RBFS software images are stored in the RtBrick Image Store and can be downloaded after providing the required certificate.

Image stores containing the Host installer images are published on https://releases.rtbrick.com/ and updated when new image versions are available.

The rtb-image command (CLI tool) provided by the rtbrick-imgstore package is used to interact with "image stores".

The RBFS software (NOS) available on the RtBrick Image Store is provided as the RBFS Host installer image for installation on qualified OCP-compliant switches.

In addition to RBFS software, other RtBrick software tools are delivered in Debian package format compatible with Debian 12 (Bookworm). The software delivered as Debian 12 packages includes a set of CLI tools and/or daemons designed to facilitate working with RBFS containers and the RBFS API. Debian package repositories containing these packages are available at /https://releases.rtbrick.com/ and are updated whenever a new version becomes available.

The Open Network Install Environment (ONIE) comes pre-installed on OCP-compliant switches. The ONIE environment is used for installing the RtBrick Host installer image. It provides an environment for installing the RBFS software to run on those switches. For more details about ONIE, see https://opencomputeproject.github.io/onie/.

An RBFS release can be defined as a set of software packages (currently, in the Debian package format). However, it is delivered as an image, either a container image or as a complete Host installation image. The Host installation image may or may not contain a container image pre-installed in it. An image can be defined as the archived root file system of a Linux OS installation with the needed software packages pre-installed and with a default configuration. In the current context, the terms 'RBFS release' and 'image' are used interchangeably.

RBFS uses the following versioning format:

<year>.<release>.<minor>[.<fix>][-<label>

Examples:

24.3.1
24.3.1.1

In the version example 24.3.1, the first number, "24," represents the year 2024. The second number, "3," indicates the release version, where "1" corresponds to the first release of the year, and this number will be incremented with each subsequent release. The third number, "1," denotes the minor release, which will also be incremented with each future minor release.

RtBrick also uses a four-number versioning format, represented as 24.3.1.1. In this format, the fourth number indicates the bug-fix release. Bug-fix releases are delivered only when necessary and are based on an existing RBFS release, such as 24.3.1. The bug-fix release numbers will also be incremented with each subsequent minor release.

Candidate releases will use a label such as "candidate.6", which will be incremented with each subsequent candidate release.

RtBrick images delivered through the RtBrick Image Store and the rtb-image utility have the following attributes:

RtBrick images intended to be installed on supported hardware devices contain format, platform, and model set accordingly to the specific switching hardware.

An image partition is a dedicated storage area on the device where a specific version of the system software image is installed. RBFS Image partition allows the device to install multiple software images (one RBFS image per partition, for example, Image-A and Image-B). Image Partition provides an isolated environment for installing and operating software images without affecting the active system. It allows to install a new image in a partition, and if the new image fails, the system can rollback to the previous functioning image.

Each partition can boot independently. The system can switch between the partitions, if required.

This image partition layout describes how RBFS organizes the storage into logical partitions, each serving a specific purpose.

RtBrick customers use the self-service portal to request access to the RBFS image download servers and request RBFS licenses. Every user of the Self-Service portal is associated with a specific organization, which is determined by the domain of their company email address. For example, all users with an email address under the domain @rtbrick.com are affiliated with RtBrick. If your email domain is not registered with RtBrick, please contact RtBrick Support for assistance.

The Self-Service portal uses OpenID/Connect to delegate user authentication to third-party authorization services. These authorization services ensure the secure storage of user credentials and provide additional security measures, including two-factor authentication and account recovery options for users who may have forgotten their passwords.

The portal suppors three authentication service providers:

When a user logs into the portal for the first time, their membership is created. The member will be assigned to an organization based on the domain of their email address. This domain must be a trusted domain, meaning it should be listed in the trusted domains list of exactly one organization.

GitHub allows users to create new accounts for free. A user must declare their company email address as the public email in their GitHub profile to enable the portal to read the email address during the OpenID/Connect authentication process.

The user must confirm that the portal has permission to access the email address from their user profile for the sign-up process. After the initial sign-up, subsequent logins will not require the user to grant access to their profile again.

Microsoft allows domain administrators to decide which sites can delegate authentication to the Microsoft’s OpenID/Connect authorization services. This adds an additional level of security, because a user can not accidentally share profile data with an untrusted site.

A user will only be prompted for granting the portal access to its profile if the domain administrator has allowed the portal to delegate the login to Microsoft for its organization. In case the portal is not allowed to delegate authentication to Microsoft for the paritcular organization, the user attempting to sign-up to the portal will be prompted to request a domain administrator to grant the portal access to Microsoft authentication services.

In large enterprises with strict security processes granting the portal access to Microsoft authentication service might take a considerable amount of time. An alternative would be to create a GitHub account.