Introduction

OS deployment methods

CAUTION System Support Violation

You must ensure that the NSP supports each update that you apply to a RHEL OS in an NSP deployment. An automated update by a subscription manager may deploy an unsupported RHEL version that you must subsequently roll back.

In order to avoid the accidental deployment of an unsupported RHEL version on an NSP station, it is strongly recommended that you lock the supported release in your RHEL subscription manager. See To lock the RHEL OS version for information.

Before you attempt to deploy the RHEL OS in an NSP system, you must review the NSP Planning Guide and the NSP and CLM Host Environment Compatibility Reference for information about the RHEL OS support by NSP release.

Note: It is strongly recommended to install any OS, driver, or firmware update that your hardware vendor advises for RHEL.

You can install the required RHEL OS instance for an NSP component by:

• deploying an NSP disk image, as described in NSP disk-image deployment

• manually, as described in Manual NSP RHEL OS installation

Note: Deploying an NSP disk image is the recommended method.

Note: It is strongly recommended that you verify the message digest of each NSP image file or software bundle that you download from the Nokia Support portal. The download page includes the MD5, SHA256, and SHA512 checksums for comparison with the output of the RHEL md5sum, sha256sum, or sha512sum command. See the associated RHEL man page for command usage information.

Note: The Bash shell is the supported command shell for RHEL CLI operations.

Time synchronization requirement

CAUTION Service Degradation

Some components, for example, members of an etcd cluster, fail to trust data integrity in the presence of a time difference. Failing to closely synchronize the system clocks among components complicates troubleshooting and may cause a service outage.

Ensure that you use only the time service described in this section to synchronize the NSP components.

The system clocks of the NSP components must always be closely synchronized. The RHEL chronyd service is the mandatory time-synchronization mechanism that you must engage on each NSP component during deployment.

Note: Only one time-synchronization mechanism can be active in an NSP system. Before you enable chronyd on an NSP component, you must ensure that no other time-synchronization mechanism, for example, the VMware Tools synchronization utility, is enabled.

Required RHEL 8 swappiness workaround

As noted by Red Hat, the RHEL 8 swappiness setting is ineffective. Special configuration is required to resolve the issue on a RHEL OS instance. Red Hat provides corrective steps that you must perform on any RHEL OS instance that is designated to host any of the following NSP components:

• NSP Flow Collector

• NSP Flow Collector Controller

• collocated NSP Flow Collector Controller and Flow Collector

• NSP analytics server

• NFM-P:

  • main server

  • main database

  • collocated main server and database

  • auxiliary server

  • auxiliary database

Note: You must apply the RHEL workaround before you attempt to deploy any NSP software on the OS instance.

To apply the RHEL 8 swappiness workaround describes how to apply the workaround, which configures the RHEL OS to use cgroups v2 rather than v1.

OS security

The NSP includes various security mechanisms and system hardening options. The following topics describe established or configurable during RHEL OS installation.

RHEL 8 crypto-policy setting

The NSP provides system-wide support for a RHEL 8 crypto-policy setting of FUTURE. The setting is enabled and preconfigured on an OS instance deployed using an NSP RHEL OS OEM image.

A manually deployed OS instance, however, requires the creation of a custom sub-policy, as described in To enable the NSP crypto-policy function on a manually installed RHEL OS.

SELinux

All NSP components support deployment on a RHEL OS that has SELinux enabled in permissive or enforcing mode, except an auxiliary database, which supports SELinux only in permissive mode.

You cannot upgrade an NSP component on which SELinux is enabled in enforcing mode, so must switch to permissive mode before the upgrade. Switching to SELinux enforcing mode is done only after a component installation or upgrade.

Note: An NSP RHEL disk image has SELinux enabled in permissive mode by default.

See “What is SELinux?” in the NSP System Administrator Guide for information about enabling and troubleshooting SELinux in an NSP system, and about switching between SELinux permissive mode and enforcing mode.

Removing executable world permissions

Optionally, you can remove the world permissions from RHEL compiler executable files, as described in Resetting GCC-compiler file permissions.

Applying OS updates

WARNING System Failure

Attempting to apply the OS update described below on a station that is not described in this guide may result in a catastrophic failure.

You must perform the OS-update procedure only on a station whose deployment is described in the NSP Installation and Upgrade guide.

If you are upgrading the NSP in a VM created using an NSP RHEL OS disk image, you must apply a RHEL update to the OS before you can upgrade the component, as described in To apply a RHEL update to an NSP image-based OS.

Note: If the upgrade includes a migration to a new RHEL OS version, for example, an upgrade from NSP Release 22.6 or earlier, the update is included in the new OS image that you deploy, so you do not need to perform the procedure.