RBFS Installation Overview

RBFS software images are available in the RtBrick Image Store, allowing users to download and install the images for specific roles on supported hardware platforms. All the latest versions of RBFS software images are available in the RtBrick image store. For a complete list of the supported hardware platforms, see Supported Platforms section of the Platform Guide.

Access to Image Store and Debian package repositories on /https://releases.rtbrick.com/ is restricted through the use of TLS mutual authentication with TLS client certificates.

It is essential to familiarize with the components listed below before beginning the RBFS Image Download process.

  • RtBrick Image Store: RBFS software images are stored in the RtBrick Image Store and can be downloaded after meeting licensing requirements.

    • Image stores containing the RBFS ONL installer images are published on /https://releases.rtbrick.com/ and updated when new image versions are avaizlable.

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

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

  • RtBrick Tools: In addition to RBFS software, other RtBrick software tools are delivered in Debian package format compatible with Ubuntu. Currently, the only supported Ubuntu release is 22.04 LTS (Jammy). The software delivered as Debian 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.

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

Understanding RBFS Release Versioning

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 (LXC/LXD) image or as a complete ONL installation image. The ONL 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
24.3.1-candidate.6

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.

Understanding the RBFS Image Formats

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

  • format: This is the file format in which the image is packaged and archived. The available format is onl-installer.

  • role: The role inside a network of the device which will be running the image. For example, consolidated-bng signifies the full BNG functionality on a single image.

  • platform: Identifies the hardware platform in which the image can run. For example, q2a signifies the switch ASIC Broadcom Qumran-2A.

  • model: Identifies the hardware model. For example, s9510-28dc signifies the hardware model UfiSpace S9510-28DC.

  • ver-range: Identifies the image version. For example, 24.8.1 signifies the RBFS release 24.8.1.

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

You can see this using sudo rtb-image list command and look for the Format column.

Downloading the RBFS Image

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

Installation Modes

After downloading the RBFS software image, you can install it in any of the following modes:

  1. RBFS Manual Installation: In this mode, you install RBFS ONL installer on a new switch without manually using the ONIE install environment. For detailed step-by-step instructions on the manual installation process, see section RBFS Manual Installation.

  2. RBFS Automated Installation: In this mode, you install RBFS on a new switch by using Zero Touch Provisioning (ZTP). For detailed step-by-step instructions on the automated installation process, see section RBFS Automated Installation (Zero Touch Provisioning).

Self-Service Portal Sign-Up / Sign-In

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:

  • GitHub

  • Google

  • Microsoft

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.

Attempts to sign up / sign in to the portal with an email address of an untrusted domain will be rejected.
GitHub

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.

A user cannot sign up / sign in to the portal if the portal is not allowed to read the user’s email address.
Google

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

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.

Using the Self-Service Portal

The Self-Service Portal can be used for generating and uploading client certificates. Also, it is required for obtaining new RBFS licenses or extend the existing licenses. For more information, see the Uploading the Certificate to the Self-Service Portal section of the RBFS Image Download Guide and Managing Licenses via Self-Service Portal section of the RBFS Licensing Guide.