Introduction

OS deployment methods
CAUTION 

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 driver or firmware update that your hardware vendor advises for RHEL.

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

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

Note: Before you deploy any NSP software in a VMware VM, you must install the latest VMware Tools software.

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 

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.

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 

WARNING

System Failure

You must not attempt to apply an OS update as described below on a system that is not deployed as described in this guide, or catastrophic system failure may result. For example, applying the OS update on an NSP appliance host or NSP Server host results in the uninstallation of virsh and virt-manager, and causes all VMs to be removed.

You must perform the OS-update procedure only on a system deployed as described in this 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.