Centralized License Manager Release 20.9
Installation and Upgrade Guide
3HE-16174-AAAC-TQZZA Issue 1 September 2020 CLM
Legal notice
Nokia is a registered trademark of Nokia Corporation. Other products and company names mentioned herein may be trademarks or tradenames of their respective owners.
The information presented is subject to change without notice. No responsibility is assumed for inaccuracies contained herein.
© 2020 Nokia.
Release 20.9 September 2020 2 3HE-16174-AAAC-TQZZA Issue 1 Contents CLM
Contents
About this document...... 5
1 Pre-installation ...... 7 1.1 Introduction ...... 7 1.2 Operating system specifications ...... 7 1.3 RHEL OS deployment in a VM...... 8 1.4 To deploy the RHEL OS for CLM using a qcow2 image...... 8 1.5 To apply a CLM RHEL qcow2 OS update ...... 13 1.6 Manual RHEL OS installation requirements...... 15 1.7 Virtual machine requirements...... 29 1.8 VMware Virtualization...... 30 1.9 KVM virtualization ...... 31 1.10 OpenStack requirements ...... 31 1.11 Platform requirements...... 32 1.12 CLM disk partitioning...... 33 1.13 To configure a CLM disk partition created after the RHEL OS installation ...... 34 1.14 Securing the CLM ...... 35 1.15 Operating system security for CLM workstations...... 36 1.16 Port information...... 36 1.17 CLM firewall rules and NAT...... 38
2 Standalone installation and upgrade ...... 41 2.1 Introduction ...... 41 2.2 To install a standalone CLM system...... 48 2.3 To upgrade a standalone CLM server ...... 50
3 Redundant installation and upgrade...... 53 3.1 Introduction ...... 53 3.2 To install a redundant CLM system ...... 53 3.3 To upgrade redundant CLM servers...... 55 3.4 To convert a standalone CLM system to a redundant CLM system...... 58
4 Post-installation activities...... 61 4.1 Introduction ...... 61 4.2 Configuring and enabling User Access Control...... 61 4.3 To uninstall a CLM system ...... 63 4.4 To enable CLM notification forwarding to NSP Fault Management application...... 64
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 3 Contents CLM
4.5 To change CLM application settings ...... 66
5 CLM user accounts and security...... 69 5.1 Introduction ...... 69 5.2 CLM and RHEL user accounts...... 69 5.3 CLM authentication ...... 69 5.4 CLM login security...... 70 5.5 To suppress security warnings in CLM browser sessions...... 70 5.6 CLM TLS configuration and management...... 71 5.7 To configure and enable a PKI server ...... 73 5.8 To migrate to the PKI server...... 77 5.9 To generate TLS keystore and truststore files...... 78 5.10 Data privacy ...... 82 5.11 To configure the CLM security statement...... 83 5.12 To update the supported CLM TLS versions and ciphers ...... 84
6 Backup and restore...... 89 6.1 Introduction ...... 89 6.2 To manually backup the PostgreSQL database ...... 89 6.3 To restore the PostgreSQL database...... 90
A Obtaining CLM software and documentation...... 93 A.1 Software ...... 93 A.2 Documentation ...... 93
B How do I perform a manual switchover? ...... 97 B.1 To execute a manual switchover of a redundant CLM system...... 97
Release 20.9 September 2020 4 3HE-16174-AAAC-TQZZA Issue 1 About this document CLM
About this document
Purpose The CLM Installation and Upgrade Guide provides detailed information regarding the installation of the CLM, including pre- and post-installation activities.
Safety information For your safety, this document contains safety statements. Safety statements are given at points where risks of damage to personnel, equipment, and operation may exist. Failure to follow the directions in a safety statement may result in serious consequences.
Document support
Customer documentation and product support URLs: • Documentation Center • Technical support
How to comment Documentation feedback
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 5 About this document CLM
Release 20.9 September 2020 6 3HE-16174-AAAC-TQZZA Issue 1 Pre-installation CLM Introduction
1 Pre-installation
1.1 Introduction
1.1.1 Overview
CAUTION
Service Disruption A CLM instance is node-locked to the server where it is installed. Network Pool Keys issued by Nokia are tied to a specific CLM instance by its UUID. Resource and network parameters associated with the CLM server shall not be altered after Network Pool Keys are received for a specific CLM instance. An operator may migrate a CLM instance within a VM environment only if the server resource and network characteristics remain constant. This chapter provides information and procedures that may need to be understood/performed prior to installing or upgrading the CLM.
1.2 Operating system specifications
1.2.1 Red Hat Enterprise Linux (RHEL) description and recommendations The CLM is supported on the following base RHEL versions: • RHEL server 7 x86-64 - Update 3 (7.3) • RHEL server 7 x86-64 - Update 4 (7.4) • RHEL server 7 x86-64 - Update 5 (7.5) • RHEL server 7 x86-64 - Update 6 (7.6) • RHEL server 7 x86-64 - Update 7 (7.7) • RHEL server 7 x86-64 - Update 7 (7.8) Previous releases, or other variants of Red Hat, and other Linux variants are not supported. The Nokia provided RHEL OS qcow2 image is based upon RHEL 7.8. The CLM does not support all functionality provided in RHEL.
Note: SELinux, iptables, and Network Manager are not supported in CLM configurations.
Note: The CLM should use a time synchronization mechanism, such as NTP, to ensure accurate time.
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 7 Pre-installation CLM RHEL OS deployment in a VM
Note: The CLM requires that the server hostname is configured in the /etc/hosts file. RHEL must be installed in 64 bit mode where the CLM will be installed. Customers are expected to purchase RHEL software and support for all platforms running RHEL Server with the CLM. It is strongly recommended to purchase a support package from Red Hat that provides 24x7 support. Nokia recommends the installation of any OS, driver, or firmware updates that the hardware vendor advises for RHEL. With the exception of documented Operating System parameter changes for CLM, all other settings must be left at the RHEL default configuration.
1.2.2 Third-party applications Applications that are not sanctioned by Nokia must not be running on any virtual instance running the CLM. Nokia reserves the right to remove any applications that are suspected of causing issues from workstations running CLM.
1.3 RHEL OS deployment in a VM
1.3.1 Description You can install the required RHEL OS for CLM using a qcow2 disk image. The image contains only the RHEL OS, and does not include any product-specific packages or application files. After you deploy the image as described in 1.4 “To deploy the RHEL OS for CLM using a qcow2 image” (p. 7), you can install and upgrade the CLM software in the VM.
Note: The OS installation includes all required and optional packages. See 1.6.3 “Required RHEL environment and OS packages” (p. 16) for a list of the required and optional packages.
1.4 To deploy the RHEL OS for CLM using a qcow2 image
1.4.1 Purpose This procedure describes how to create one or more RHEL OS instances for the installation of CLM servers.
Note: You require the following user privileges on each server station in the system: • root • nsp
Note: The following RHEL CLI prompts in command lines denote the active user, and are not to be included in typed commands: • # —root user • bash$ —nsp user
Release 20.9 September 2020 8 3HE-16174-AAAC-TQZZA Issue 1 Pre-installation CLM To deploy the RHEL OS for CLM using a qcow2 image
1.4.2 Steps
Prepare required images
1 Log in to the VM host station as the root user.
2 Download the following file from the CLM downloads page on the Nokia Support portal to a local directory on the station: • NSP_RHEL7_yy_mm.qcow2 where yy_mm represents the year and month of the file issue
3 Open a console window.
4 For each VM that you require, enter the following to create a raw VM disk image file: # qemu-img convert -f qcow2 qcow2_file -O raw -S 0 raw_image.img ↵ where qcow2_file is the name of the downloaded qcow2 file raw_image is the name that you want to assign to the image; for example, CLM_Server_A
5 Perform one of the following: a. If you want only one disk to contain all OS, product software, and data files on a VM, you must resize the VM disk image in accordance with your Platform Sizing Response. For each one-disk VM that you require, enter the following: # qemu-img resize "raw_image.img" sizeG ↵ where raw_image is the raw disk image name specified in Step 4 size is the required disk size, in Gbytes b. If you want more than one disk in a VM, for example, one for the OS, and one for CLM software and data, or separate disks for specific partitions, you must create a separate raw image for each required disk. The disk size must be in accordance with your Platform Sizing Response. For each separate disk image that you require, enter the following: # qemu-img create -f raw "raw_image.img" sizeG ↵ where
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 9 Pre-installation CLM To deploy the RHEL OS for CLM using a qcow2 image
raw_image is the name that you want to assign to the disk image; for example, CLM_ Server_A_Complete, for an image that is to contain all CLM server partitions, or CLM_ Server_A_Software, for an image that is to contain only the /opt/nsp partition size is the required disk size, in Gbytes
6 The raw image files that you create in Step 5 are in sparse format; conversion of an image file to non-sparse format provides optimal disk performance.
Note: Non-sparse format is strongly recommended. For each disk image created in Step 5 that you want to convert to non-sparse format, enter the following: # cp --sparse=never raw_image.img non-sparse_raw_image.img ↵ raw_image is a raw disk image name specified in Step 5 non-sparse_raw_image is the name to assign to the non-sparse image
Deploy VMs
7 For each VM, enter the following to deploy the VM: # virt-install --connect qemu:///system --ram RAM --vcpu=cores -n instance --os-type=linux --os-variant=rhel7 --disk path="image_1", device=disk,bus=virtio,format=raw,io=native,cache=none --disk path="image_2", device=disk,bus=virtio,format=raw,io=native,cache=none --disk path="image_n", device=disk,bus=virtio,format=raw,io=native, cache=none --network bridge=bridge_name --import ↵ where RAM is the required amount of RAM specified in your Customer Sizing Response cores is the required number of vCPU cores specified in your Customer Sizing Response instance is the name to assign to the VM image_1, image_2, and image_n are the raw disk images created for the VM bridge_name is the name of the network bridge for a VM interface
Note: One “--network bridge=bridge_name” entry is required for each VM interface that you intend to configure.
8 Log in to the new VM as the root user; the default password is available from technical support.
9 Configure the RHEL OS as required for the CLM server; for example: • Plumb the required IPv4 and IPv6 addresses.
Release 20.9 September 2020 10 3HE-16174-AAAC-TQZZA Issue 1 Pre-installation CLM To deploy the RHEL OS for CLM using a qcow2 image
• Set the hostname. • Update the /etc/hosts file.
10 Perform one of the following; see 1.12 “CLM disk partitioning” (p. 33) for specific disk partitioning information.
Note: If you are using multiple disks in a VM, you must mount a parent partition before you mount any child partition. For example, you cannot mount the /var/log/audit partition before you mount the /var/log partition. a. If you are using only one disk per VM, perform the following steps for each such VM. 1. Enter the following commands: # mkdir -p /extra ↵ # mkdir -p /opt/nsp ↵ 2. Use the RHEL fdisk utility to create the required sub-disks for the following directories: • /extra • /opt/nsp • /var/log • /var/log/audit For each directory, enter the following and respond to the prompts; specify the directory size from your Platform Sizing Response: # fdisk /dev/virtual_device ↵ where virtual_device is the virtual device name, for example, vda in a KVM VM 3. Enter the following to reboot the VM: # systemctl reboot ↵ 4. After the reboot, perform one of the following. a. If you are using LVM, perform the following steps. 1. Enter the following sequence of commands for each sub-disk: # pvcreate /dev/virtual_devicen ↵ # vgcreate vg2 /dev/virtual_devicen ↵ where virtual_device is the virtual device name, for example, vda in a KVM VM n is the number associated with the sub-disk 2. Go to Step 11. b. If you are not using LVM, perform the following steps. 1. Enter the following for each sub-disk: # mkfs.ext4 -L path /dev/devicen ↵ where path is the directory path associated with the sub-disk, for example, /opt/nsp device is the device name, for example, vda in a KVM VM n is the device number associated with the sub-disk 2. Open the /etc/fstab file using a plain-text editor such as vi.
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 11 Pre-installation CLM To deploy the RHEL OS for CLM using a qcow2 image
3. Add one line in the following format for each sub-disk: /dev/virtual_devicen path fs_type defaults 0 0 where device is the device name, for example, vda in a KVM VM n is the number associated with the sub-disk path is the directory path associated with the sub-disk, for example, /opt/nsp fs_type is the file system type, which is ext4 for all sub-disks except /var/log and /var/ log/audit, for which it is xfs 4. Save and close the file. 5. Enter the following: # mount -a ↵ 6. Go to Step 12. b. If you specify multiple disks per VM and are using LVM, enter the following sequence of commands for each disk in each VM: # pvcreate /dev/device ↵ # vgcreate group /dev/device ↵ where device is the device name for the disk group is the name to assign to the volume group, and must be unique in the VM
Configure LVM
11 Create the LVM volumes and partitions. Perform the following steps for each disk in a VM, beginning with the parent disk partitions.
Note: If you are using multiple disks in a VM, you must mount a parent partition before you mount any child partition. For example, you cannot mount the /opt/nsp/nfmp/ nebackup partition before you mount the /opt/nsp partition.
Note: The /extra partition is allocated for use as a temporary storage location for downloaded product software. 1. Enter the following to create a logical volume: # lvcreate -n volume -L sizeG group /dev/device ↵ where volume is the name to assign to the logical volume size is the volume size from your Platform Sizing Response group is the name to assign to the volume group, and must be unique in the VM device is the device name 2. Enter the following: # mkdir directory ↵
Release 20.9 September 2020 12 3HE-16174-AAAC-TQZZA Issue 1 Pre-installation CLM To apply a CLM RHEL qcow2 OS update
where directory is the name of the directory to associate with the volume, for example, /opt/ nsp 3. Enter the following: # mkfs.ext4 -L directory /dev/group/volume ↵ where directory is the directory associated with the volume group is the volume group volume is the logical volume name 4. Open the /etc/fstab file using a plain-text editor such as vi. 5. Add an entry in the following format: /dev/group/partition directory fs_type noatime 0 0 where group is the volume group partition is the partition name directory is the associated directory path fs_type is the file system type, which is one of the following: • ext4, for all partitions except /var/log and /var/log/audit • xfs, for the /var/log and /var/log/audit partitions 6. Save and close the file. 7. Enter the following: # mount -a ↵
Install and configure product software
12 Install and configure the CLM server software on the VMs.
Note: The /extra partition is allocated for use as a temporary storage location for downloaded product software.
END OF STEPS
1.5 To apply a CLM RHEL qcow2 OS update
1.5.1 Description If you are upgrading the CLM in a VM created using the CLM RHEL OS qcow2 image described in 1.4 “To deploy the RHEL OS for CLM using a qcow2 image” (p. 8), you must apply a RHEL update to the OS before you can upgrade the component.
Note: The procedure applies only to a VM OS deployed using the CLM RHEL OS qcow2 image.
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 13 Pre-installation CLM To apply a CLM RHEL qcow2 OS update
Note: If required, you can roll back an applied update by using the ‘yum history’ command to do the following. 1. Obtain the yum transaction ID. 2. Undo the transaction. See the RHEL OS documentation for more information.
1.5.2 Steps
1 Log in to the server station as the root user.
2 Open a console window.
3 Enter the following to stop the server: # nspdctl stop ↵
4 Enter the following: # mkdir -p /opt/OSUpdate ↵
5 Download the following compressed file for the new CLM release to the /opt/OSUpdate directory: NSP_RHELn_QCOW2_UPDATE_yy_mm.tar.gz where n is the major RHEL version, for example, 7 yy.mm is the issue date of the OS update
6 Enter the following: # cd /opt/OSUpdate ↵
7 Enter the following to expand the downloaded file: # tar -zxvf NSP_RHELn_QCOW2_UPDATE_yy_mm.tar.gz ↵ The update files are extracted to the following directory: /opt/OSUpdate/rhelversion-yy.mm.dd where
Release 20.9 September 2020 14 3HE-16174-AAAC-TQZZA Issue 1 Pre-installation CLM Manual RHEL OS installation requirements
version is the RHEL version, for example, 7.5 yy.mm.dd is the issue date of the OS update
8 Enter the following: # cd rhelversion-yy.mm.dd ↵
9 Enter the following to install the update: # yum install * ↵
10 Enter the following: # systemctl reboot ↵ The station reboots.
11 After the reboot, remove the /opt/OSUpdate directory to conserve disk space.
12 Applying the update may leave outdated and inactive OS kernel instances on the station. To remove any previous kernel instances, enter the following as the root user: # package-cleanup --oldkernels --count=1 ↵
13 Close the console window.
END OF STEPS
1.6 Manual RHEL OS installation requirements
1.6.1 Introduction
CAUTION
Upgrade Failure The CLM system locale must remain unchanged after the initial system installation; otherwise, a system upgrade fails. Ensure that you set the system locale only before CLM system installation, and not afterward. This section describes the manual RHEL OS installation requirements for a CLM system.
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 15 Pre-installation CLM Manual RHEL OS installation requirements
Each CLM server requires the following: • a specific RHEL Software Selection as the base environment • the installation and removal of specific OS packages
Note: The RHEL rpm utility requires hardware driver files in binary format. If the RHEL driver files provided by your server hardware vendor are in source rpm format, you may need to install additional packages in order to compile the files into binary format. See the station hardware documentation for information.
Note: The RHEL SELinux function is not supported; you must disable this function before you attempt to install or upgrade the CLM.
1.6.2 Using the yum utility To simplify package management, Nokia recommends that you use the RHEL yum utility to install and remove OS packages. The package installation syntax is the following: yum -y install package_1 package_2 ... package_n ↵ The package removal syntax is the following: yum -y remove package_1 package_2 ... package_n ↵
Note: Package installation using yum requires a yum repository. The following repository types are available: • local repository, which you can create during the RHEL OS installation • Internet-based repository, which you can access after you register with the Red Hat Network See the RHEL documentation for information about setting up a yum repository.
Note: If a package has dependencies on one or more additional packages that are not listed in the package documentation, the yum utility installs the additional packages.
1.6.3 Required RHEL environment and OS packages During the RHEL OS installation for a CLM server, you must do the following.
Note: After you complete the process below, you must reboot the CLM server. 1. Specify “Minimal Install” as the Software Selection in the RHEL installer. 2. Install specific OS packages, as described in 1.6.4 “RHEL OS packages to install” (p. 17). 3. Remove specific OS packages, as described in 1.6.5 “RHEL OS packages to remove” (p. 21). 4. Perform RHEL version-specific package actions; see 1.6.6 “Additional package requirements” (p. 23). 5. Optionally, install one or more packages listed in 1.6.7 “Optional RHEL OS packages” (p. 29).
Release 20.9 September 2020 16 3HE-16174-AAAC-TQZZA Issue 1 Pre-installation CLM Manual RHEL OS installation requirements
1.6.4 RHEL OS packages to install
CAUTION
Risk of excessive resource consumption The RHEL gnome desktop may consume excessive memory and result in system performance degradation. The CLM does not require the gnome desktop, which is provided for customer and support convenience. It is recommended that you disable the gnome desktop on CLM if you do not require the gnome desktop. You can stop the gnome desktop using the following command as the root user: systemctl stop gdm ↵ To disable the gnome desktop so that it does not start after a station reboot, enter the following as the root user: systemctl disable gdm ↵ You must install a set of RHEL OS packages that are common to each CLM server. Most of the common packages are available from the RHEL ISO disk image and the default RHEL package repository. Such packages are listed in “Required packages, RHEL ISO image or default RHEL repository” (p. 16). You must also install additional packages that are available only from the RHEL optional package repository. Such packages are listed in “Required packages, RHEL optional package repository” (p. 21).
Required packages, RHEL ISO image or default RHEL repository The RHEL ISO image and default package repository each contain the following OS packages that you must install. To facilitate the package installation, you can paste the following command block in a CLI:
yum -y install @base @gnome-desktop @legacy-x @x11 yum -y install autofs bc.x86_64 binutils.x86_64 compat-libcap1.x86_64 yum -y install copy-jdk-configs-3.3 cups-client.x86_64 cups-libs.x86_64 yum -y install dialog elfutils-libelf-devel.x86_64 elfutils.x86_64 yum -y install firefox.x86_64 ftp gcc.x86_64 gcc-c++.x86_64 glibc.i686 yum -y install glibc.x86_64 glibc-devel.i686 glibc-devel.x86_64 yum -y install gtk2.i686 haproxy.x86_64 hdparm.x86_64 irqbalance.x86_64 yum -y install javapackages-tools keepalived.x86_64 yum -y install keyutils-libs-devel.x86_64 krb5-devel.x86_64 ksh.x86_64 yum -y install libaio.i686 libaio.x86_64 libaio-devel.i686 yum -y install libaio-devel.x86_64 libcom_err-devel.x86_64 yum -y install libffi-devel.x86_64 libgcc.i686 libgcc.x86_64 yum -y install libgcrypt-devel.x86_64 libgpg-error-devel.x86_64 yum -y install libibverbs.x86_64 libkadm5.x86_64 yum -y install libselinux-devel.x86_64 libsepol-devel.x86_64
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 17 Pre-installation CLM Manual RHEL OS installation requirements
yum -y install libstdc++.i686 libstdc++.x86_64 libstdc++-devel.i686 yum -y install libstdc++-devel.x86_64 libverto-devel.x86_64 libXi.i686 yum -y install libXi.x86_64 libxml2-devel.x86_64 libXrender.i686 yum -y install libxslt-devel.x86_64 libXtst.i686 libXtst.x86_64 yum -y install lksctp-tools.x86_64 lshw.x86_64 lsof.x86_64 make.x86_64 yum -y install man mcelog net-snmp net-snmp-utils ntp yum -y install numactl-devel.i686 numactl-devel.x86_64 openssh.x86_64 yum -y install openssh-askpass.x86_64 openssh-clients.x86_64 yum -y install openssh-server.x86_64 openssl-devel.x86_64 yum -y install pcre-devel.x86_64 procps pcsc-lite-libs.x86_64 yum -y install pyldb.x86_64 pytalloc.x86_64 python-devel.x86_64 yum -y install python-javapackages python-tdb.x86_64 yum -y install redhat-lsb-core.x86_64 redhat-lsb-submod-security.x86_64 yum -y install rsync.x86_64 samba-libs.x86_64 tcpdump.x86_64 yum -y install tzdata-java-2020a unzip.x86_64 which xinetd.x86_64 yum -y install xz-devel.x86_64 zip.x86_64
Table 1-1 Required OS packages from default RHEL repository or ISO image
Package Description
@base Base package group
@gnome-desktop Gnome package group
@legacy-x Legacy X package group
@x11 X11 package group
autofs A tool for automatically mounting and unmounting filesystems
bc.x86_64 GNU's bc (a numeric processing language) and dc (a calculator)
binutils.x86_64 A GNU collection of binary utilities
compat-libcap1.x86_64 Library for getting and setting POSIX.1e capabilities
copy-jdk-configs 1 JDK configuration files copier
cups-client.x86_64 CUPS printing system - client programs
cups-libs.x86_64 CUPS printing system - libraries
dialog A utility for creating TTY dialog boxes
elfutils.x86_64 A collection of utilities and DSOs to handle compiled objects
elfutils-libelf-devel.x86_64 Development support for libelf
firefox.x86_64 Mozilla Firefox web browser
ftp The standard UNIX FTP client
gcc.x86_64 Various compilers, for example, C, C++, Objective-C, and Java
gcc-c++.x86_64 C++ support for GCC
glibc.i686 The GNU libc libraries
glibc.x86_64 The GNU libc libraries
Release 20.9 September 2020 18 3HE-16174-AAAC-TQZZA Issue 1 Pre-installation CLM Manual RHEL OS installation requirements
Table 1-1 Required OS packages from default RHEL repository or ISO image (continued)
Package Description
glibc-devel.i686 Object files for development using standard C libraries
glibc-devel.x86_64 Object files for development using standard C libraries
gtk2.i686 The GIMP ToolKit (GTK+), a library for creating GUIs for X
haproxy.x86_64 TCP/HTTP proxy and load balancer for high availability environments
hdparm.x86_64 Utility for displaying and/or setting hard disk parameters
irqbalance.x86_64 Daemon that evenly distributes IRQ load across multiple CPUs
javapackages-tools 1 Macros and scripts for Java packaging support
keepalived.x86_64 Load balancer and high availability service
keyutils-libs-devel.x86_64 Development package for building Linux key management utilities
krb5-devel.x86_64 Development files needed to compile Kerberos 5 programs
ksh.x86_64 The Original ATT Korn Shell
libaio.i686 Linux-native asynchronous I/O access library
libaio.x86_64 Linux-native asynchronous I/O access library
libaio-devel.i686 Development files for Linux-native asynchronous I/O access
libaio-devel.x86_64 Development files for Linux-native asynchronous I/O access
libcom_err-devel.x86_64 Common error description library
libffi-devel.x86_64 GCC development for FFI
libgcc.i686 GCC version 4.8 shared support library
libgcc.x86_64 GCC version 4.4 shared support library
libgcrypt-devel.x86_64 Development files for the libgcrypt package
libgpg-error-devel.x86_64 Development files for the libgpg-error package
libibverbs.x86_64 Core user space library that implements hardware abstracted verbs protocol
libkadm5.x86_64 Kerberos 5 Administrative libraries
libselinux-devel.x86_64 Header files and libraries used to build SELinux
libsepol-devel.x86_64 Header files and libraries used to build policy manipulation tools
libstdc++.i686 GNU Standard C++ Library
libstdc++.x86_64 GNU Standard C++ Library
libstdc++-devel.i686 Header files and libraries for C++ development
libstdc++-devel.x86_64 Header files and libraries for C++ development
libverto-devel.x86_64 Development files for libverto
libXi.i686 X.Org X11 libXi runtime library
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 19 Pre-installation CLM Manual RHEL OS installation requirements
Table 1-1 Required OS packages from default RHEL repository or ISO image (continued)
Package Description
libXi.x86_64 X.Org X11 libXi runtime library
libxml2-devel.x86_64 Libraries, includes, etc. to develop XML and HTML applications
libXrender.i686 X.Org X11 libXrender runtime library
libxslt-devel.x86_64 Development libraries and header files for libxslt
libXtst.i686 X.Org X11 libXtst runtime library
libXtst.x86_64 X.Org X11 libXtst runtime library
lksctp-tools 1 User-space access to Linux Kernel SCTP
lshw.x86_64 Hardware lister
lsof.x86_64 Provides a utility to list information about open files
make.x86_64 GNU tool which simplifies the build process for users
man A set of documentation tools: man, apropos and whatis
mcelog Tool to translate x86-64 CPU Machine Check Exception data
net-snmp SNMP Agent Daemon and documentation
net-snmp-utils SNMP clients such as snmpget and snmpwalk
ntp The NTP daemon and utilities
numactl-devel.i686 Development package for building Applications that use numa
numactl-devel.x86_64 Development package for building Applications that use numa
openssh.x86_64 Open source implementation of SSH protocol versions 1 and 2
openssh-askpass.x86_64 Passphrase dialog for OpenSSH and X
openssh-clients.x86_64 Open-source SSH client application
openssh-server.x86_64 Open source SSH server daemon
openssl-devel.x86_64 Files for development of applications which will use OpenSSL
pcre-devel.x86_64 Development files for PCRE
pcsc-lite-libs 1 PC/SC Lite libraries
procps OS utilities for /proc
pyldb.x86_64 1 Python bindings for the LDB library
pytalloc.x86_64 1 Developer tools for the Talloc library
python-devel.x86_64 The libraries and header files needed for Python development
python-javapackages 1 Module for handling various files for Java packaging
python-tdb.x86_64 1 Python bindings to Samba's tdb embedded database
redhat-lsb-core.x86_64 LSB Core module support
Release 20.9 September 2020 20 3HE-16174-AAAC-TQZZA Issue 1 Pre-installation CLM Manual RHEL OS installation requirements
Table 1-1 Required OS packages from default RHEL repository or ISO image (continued)
Package Description
redhat-lsb-submod-security.x86_64 LSB Security submodule support
rsync.x86_64 A program for synchronizing files over a network
samba-libs.x86_64 1 Common libraries used by both Samba servers and clients
tcpdump.x86_64 Command-line packet analyzer and network traffic capture; used by technical support for debugging
tzdata-java 1 Timezone data for Java
unzip.x86_64 A utility for unpacking zip files
which Displays where a particular program in your path is located
xinetd.x86_64 A secure replacement for inetd
xz-devel.x86_64 Development libraries and headers for liblzma
zip.x86_64 A file compression utility
Notes: 1. New in Release 20.9
Required packages, RHEL optional package repository The RHEL optional package repository contains the OS packages in Table 1-2, “Required OS packages from RHEL optional package repository” (p. 21) that you must install. To facilitate the package installation, you can paste the following command block in a CLI:
yum -y install compat-libstdc++-33.i686 compat-libstdc++-33.x86_64
Table 1-2 Required OS packages from RHEL optional package repository
Package name Description
compat-libstdc++-33.i686 Compatibility standard C++ libraries
compat-libstdc++-33.x86_64 Compatibility standard C++ libraries
1.6.5 RHEL OS packages to remove After you install the required OS packages on a CLM server station, you must remove packages that are installed by default but not required by the CLM. For all RHEL 7 versions, you must remove the packages listed in Table 1-3, “RHEL OS packages to remove, all RHEL versions” (p. 22). To facilitate the package removal, you can paste the following command block in a CLI:
yum -y remove anaconda-core.x86_64 anaconda-gui.x86_64 yum -y remove anaconda-tui.x86_64 avahi.x86_64 biosdevname yum -y remove chrome-gnome-shell.x86_64 dnsmasq.x86_64
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 21 Pre-installation CLM Manual RHEL OS installation requirements
yum -y remove gnome-boxes.x86_64 initial-setup.x86_64 yum -y remove initial-setup-gui.x86_64 iwl7265-firmware.noarch yum -y remove libstoragemgmt.x86_64 libstoragemgmt-python.noarch yum -y remove libvirt-daemon-config-network.x86_64 yum -y remove libvirt-daemon-driver-network.x86_64 yum -y remove libvirt-daemon-driver-qemu.x86_64 yum -y remove libvirt-daemon-kvm.x86_64 libvirt-gconfig.x86_64 yum -y remove libvirt-gobject.x86_64 yum -y remove NetworkManager-libreswan.x86_64 yum -y remove NetworkManager-libreswan-gnome.x86_64 yum -y remove NetworkManager-team.x86_64 NetworkManager-tui.x86_64 yum -y remove qemu-kvm.x86_64 qemu-kvm-common.x86_64 yum -y remove setroubleshoot.x86_64 setroubleshoot-plugins.noarch yum -y remove setroubleshoot-server.x86_64 yum -y remove subscription-manager-initial-setup-addon.x86_64
Table 1-3 RHEL OS packages to remove, all RHEL versions
Package Description
anaconda-core.x86_64 Core of the Anaconda installer
anaconda-gui.x86_64 Graphical user interface for the Anaconda installer
anaconda-tui.x86_64 Textual user interface for the Anaconda installer
avahi.x86_64 Local network service discovery
biosdevname Utility that provides an optional convention for naming network interfaces
chrome-gnome-shell.x86_64 1 Support for managing GNOME Shell Extensions through web browsers
dnsmasq.x86_64 A lightweight DHCP/caching DNS server
gnome-boxes.x86_64 A simple GNOME 3 application to access remote or virtual systems
initial-setup.x86_64 Initial system configuration utility
initial-setup-gui.x86_64 Graphical user interface for the initial-setup utility
iwl7265-firmware.noarch 1 Firmware for Intel(R) Wireless Adapters
libstoragemgmt.x86_64 Storage array management library
libstoragemgmt-python.noarch Python2 client libraries and plug-in support for libstoragemgmt
libvirt-daemon-config-network.x86_64 Default configuration files for the libvirtd daemon
libvirt-daemon-driver-network.x86_64 Network driver plugin for the libvirtd daemon
libvirt-daemon-driver-qemu.x86_64 Qemu driver plugin for the libvirtd daemon
libvirt-daemon-kvm.x86_64 Server side daemon & driver required to run KVM guests
libvirt-gconfig.x86_64 libvirt object APIs for processing object configuration
libvirt-gobject.x86_64 libvirt object APIs for managing virtualization hosts
NetworkManager-libreswan.x86_64 NetworkManager VPN plugin for libreswan
Release 20.9 September 2020 22 3HE-16174-AAAC-TQZZA Issue 1 Pre-installation CLM Manual RHEL OS installation requirements
Table 1-3 RHEL OS packages to remove, all RHEL versions (continued)
Package Description
NetworkManager-libreswan-gnome. NetworkManager VPN plugin for libreswan - GNOME files x86_64
NetworkManager-team.x86_64 Team device plugin for NetworkManager
NetworkManager-tui.x86_64 NetworkManager curses-based UI
qemu-kvm.x86_64 QEMU metapackage for KVM support
qemu-kvm-common.x86_64 QEMU common files needed by all QEMU targets
setroubleshoot.x86_64 Helps troubleshoot SELinux problem
setroubleshoot-plugins.noarch Analysis plugins for use with setroubleshoot
setroubleshoot-server.x86_64 SELinux troubleshoot server
subscription-manager-initial-setup- Initial setup screens for subscription manager addon.x86_64
Notes: 1. New in Release 20.9
1.6.6 Additional package requirements For some RHEL versions, the CLM requires the addition or removal of specific packages. All RHEL versions require specific versions of some packages. To complete your manual RHEL installation, you must do the following after the package additions and removals described in the preceding sections. 1. Ensure that the required versions of specific packages are installed, as described in “Required package versions” (p. 23). 2. Add or remove packages, as required for your RHEL version: • RHEL 7.3 or 7.4—see “Additional package requirements, RHEL 7.3 and 7.4” (p. 24) • RHEL 7.6, 7.7, or 7.8—see “Additional package requirements, RHEL 7.6, 7.7, and 7.8” (p. 24)
Required package versions The CLM requires the minimum version or later of each RHEL 7 package listed in Table 1-4, “Required RHEL OS package versions” (p. 24). If an installed package version is lower than the minimum, you must upgrade the package to at least the minimum. To facilitate the package upgrade, you can paste the following command block in a CLI:
yum -y install copy-jdk-configs-3.3 nspr.x86_64 yum -y install nss-softokn-freebl.i686 nss-softokn-freebl.x86_64 yum -y install nss-softokn.x86_64 nss-util.x86_64 tzdata-java-2020a
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 23 Pre-installation CLM Manual RHEL OS installation requirements
Table 1-4 Required RHEL OS package versions
Package Minimum required version copy-jdk-configs 3.3 nspr.x86_64 4.19.0-1.el7 nss-softokn-freebl.i686 3.36.0-5.el7 nss-softokn-freebl.x86_64 3.36.0-5.el7 nss-softokn.x86_64 3.36.0-5.el7 nss-util.x86_64 3.36.0-1.el7 tzdata-java 2020a
Additional package requirements, RHEL 7.3 and 7.4
NOTICE
RHEL 7.3 requirement A CLM system on RHEL 7.3 requires openssl-devel.x86_64 version 1.0.2k or later. Before you can upgrade a CLM on RHEL 7.3, you must ensure that the openssl-devel.x86_64 package is at a supported version. For RHEL 7.3 or 7.4, you must remove the packages listed in Table 1-5, “OS packages to remove, RHEL 7.3 or 7.4” (p. 24). To facilitate the package removal, you can paste the following command block in a CLI:
yum -y remove NetworkManager.x86_64 NetworkManager-wifi.x86_64
Note: The packages are required by RHEL 7.5 and later because of a package dependency introduced in RHEL 7.5.
Table 1-5 OS packages to remove, RHEL 7.3 or 7.4
Package Description
NetworkManager.x86_64 Network connection manager and user applications
NetworkManager-wifi.x86_64 Wifi plugin for NetworkManager
Additional package requirements, RHEL 7.6, 7.7, and 7.8 For RHEL 7.6, 7.7, or 7.8, you must do the following: 1. Install the packages in Table 1-6, “Additional OS packages, RHEL 7.6, 7.7, or 7.8” (p. 25). 2. Remove the packages in Table 1-7, “OS packages to remove, RHEL 7.6, 7.7, or 7.8” (p. 27). Table 1-6, “Additional OS packages, RHEL 7.6, 7.7, or 7.8” (p. 25) lists the additional packages that you must install on RHEL 7.6, 7.7, or 7.8.
Release 20.9 September 2020 24 3HE-16174-AAAC-TQZZA Issue 1 Pre-installation CLM Manual RHEL OS installation requirements
To facilitate the package installation, you can paste the following command block in a CLI:
yum -y install bpftool c-ares copy-jdk-configs gcc-gfortran yum -y install hyphen-en javapackages-tools yum -y install javapackages-tools.noarch libcurl-devel.x86_64 yum -y install libgfortran libquadmath libquadmath-devel yum -y install libverto-libevent libyaml-devel.x86_64 yum -y install lksctp-tools.x86_64 nfs-utils orca yum -y install pcsc-lite-libs.x86_64 pyldb.x86_64 pytalloc.x86_64 yum -y install python-babel python-javapackages python-jinja2 yum -y install python-jsonpatch python-jsonpointer yum -y install python-markupsafe python-paramiko python-pillow yum -y install python-prettytable python-pygments python-requests yum -y install python-tdb.x86_64 python-urllib3 python2-oauthlib yum -y install samba-libs.x86_64 socat tigervnc-server.x86_64 yum -y install tzdata-java
Table 1-6 Additional OS packages, RHEL 7.6, 7.7, or 7.8
Package Description
bpftool Inspection and simple manipulation of eBPF programs and maps
c-ares A library that performs asynchronous DNS operations
copy-jdk-configs 1 2 JDK configuration files copier
gcc-gfortran Fortran 95 support for gcc
hyphen-en English hyphenation rules
javapackages-tools 1 2 Macros and scripts for Java packaging support
javapackages-tools.noarch Macros and scripts for Java packaging support
libcurl-devel.x86_64 A Tool for Transferring Data from URLs
libgfortran Fortran runtime
libquadmath GCC __float128 shared support library
libquadmath-devel GCC __float128 support
libverto-libevent libevent module for libvert
libyaml-devel.x86_64 Development files for LibYAML applications
lksctp-tools 1 2 User-space access to Linux Kernel SCTP
nfs-utils NFS utilities and supporting clients and daemons for the kernel NFS server
orca GNOME screen reader for people with visual impairments
pcsc-lite-libs 1 2 PC/SC Lite libraries
pyldb.x86_64 1 2 Python bindings for the LDB library
pytalloc.x86_64 1 2 Developer tools for the Talloc library
python-babel Internationalization utilities
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 25 Pre-installation CLM Manual RHEL OS installation requirements
Table 1-6 Additional OS packages, RHEL 7.6, 7.7, or 7.8 (continued)
Package Description
python-javapackages 1 2 Module for handling various files for Java packaging
python-jinja2 Python template engine
python-jsonpatch Apply JSON-Patches (RFC 6902)
python-jsonpointer Identify specific nodes in a JSON document (RFC 6901)
python-markupsafe XML/HTML/XHTML markup safe string package for Python
python-paramiko SSH2 protocol library
python-pillow Python image processing library
python-prettytable Python library for displaying data in ASCII table format
python-pygments Syntax highlighting package written in Python
python-requests Python HTTP for Humans
python-tdb.x86_64 1 2 Python bindings to Samba's tdb embedded database
python-urllib3 HTTP library with thread-safe connection pooling, file post, and more
python2-oauthlib A Generic Implementation of the OAuth Request-Signing Logic
samba-libs.x86_64 1 2 Common libraries used by both Samba servers and clients
socat Multipurpose relay for bidirectional data transfer
tigervnc-server.x86_64 Server for the VNC remote display system
tzdata-java 1 2 Timezone data for Java
Notes: 1. New in Release 20.9 2. Also listed in Table 1-1, “Required OS packages from default RHEL repository or ISO image” (p. 18); listed in this table for upgrade purposes, and for compatibility with earlier RHEL releases. Nokia recommends including the package in the yum command to ensure that the package is installed. Table 1-7, “OS packages to remove, RHEL 7.6, 7.7, or 7.8” (p. 27) lists the packages that you must remove from RHEL 7.6, 7.7, or 7.8. To facilitate the package removal, you can paste the following command block in a CLI:
yum -y remove anaconda-user-help anaconda-widgets yum -y remove cryptsetup-python cyrus-sasl cyrus-sasl-gssapi yum -y remove daxctl-libs fcoe-utils glade-libs glusterfs-cli yum -y remove gnome-initial-setup ipxe-roms-qemu yum -y remove iscsi-initiator-utils iscsi-initiator-utils-iscsiuio yum -y remove isomd5sum kernel-devel keybinder3 ldns yum -y remove libblockdev-nvdimm libconfig libgovirt libnm-gtk yum -y remove librdmacm libreport-anaconda libreport-plugin-bugzilla yum -y remove libreport-rhel-anaconda-bugzilla libreswan
Release 20.9 September 2020 26 3HE-16174-AAAC-TQZZA Issue 1 Pre-installation CLM Manual RHEL OS installation requirements
yum -y remove libtimezonemap libuser-python yum -y remove libverto-tevent lldpad mtools ndctl ndctl-libs yum -y remove netcf-libs nmap-ncat numad oddjob oddjob-mkhomedir yum -y remove pykickstart pyparted pyserial yum -y remove python-blivet python-coverage python-di yum -y remove python-meh-gui python-nss python-ntplib yum -y remove python-pwquality python-pyblock python2-blockdev yum -y remove python2-subprocess32 pytz radvd realmd seabios-bin yum -y remove seavgabios-bin sgabios-bin spice-server yum -y remove unbound-libs yajl
Table 1-7 OS packages to remove, RHEL 7.6, 7.7, or 7.8
Package Description
anaconda-user-help Anaconda built-in help system
anaconda-widgets A set of custom GTK+ widgets for use with anaconda
cryptsetup-python Python bindings for libcryptsetup
cyrus-sasl Implementation of Cyrus SASL API
cyrus-sasl-gssapi Plugin for the GSSAPI SASL mechanism
daxctl-libs Management library for "Device DAX" devices
fcoe-utils FCoE userspace management tools
glade-libs Widget library for Glade UI designer
glusterfs-cli GlusterFS CLI
gnome-initial-setup GNOME Initial Setup Assistant
ipxe-roms-qemu Network boot loader roms supported by QEMU, .rom format
iscsi-initiator-utils iSCSI daemon and utility programs
iscsi-initiator-utils-iscsiuio Userspace configuration daemon required for some iSCSI hardware
isomd5sum Utilities for working with md5sum implanted in ISO images
kernel-devel Development files needed for building kernel modules
keybinder3 A library for registering global keyboard shortcuts
ldns A library for developing the Domain Name System
libblockdev-nvdimm The NVDIMM plugin for the libblockdev library
libconfig C++ bindings development files for libconfig
libgovirt A GObject library for interacting with oVirt REST API
libnm-gtk Private libraries for NetworkManager GUI support
librdmacm Userspace RDMA Connection Manager
libreport-anaconda Default configuration for reporting anaconda bugs
libreport-plugin-bugzilla libreport's bugzilla plugin
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 27 Pre-installation CLM Manual RHEL OS installation requirements
Table 1-7 OS packages to remove, RHEL 7.6, 7.7, or 7.8 (continued)
Package Description
libreport-rhel-anaconda-bugzilla Default configuration for reporting anaconda bugs to Red Hat Bugzilla
libreswan IPsec implementation with IKEv1 and IKEv2 keying protocols
libtimezonemap Time zone map widget for Gtk+
libuser-python Python bindings for the libuser library
libverto-tevent Python bindings for the libuser library
lldpad Intel LLDP Agent
mtools Tools to access MS-DOS filesystems without kernel drivers
ndctl Manage "libnvdimm" subsystem devices (Non-volatile Memory)
ndctl-libs Management library for "libnvdimm" subsystem devices (Non-volatile Memory)
netcf-libs Libraries for netcf
nmap-ncat Nmap's Netcat replacement
numad Userspace daemon that automatically binds workloads to NUMA node
oddjob A D-Bus service which runs odd jobs on behalf of client applications
oddjob-mkhomedir An oddjob helper which creates and populates home directories
pykickstart A python library for manipulating kickstart files
pyparted Python module for GNU parted
pyserial Python serial port access library
python-blivet A python module for system storage configuration
python-coverage Code coverage measurement for Python
python-di Python library for dependency injection support
python-meh-gui Graphical user interface for the python-meh library
python-nss Python bindings for Network Security Services (NSS)
python-ntplib Python module that offers a simple interface to query NTP servers
python-pwquality Library for password quality checking -- Python bindings
python-pyblock Python modules for dealing with block devices
python2-blockdev Python2 gobject-introspection bindings for libblockdev
python2-subprocess32 Backport of subprocess module from Python 3.2 to Python 2
pytz World Timezone Definitions for Python
radvd A Router Advertisement daemon
realmd Kerberos realm enrollment service
seabios-bin Seabios for x86
Release 20.9 September 2020 28 3HE-16174-AAAC-TQZZA Issue 1 Pre-installation CLM Virtual machine requirements
Table 1-7 OS packages to remove, RHEL 7.6, 7.7, or 7.8 (continued)
Package Description
seavgabios-bin Seavgabios for x86
sgabios-bin Sgabios for x86
spice-server Implements the server side of the SPICE protocol
unbound-libs Libraries used by the unbound server and client applications
yajl Yet Another JSON Library Tools
1.6.7 Optional RHEL OS packages Table 1-8, “Optional RHEL OS packages” (p. 29) lists the optional packages that you can install. To facilitate the package installation, copy the following command and paste it in a CLI:
yum -y install nfs-utils
Table 1-8 Optional RHEL OS packages
Package Description
nfs-utils NFS utilities and supporting clients and daemons for the kernel
1.7 Virtual machine requirements
1.7.1 Overview Nokia recommends that the CLM be installed on virtual machines using VMWare ESXi or RHEL KVM, including OpenStack. The Guest Operating System for a CLM deployment must be a supported version of RHEL 7.3, 7.4, 7.5, 7.6, 7.7, or 7.8 Server x86-64. Installations of CLM are server- and vendor-agnostic, but must meet any defined hardware criteria and performance targets to be used with the CLM. Server class hardware must be used, not desktops. Processors must be x86-64 based with a minimum core speed of 2.4GHz. Defined CPU and Memory resources for a virtual machine must be reserved and dedicated to that guest OS, and cannot be shared or oversubscribed. Disk and network resources should be managed appropriately to ensure that other guest OSs on the same physical server do not negatively impact the operation of the CLM. Provisioned CPU resources are based upon the CLM hardware platform requirements. Virtual machines should be configured with all vCPUs on one virtual socket A guest virtual machine must use only one time synchronization protocol such as NTP. Additional time synchronization applications must be disabled to ensure the proper operation of CLM. Nokia support personnel must be provided with the details of the provisioned Virtual Machine. These details can either be provided through read-only access to the hypervisor or must be available to Nokia support when requested. Failure to provide these details could impact support of the CLM.
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 29 Pre-installation CLM VMware Virtualization
1.8 VMware Virtualization
1.8.1 Overview The CLM supports using VMware vSphere ESXi 6.0, 6.1, 6.5, or 6.7 only, on x86 based servers natively supported by ESXi. VMware’s Hardware Compatibility List (HCL) should be consulted to determine specific hardware support. Not all features offered by ESXi are supported when using the CLM. For example, Fault Tolerant, High Availability (HA), Memory Compression, and Distributed Resource Scheduler (DRS) features are not supported. Contact Nokia to determine if a specific ESXi feature is supported with a CLM installation. If using NTP or a similar time synchronization protocol on the guest virtual machine, then you must disable VMwareTools time synchronization. Virtual Machine Version 11 or above must be used. The disk must be “Thick Provisioned” with “Eager Zero” set. The SCSI controller must be set to “VMware Paravirtual” and the Disk Provisioning must be “Thick Provision Eager Zero”. The Network Adapter must be “VMXNET 3”. See the following table for additional Virtual Machine setting requirements:
Table 1-9 Additional Virtual Machine setting requirements
Resource type Parameter Setting CPU Shares Set to High Reservation Must be set to half the number of vCPUs * the CPU frequency. For example, on a 2.4 GHz 8 vCPU configuration, the reservation must be set to (1/2*8*2400) = 9600 MHz. Limit Check box checked for unlimited Memory Shares Set to High Reservation Slider set to the size of the memory allocated to the VM Limit Check box checked for unlimited Disk Shares Set to High Limit — IOPs Set to Unlimited
Release 20.9 September 2020 30 3HE-16174-AAAC-TQZZA Issue 1 Pre-installation CLM KVM virtualization
1.9 KVM virtualization
1.9.1 Overview The CLM supports using RHEL 6.3 through 6.7 KVM using QEMU version 0.12.1.2 and RHEL 7.2 through 7.5 KVM using QEMU version 1.5.3, 2.0.0, 2.3.0, or 2.10.0 only, on x86 based servers natively supported by KVM. Consult the RHEL’s Hardware Compatibility List (HCL) to determine specific hardware support. Not all features offered by KVM are supported when using the CLM. For example, Live Migration, Snapshots, or High Availability are not supported. Contact Nokia to determine if a specific KVM feature is supported with a CLM installation.
1.9.2 Configuration When you configure the KVM, set the parameters listed in the following table to the required values.
Table 1-10 KVM configuration parameters
Parameter Value Disk Controller type virtio Storage format raw Cache mode none I/O mode native I/O scheduler deadline NIC device model virtio Hypervisor type kvm
1.10 OpenStack requirements
1.10.1 OpenStack support The CLM supports deployment in an OpenStack environment using Red Hat OpenStack Platform Release 8, 10, and 11. While a CLM installation may function in other OpenStack environments, the CLM Product Group does not commit to make the CLM compatible with a customer's alternate OpenStack environment. To ensure the stability of the CLM and compatibility with OpenStack, you must follow the recommendations provided in this section.
1.10.2 Hypervisor The only hypervisor supported within an OpenStack environment is KVM. For details about the KVM hypervisor supported versions, see 1.9 “KVM virtualization” (p. 31).
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 31 Pre-installation CLM Platform requirements
1.10.3 CPU and memory resources Defined CPU and memory resources must be reserved and dedicated to the individual Guest OSs, and cannot be shared or oversubscribed. You must set both the cpu_allocation_ratio and ram_ allocation_ratio parameters to 1.0 in the OpenStack Nova configuration either on the control NE or on each individual compute node where a VM hosting the CLM could reside.
1.10.4 HyperThreading The usage of CPUs with enabled HyperThreading must be consistent across all compute nodes. If there are CPUs that do not support HyperThreading, then you must disable HyperThreading at the hardware level on all compute nodes where the CLM could be deployed.
1.10.5 CPU pinning Nokia recommends enabling CPU pinning because it restricts the use of OpenStack migration. The CLM is node locked.
1.10.6 Availability zones/affinity/placement Nokia does not provide recommendations on configuring OpenStack for VM placement.
1.10.7 Networking Basic Neutron functionality using Open vSwitch with the ML2 plugin can be used in a deployment of CLM. The use of OpenStack floating IP addresses is supported for CLM.
1.10.8 VM storage The VM storage must be persistent block (Cinder) storage and not ephemeral. For each VM to be deployed, a bootable Cinder volume must be created.
1.10.9 Firewalls Firewalls can be enabled using OpenStack Security Groups, or on the VMs using the firewalld service. If firewalld is enabled, then an OpenStack Security Group that allows all incoming and outgoing traffic must be used.
1.11 Platform requirements
1.11.1 Minimum hardware platform requirements CLM supports up to 1000 network functions. The hardware requirements are independent of the number of network functions. The following table lists the minimum hardware platform requirements for the deployment of CLM for RHEL x86-64 operating system.
Table 1-11 CLM hardware platform requirements
Hardware Requirement CPU cores 2 (minimum 2.4 GHz)
Release 20.9 September 2020 32 3HE-16174-AAAC-TQZZA Issue 1 Pre-installation CLM CLM disk partitioning
Table 1-11 CLM hardware platform requirements (continued)
Hardware Requirement Memory minimum 16 GB Disk 1 SAS 10K RPM drive, 200 GB or more
1.12 CLM disk partitioning
1.12.1 Disk partitioning overview
Note: It is recommended that you create disk partitions during the RHEL OS installation. A partition created after the OS installation requires additional configuration, as described in 1.13 “To configure a CLM disk partition created after the RHEL OS installation” (p. 34). 1.13 “To configure a CLM disk partition created after the RHEL OS installation” (p. 34) also describes ANSSI-compliance mount options that you can set for some system partitions.
1.12.2 Partitioning requirements
CAUTION
Service Disruption Each disk partition described in this section must be a mounted partition and not a symbolic link. The CLM does not support the use of symbolic links to represent partitions. Table 1-12, “CLM servers partitioning scheme” (p. 33) lists the partitioning requirements for CLM components in both live and lab deployments.
Table 1-12 CLM servers partitioning scheme
Partition Content Size (Gbytes) swap Swap space 16 / Root 26 /home User home directories 0.5 /tmp Temporary files 4 /var System data 30 /opt/nsp CLM software, operating data, 50 backups /extra Application software, etc 50
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 33 Pre-installation CLM To configure a CLM disk partition created after the RHEL OS installation
1.13 To configure a CLM disk partition created after the RHEL OS installation
1.13.1 Description Perform this procedure on each CLM disk partition that you create after the RHEL OS installation.
CAUTION
Service Disruption This procedure requires a restart of the station that hosts the partition. If the CLM is installed on the station, you must perform the procedure only during a scheduled maintenance period.
Note: The Bash shell is the supported command shell for RHEL CLI operations.
1.13.2 Steps
1 Log in as the root user on the station that hosts the partition.
2 Open a console window.
3 Mount the partition; see the RHEL OS documentation for information.
4 Enter the following: # tune2fs -m 0 -o +acl /dev/device ↵ where device is the name of the device associated with the partition
5 Open the /etc/fstab file using a plain-text editor such as vi.
6 Perform one of the following. a. For a partition in a physical hardware deployment, add the following entry: /dev/device mount_point ext4 barrier=0,noatime 1 2 b. For a partition in a VM deployment, add the following entry: /dev/device mount_point ext4 noatime 1 2 where
Release 20.9 September 2020 34 3HE-16174-AAAC-TQZZA Issue 1 Pre-installation CLM Securing the CLM
device is the name of the device associated with the partition mount_point is the partition mount point, for example, /opt/nsp
7 Optionally, in accordance with ANSSI specifications, configure the following partitions using the following options:
Note: The options specified for the /var partition are only partially ANSSI-compliant.
Note: Configuring the mount options is recommended.
Note: You must configure the options before CLM is installed on the station. /boot xfs nodev,noexec,nosuid 0 0 /home xfs nodev,noexec,nosuid 0 0 /tmp xfs nodev,nosuid 0 0 /var xfs nodev,nosuid 0 0
8 Save and close the /etc/fstab file.
9 Enter the following to reboot the station: # systemctl reboot ↵ The station reboots.
END OF STEPS
1.14 Securing the CLM
1.14.1 Overview Nokia recommends that you do the following to establish the highest level of CLM security:
Note: The supported CIS benchmark best practices are implemented in the NSP RHEL OS qcow2 image. • Install the latest recommended patch cluster from Red Hat (not supported on RHEL OS qcow2 images) • Implement firewall rules to control access to ports on CLM systems, as detailed below • Use a CA signed certificate rather than a self-signed certificate. • Use SSL certificates with strong hashing algorithms. • Enforce minimum password requirements and password renewal policies on user accounts • Configure Launchpad Security Statement. • Configure login throttling to prevent denial of service attacks.
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 35 Pre-installation CLM Operating system security for CLM workstations
• Configure maximum session limits for administrators and users. • Configure user lockout after a threshold of consecutive failed login attempts. • Enable User Access Control (UAC) Communication is secured using TLS. By default, the CLM supports only TLSv1.2; TLS 2.0 is not supported. If you need to enable a different TLS version, see 5.12 “To update the supported CLM TLS versions and ciphers” (p. 84).
1.15 Operating system security for CLM workstations
1.15.1 RHEL patches Nokia supports customers applying RHEL patches provided by Red Hat which will include security fixes as well as functional fixes. If a patch is found to be incompatible with the CLM, the patch may need to be removed until a solution to the incompatibility is provided by Red Hat or Nokia. Operating system patches of CLM provided qcow2 images must be obtained from the CLM product group.
1.15.2 Platform hardening Additional efforts to secure the system could impact CLM operation or future upgrades of the product. Customers must perform some level of basic testing to validate additional platform hardening does not impact the operation of the CLM. The CLM Product Group makes no commitment to make the CLM compatible with a customer's hardening requirements.
1.16 Port information
1.16.1 Overview The tables provided in this section identify the listening ports in the CLM.
The CLM deployment types are: • standalone • redundant
Table 1-13 Port information for CLM
Default port(s) Type Encryption Description CLM deployment All applications 22 TCP Dynamic SSH/SCP/SFTP All Encryption Used for remote access and secure file transfer nspOS
Release 20.9 September 2020 36 3HE-16174-AAAC-TQZZA Issue 1 Pre-installation CLM Port information
Table 1-13 Port information for CLM (continued)
Default port(s) Type Encryption Description CLM deployment 80 TCP None HTTP port for nspOS common All applications, redirect to 443 443 TCP Dynamic Secure HTTPS port for nspOS All Encryption common applications provided by TLS 2181 TCP None Zookeeper (unsecure) All Enabled if unsecured communications is selected during installation. 2281 TCP Dynamic Zookeeper (secure) All Encryption Enabled if secured provided by TLS communications is selected during installation. 2390 TCP Dynamic nspdctl All Encryption provided by TLS 6432 TCP Dynamic PostgreSQL database All Encryption Required for external access to PG provided by TLS from CLM DR peer. 7983 TCP None Solr (Help) All Local port to the host 8195 TCP None tomcat shutdown port All Local port to the host 8196 TCP None CLM shutdown port All Local port to the host 8544 TCP Dynamic HTTPS port for CLM All Encryption provided by TLS 8575 TCP Dynamic System Token Server All Encryption provided by TLS 8983 TCP None Solr (Help) All Local port to the host. 9092 TCP None Kafka server (unsecure) All Enabled if unsecured communications is selected during installation.
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 37 Pre-installation CLM CLM firewall rules and NAT
Table 1-13 Port information for CLM (continued)
Default port(s) Type Encryption Description CLM deployment 9192 TCP Dynamic Kafka server (secure) All Encryption Enabled if secured provided by TLS communications is selected during installation. 47100–47199 TCP None CAS ignite cache All 47500–47599 TCP None CAS ignite cache All 48500–48599 TCP Dynamic session-manager ignite cache All Encryption provided by TLS 48600–48699 TCP Dynamic session-manager ignite cache All Encryption provided by TLS PKI server 2391 TCP None PKI server Only where PKI server is installed and running
1.17 CLM firewall rules and NAT
1.17.1 Overview A firewall can be deployed to protect the CLM from different networks and applications. Firewall rules are applied to the incoming network interface traffic of the CLM workstations. As a rule, firewall rules are not applied to the outgoing network traffic. The firewall rules to be applied to a CLM deployment will depend on the deployment configuration and network topology. Some CLM operations require idle TCP ports to remain open for long periods of time. Therefore, a customer firewall that closes idle TCP connections should adjust OS TCP keep-alives to ensure that the firewall will not close sockets that are in use by the CLM. The CLM supports the use of Network Address Translation (NAT) between themselves and client applications (API and GUI). Communications with Zookeeper and Kafka are secure by default and the firewall tables below will reflect this configuration. Where unsecure Zookeeper and Kafka is configured, the corresponding unsecure port numbers for those components should be substituted.
1.17.2 CLM and nspOS firewall rules Firewall rules need to be applied bidirectionally.
Release 20.9 September 2020 38 3HE-16174-AAAC-TQZZA Issue 1 Pre-installation CLM CLM firewall rules and NAT
Table 1-14 Firewall rules for traffic between the active and standby CLM in a redundant deployment
Protocol From port To port TCP >32768 22 TCP >32768 443 TCP >32768 2390 TCP >32768 6432 TCP >32768 8544
Table 1-15 Firewall rules for traffic between the CLM and PKI server
Protocol From port From component To port To component TCP >32768 CLM 2391 PKI server
Table 1-16 Firewall rules for traffic between CLM and client (GUI/REST) applications
Protocol To port To component Purpose TCP 80 CLM / nspOS re-directs to port 443 (Launchpad) TCP 443 CLM / nspOS for Launchpad TCP 8544 CLM CLM GUI and REST API TCP 9092 CLM / nspOS External notifications (messaging)
Table 1-17 Firewall rules for CLM to NE communications
NE type Protocol Port NEs that use manual pool Telnet 23 capacity reservation (VSR, 7x50 SR/XRS, CMG) NEs that use manual pool SSH 22 capacity reservation (VSR, 7x50 SR/XRS, CMG) 7x50 SR only when using FTP 21 FTP to place license key files onto the NE’s local storage
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 39 Pre-installation CLM CLM firewall rules and NAT
Table 1-18 Firewall rules for NE to CLM communications
NE type Protocol Port NEs that use network function REST API over HTTPS 8544 driven pool capacity reservation (1830 PSS, Release 12 and later)
Table 1-19 Firewall rules for remote user authentication
Protocol From port On To port On Notes TCP/UDP Any CLM 49 TACAS For TACAS server authentica- tion TCP/UDP Any CLM 389 LDAP server For LDAP authentica- tion TCP/UDP Any CLM 636 LDAP server For LDAP authentica- tion (TLS) UDP Any CLM 1812 RADIUS For RADIUS server authentica- tion
Release 20.9 September 2020 40 3HE-16174-AAAC-TQZZA Issue 1 Standalone installation and upgrade CLM Introduction
2 Standalone installation and upgrade
2.1 Introduction
2.1.1 Overview This chapter describes the standalone CLM installation and upgrade processes, as well as related operations.
2.1.2 Hosts file A hosts file identifies the CLM server(s) that host the components of your deployment. This file must be created during CLM server installation. Depending on the configuration of your deployment, the host file is populated with one of more of the entries in the following table.
Note: You can add the optional advertised_address parameter to the IP address line of a component. The parameter enables the advertisement of the component hostname or public IP address to other components. .
Table 2-1 Hosts file sections and parameters
Deployed component Required hosts file entry
nspOS + CLM (standalone) [nspos] IPaddress [clm] IPaddress Where IPaddress is the IP address of the server that is to host the nspOS software will be installed.
nspOS + CLM (1+1 redundancy) [nspos]
2.1.3 Configuration file A configuration file is used to configure a CLM server to perform specific functions. This file must be created during CLM server installation. Of the following configuration blocks, add only those that
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 41 Standalone installation and upgrade CLM Introduction
apply to your CLM server, based on the components that it will host. See 2.1.4 “SSO configuration file parameters” (p. 43) for a list of parameters available in the SSO block of the configuration file. Based on your requirements, you must edit the sections of the configuration file that apply to your deployment. Based on your requirements, you must edit the sections of the configuration file that apply to your deployment; an example configuration file is in the following directory: NSP_installer_directory/NSD_NRC_R_r/examples If you use the example configuration file, you must comment out the portions that are not used, nfmp, nfmt, nrct, sros. A line in the file that begins with ## is a comment line, and is not to be modified. A line that begins with # is configurable.
To enable a section and the required parameters in the section, you must do the following: 1. Remove the leading # character from the section label. 2. Remove the leading # character from each parameter that you need to configure. 3. Enter the required value for each parameter, as described in the comment lines above the section label.
Note: It is recommended that you remove parameter lines that you do not require from the configuration file. Use the default values, where listed. If there is no default value listed, you must specify a value. Also, failing to provide a parameter value may have undesired consequences.
Table 2-2 Configuration file parameters
Section and parameters Description
auto_start Whether CLM starts automatically after installation Default: true
nspos — inter-component communication parameters
rest System-wide REST parameters
session ttlInMins REST token time to live, in minutes Default: 60
maxNumber Maximum number of concurrent REST session tokens Default: 50
secure Whether internal service communication between CLM components is secured using TLS You must set this to true for CLM. Default: false
tls — TLS parameters
Release 20.9 September 2020 42 3HE-16174-AAAC-TQZZA Issue 1 Standalone installation and upgrade CLM Introduction
Table 2-2 Configuration file parameters (continued)
Section and parameters Description
pki_server PKI server IP address or hostname Default: none
pki_server_port PKI server port Default: 2391
pki_org Organization name for TLS certificate Default: Nokia
pki_cn Common name for TLS certificate Default: NSP
custom_keystore_path If you are providing custom TLS keystore, keystore path and filename Default: none
custom_truststore_path If you are providing custom TLS truststore, truststore path and filename Default: none
custom_keystore_password If you are providing custom TLS keystore, keystore password Default: none
custom_truststore_password If you are providing custom TLS truststore, truststore password Default: none
custom_key_alias If you are providing custom TLS keystore, alias of required key in keystore Default: alias
regenerate_certs Whether to force TLS certificate regeneration Default: true
ean — external application notification parameters
max_subscribers Maximum number of subscribers that receive external application notifications Default: 10
Note: Parameters not being configured should be removed from the configuration file entirely. Failing to provide a value for a parameter may have undesired consequences.
2.1.4 SSO configuration file parameters The SSO section of the configuration file is used to define CLM remote user authentication sources and login features. See 5.4 “CLM login security” (p. 70) for information about how the CLM manages login attempts using the parameters in the throttling and login_failure sections.
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 43 Standalone installation and upgrade CLM Introduction
Note: TLS certificates for secure LDAP communication must be copied to the /tls/ldap directory in the installation directory. If an LDAP certificate contains an IP address or hostname in the SAN field, the same IP address or hostname must be used in the config.yml file.
Note: Multiple authentication sources can be defined, whether of the same type (such as two LDAP servers), or of differing types (such as both RADIUS and TACACS). See the installer file examples/config.yml for example configurations.
Table 2-3 SSO configuration file parameters
Section and parameters Description
session — general user session parameters
concurrent_limits_enabled Whether a maximum concurrent session limit is enabled Default: true
max_sessions_per_user Maximum number of concurrent sessions per user - does not apply to admin group Default: 10
max_sessions_for_admin Maximum number of concurrent sessions for users in admin group Default: 10
ldap — LDAP parameters
enabled Whether LDAP is to be used for authentication Default: false
servers List of LDAP servers; specify a server using the parameters below
type LDAP server type Values: AUTHENTICATION/AD/ANONYMOUS Note: AD should only be used for an active directory server where users are members of only one group in the specified group base DN. Group search can only be performed when AUTHENTICATION is used, which requires bind credentials for performing the LDAP query. When ANONYMOUS or AD are used, the group can only be defined by the group_base_dn.
url LDAP server URL with IP address or hostname and port Default: none
security Type of LDAP server security Values: SSL/STARTTLS/NONE
timeout Timeout period, in seconds, for receiving an authentication response Default: 10
user_base_dn User base dn value Default: none
Release 20.9 September 2020 44 3HE-16174-AAAC-TQZZA Issue 1 Standalone installation and upgrade CLM Introduction
Table 2-3 SSO configuration file parameters (continued)
Section and parameters Description
user_filter Filter criteria for username Default: none
group_base_dn The DN that contains the applicable CLM groups Default: none Note: Used for further refining the groups returned by the server
group_search Custom group search options Note: Can also be used for custom searches or further group filtering
filter Group search filter criteria Default: none
attribute_id Group search attribute that identifies the CLM group name Default: none Note: In most cases, CN is adequate
bind LDAP bind credentials for authenticated access only
dn User with authority to bind to LDAP server Default: none
credential Password for bind user Note: The password must be enclosed in double quotation marks. Default: none
min_pool_size Minimum pool size Default: 0
max_pool_size Maximum pool size Default: 10
use_entry_resolver Whether an entry resolver is to be used for extracting additional user information Default: none
radius — RADIUS parameters
enabled Whether RADIUS is to be used for authentication Default: none
address Comma-separated list of RADIUS servers Default: none
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 45 Standalone installation and upgrade CLM Introduction
Table 2-3 SSO configuration file parameters (continued)
Section and parameters Description
secret Shared server secret Note: The shared secret value must be enclosed in double quotation marks. Default: none
protocol Protocol to use—PAP or CHAP Default: none
retries Maximum number of attempts to reach server Default: 3
timeout Timeout, in seconds, for attempts to reach RADIUS server Default: 60
failover_on_exception Whether second server is tried if first server fails with exception Default: none
failover_on_rejection Whether second server is tried if first server fails with rejection Default: none
authentication_port RADIUS port Default: 1812
vendor_id Vendor ID for VSA search Default: 123
role_VSA_id VSA ID used to identify group Default: 3
tacacs — TACACS+ parameters
enabled Whether TACACS+ authentication is to be used Default: none
address Comma-separated list of TACACS+ servers Default: none
secret Shared server secret Note: The shared secret must be enclosed in double quotation marks. Default: none
protocol Protocol to use Default: PAP
timeout Timeout, in seconds, for attempts to reach TACACS+ server Default: 7
failover_on_exception Whether second server is tried if first server fails with exception Default: none
failover_on_rejection Whether second server is tried if first server fails with rejection Default: none
Release 20.9 September 2020 46 3HE-16174-AAAC-TQZZA Issue 1 Standalone installation and upgrade CLM Introduction
Table 2-3 SSO configuration file parameters (continued)
Section and parameters Description
authentication_port TACACS+ port Default: 49
default_group Default group to assign if no group defined on server Default: none
VSA_enabled Whether VSA search is enabled Default: true
role_VSA_id Role used for VSA search Default: sam-security-group
VSA_service_id VSA search service identifier Default: sam-app
throttling — user login throttling parameters
enabled Whether to enable login throttling Default: none
rate_threshold Login failure threshold used for calculating login failure rate; see rate_seconds parameter Default: 3
rate_seconds Number of seconds used for calculating login failure rate; exceeded if login attempt comes within rate_seconds/rate_ threshold seconds of a previous failed login attempt Default: 9
lockout_period Number of seconds after throttling threshold exceeded to wait before attempting to authenticate the same user and source address combination Default: 5
login_failure — user login failure parameters
enabled Whether to lock out users who have more consecutive login failures than specified by the threshold parameter Default: none
threshold Maximum number of consecutive login failures before user lockout Default: 3
lockout_minutes Number of minutes to lock the user out after the threshold parameter value is exceeded Default: 1
Note: Any certificates required for secure LDAP communications should be copied to
Note: If hostnames are used instead of IP addresses within the config.yml file, those hostnames need to be used in the hosts file as well.
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 47 Standalone installation and upgrade CLM To install a standalone CLM system
2.2 To install a standalone CLM system
2.2.1 Purpose Use this procedure to install a standalone CLM system.
2.2.2 Before you begin Before executing the CLM installer, ensure that your system meets the hardware and software requirements described see Chapter 1, “Pre-installation”.
2.2.3 Steps
CAUTION
Deployment failure The RHEL OS requires specific versions of some RHEL packages. If the required package versions are not installed, the CLM installation fails. See 1.6.6 “Additional package requirements” (p. 23) for the required package versions.
1 Download the NSP_CLM_installer_
Note: In subsequent steps, the directory is called the NSP installer directory or NSP_ installer_directory.
Note: It is strongly recommended that you verify the checksum of each software package or file that you download from the Nokia Support portal. You can compare the checksum value on the download page with, for example, the output of the RHEL md5sum or sha256sum command. See the appropriate RHEL man page for information.
Note: The install.sh utility communicates with remote target stations using an SSH session. To perform an operation using the utility, you must do one of the following: • Configure the required SSH keys on the stations. • Use the --ask-pass argument for root access to all target systems when SSH keys are not configured between the install server and target systems.
2 Enter the following to navigate to the NSP installer directory:
Release 20.9 September 2020 48 3HE-16174-AAAC-TQZZA Issue 1 Standalone installation and upgrade CLM To install a standalone CLM system
cd NSD_NRC_R_r ↵
3 Create a hosts file in the directory where the CLM installer bundle was extracted and add the required entries based on the components that the server will host. See 2.1.2 “Hosts file” (p. 41) for more information.
4 Create a YAML or JSON configuration file in the directory where the CLM installer bundle was extracted and add only the configuration blocks that apply to your deployment.
Note: You must set the secure parameter to true. See 2.1.3 “Configuration file” (p. 41) for more information.
5 If the TLS block of the configuration file was populated in Step 4, copy the TLS certificates into the installer directory.
6 If LDAP authentication settings were configured in Step 4, copy the LDAP server certificate into the tls/ldap directory.
7 Perform 5.7 “To configure and enable a PKI server” (p. 73) to enable the configuration of TLS in the system.
8 Install the CLM. execute the following commands as root user to install the components specified in the hosts file: :
cd bin ↵
./install.sh --ask-pass ↵ Enter the password for the CLM when prompted.
9 If the auto_start parameter was set to false in Step 4, execute the following commands to start the system:
systemctl start nspos-nspd ↵
nspdctl --host
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 49 Standalone installation and upgrade CLM To upgrade a standalone CLM server
where IP_address is the IP address of the desired CLM server
END OF STEPS
2.3 To upgrade a standalone CLM server
2.3.1 Purpose Use this procedure to upgrade a standalone CLM server.
2.3.2 Before you begin Before executing the CLM installer, ensure that your system meets the hardware and software requirements described see Chapter 1, “Pre-installation”.
Note: Before performing an upgrade, all processes must be stopped on both the primary and standby servers and a database backup should be performed.
2.3.3 Steps
CAUTION
Deployment failure Check if any new packages need to be installed and then install them before performing the upgrade. See 1.6.4 “RHEL OS packages to install” (p. 17) for the required packages.
CAUTION
Deployment failure The RHEL OS requires specific versions of some RHEL packages. If the required package versions are not installed, the CLM upgrade fails. See 1.6.6 “Additional package requirements” (p. 23) for the required package versions.
CAUTION
Deployment failure Upgrades should not be performed on a CLM server that has never been operational. Confirm that the CLM server to be upgraded has been started successfully before performing this procedure.
1 Stop all processes. Execute:
Release 20.9 September 2020 50 3HE-16174-AAAC-TQZZA Issue 1 Standalone installation and upgrade CLM To upgrade a standalone CLM server
nspdctl --host
systemctl stop nspos-nspd ↵ where IP_address is the IP address of the desired CLM server
2 Ensure that the supported version of RHEL 7 is running. As root user, execute the following command on the CLM server:
cat /etc/redhat-release ↵
Note: Any server running an unsupported version of RHEL 7 must be upgraded to a supported version.
3 If the CLM is deployed in a VM created using the NSP RHEL OS qcow2 image, perform 1.5 “To apply a CLM RHEL qcow2 OS update” (p. 13) on the server station.
4 Download the NSP_CLM_installer_
Note: In subsequent steps, the directory is called the NSP installer directory or NSP_ installer_directory.
Note: It is strongly recommended that you verify the checksum of each software package or file that you download from the Nokia Support portal. You can compare the checksum value on the download page with, for example, the output of the RHEL md5sum or sha256sum command. See the appropriate RHEL man page for information.
Note: The install.sh utility communicates with remote target stations using an SSH session. To perform an operation using the utility, you must do one of the following: • Configure the required SSH keys on the stations. • Use the --ask-pass argument for root access to all target systems when SSH keys are not configured between the install server and target systems.
5 Enter the following to navigate to the NSP installer directory: cd NSD_NRC_R_r ↵
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 51 Standalone installation and upgrade CLM To upgrade a standalone CLM server
6 Create a hosts file in the directory where the CLM installer bundle was extracted and add the required entries based on the components that the server will host. See 2.1.2 “Hosts file” (p. 41) for more information.
7 Create a YAML or JSON configuration file in the directory where the CLM installer bundle was extracted and add only the configuration blocks that apply to your deployment.
Note: You must set the secure parameter to true. See 2.1.3 “Configuration file” (p. 41) for more information.
8 If the TLS block of the configuration file was populated in Step 7, copy the TLS certificates into the installer directory.
9 If LDAP authentication settings were configured in Step 7, copy the LDAP server certificate into the tls/ldap directory.
10 Perform 5.7 “To configure and enable a PKI server” (p. 73) to enable the configuration of TLS in the system.
11 Install the CLM. As root user, execute the following commands:
cd bin ↵
./install.sh --ask-pass ↵ Enter the password for the CLM when prompted.
12 If the auto_start parameter was set to false in Step 7, execute the following commands to start the system:
systemctl start nspos-nspd ↵
nspdctl --host
END OF STEPS
Release 20.9 September 2020 52 3HE-16174-AAAC-TQZZA Issue 1 Redundant installation and upgrade CLM Introduction
3 Redundant installation and upgrade
3.1 Introduction
3.1.1 Overview
CAUTION
Service Disruption In a redundant system, a GUI client that uses a main server IP address to open a browser connection to the CLM system may need to use the IP address of the peer main server after a main server communication failure. To ensure GUI client access to the CLM in a redundant system, it is highly recommended that you do the following: • Configure DNS for GUI clients to map each main server IP address to the same DNS name • Configure each GUI client to use the DNS name for browser connections to the CLM system • Use a client browser that caches multiple IP addresses associated with one hostname This chapter describes redundant CLM installation and upgrade processes, as well as related operations.
3.2 To install a redundant CLM system
3.2.1 Purpose Use this procedure to install a CLM system with 1+1 redundancy, which requires the installation of both a master CLM instance, and a standby CLM instance.
3.2.2 Before you begin Before executing the CLM installer, ensure that your system meets the hardware and software requirements described see Chapter 1, “Pre-installation”.
3.2.3 Steps
CAUTION
Deployment failure The RHEL OS requires specific versions of some RHEL packages. If the required package versions are not installed, the CLM installation fails. See 1.6.6 “Additional package requirements” (p. 23) for the required package versions.
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 53 Redundant installation and upgrade CLM To install a redundant CLM system
1 Download the NSP_CLM_installer_
Note: In subsequent steps, the directory is called the NSP installer directory or NSP_ installer_directory.
Note: It is strongly recommended that you verify the checksum of each software package or file that you download from the Nokia Support portal. You can compare the checksum value on the download page with, for example, the output of the RHEL md5sum or sha256sum command. See the appropriate RHEL man page for information.
Note: The install.sh utility communicates with remote target stations using an SSH session. To perform an operation on a remote station using the utility, you must do one of the following: • Configure the required SSH keys on the stations. • Use the --ask-pass argument when you run install.sh, in which case each remote station must have the same root user password; for example: ./install.sh --ask-pass --target remote_station
2 Enter the following to navigate to the NSP installer directory: cd NSD_NRC_R_r ↵
3 Create a hosts file in the directory where the CLM installer bundle was extracted and add the required entries based on the components that the CLM server will host. See 2.1.2 “Hosts file” (p. 41) for more information.
4 Create a YAML or JSON configuration file in the directory where the CLM installer bundle was extracted and add only the configuration blocks that apply to your deployment.
Note: You must set the secure parameter to true. See 2.1.3 “Configuration file” (p. 41) for more information.
5 Perform 5.7 “To configure and enable a PKI server” (p. 73) to enable the configuration of TLS in the system.
Release 20.9 September 2020 54 3HE-16174-AAAC-TQZZA Issue 1 Redundant installation and upgrade CLM To upgrade redundant CLM servers
6 Install the CLM. As root user, execute the following commands:
cd bin ↵
./install.sh --ask-pass ↵ Enter the password for the CLM when prompted.
7 If the auto_start parameter was set to false in Step 4, enter the following sequence of commands on each CLM server:
systemctl start nspos-nspd ↵
nspdctl --host
8 Close the open console windows.
END OF STEPS
3.3 To upgrade redundant CLM servers
3.3.1 Purpose Use this procedure to upgrade a CLM server deployed with 1+1 redundancy.
3.3.2 Before you begin Before executing the CLM installer, ensure that your system meets the hardware and software requirements described see Chapter 1, “Pre-installation”.
Note: Before performing an upgrade, all processes should be stopped on both the primary and standby servers and a database backup should be performed.
3.3.3 Steps
CAUTION
Deployment failure Check if any new packages need to be installed and then install them before performing the upgrade. See 1.6.4 “RHEL OS packages to install” (p. 17) for the required packages.
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 55 Redundant installation and upgrade CLM To upgrade redundant CLM servers
CAUTION
Deployment failure The RHEL OS requires specific versions of some RHEL packages. If the required package versions are not installed, the CLM upgrade fails. See 1.6.6 “Additional package requirements” (p. 23) for the required package versions.
CAUTION
Deployment failure Upgrades should not be performed on a CLM server that has never been operational. Confirm that the CLM server to be upgraded has been started successfully before performing this procedure.
1 Stop all processes. Execute the following command on both the primary and standby CLM servers:
nspdctl --host
systemctl stop nspos-nspd ↵ where IP_address is the IP address of the desired CLM server
2 Ensure that the supported version of RHEL 7 is running. As root user, execute the following command on both the primary and standby CLM servers:
cat /etc/redhat-release ↵
Note: Any server running an unsupported version of RHEL 7 must be upgraded to a supported version.
3 If the server is deployed in a VM created using the NSP RHEL OS qcow2 image, perform 1.5 “To apply a CLM RHEL qcow2 OS update” (p. 13) on the server station.
4 Download the NSP_CLM_installer_
Release 20.9 September 2020 56 3HE-16174-AAAC-TQZZA Issue 1 Redundant installation and upgrade CLM To upgrade redundant CLM servers
An NSD_NRC_R_r directory is created in the current directory, where R_r is the CLM release identifier in the form MAJOR_minor.
Note: In subsequent steps, the directory is called the NSP installer directory or NSP_ installer_directory.
Note: It is strongly recommended that you verify the checksum of each software package or file that you download from the Nokia Support portal. You can compare the checksum value on the download page with, for example, the output of the RHEL md5sum or sha256sum command. See the appropriate RHEL man page for information.
Note: The install.sh utility communicates with remote target stations using an SSH session. To perform an operation on a remote station using the utility, you must do one of the following: • Configure the required SSH keys on the stations. • Use the --ask-pass argument when you run install.sh, in which case each remote station must have the same root user password; for example: ./install.sh --ask-pass --target remote_station
5 Enter the following to navigate to the NSP installer directory: cd NSD_NRC_R_r ↵
6 Create a hosts file in the directory where the CLM installer bundle was extracted and add the required entries based on the components that the CLM server will host. See 2.1.2 “Hosts file” (p. 41) for more information.
7 Create a YAML or JSON configuration file in the directory where the CLM installer bundle was extracted and add only the configuration blocks that apply to your deployment. See 2.1.3 “Configuration file” (p. 41) for more information.
8 Perform 5.7 “To configure and enable a PKI server” (p. 73) to enable the configuration of TLS in the system.
9 If LDAP authentication settings were configured in Step 7, copy the LDAP server certificate into the tls/ldap directory.
10 Install the CLM servers. Execute the following commands:
cd bin ↵
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 57 Redundant installation and upgrade CLM To convert a standalone CLM system to a redundant CLM system
./install.sh --ask-pass ↵ The CLM servers are automatically deployed on both servers.
11 If the auto_start parameter was set to false in Step 7, enter the following sequence of commands on each CLM server:
systemctl start nspos-nspd ↵
nspdctl --host
12 Close the open console windows.
END OF STEPS
3.4 To convert a standalone CLM system to a redundant CLM system
3.4.1 Purpose Use this procedure to convert a previously-installed standalone CLM system to a redundant CLM system.
Note: Upon converting to a redundant CLM system, TLS communication configurations must be updated so that the IP addresses of both the active and standby CLM servers are included in the SAN entries.
3.4.2 Steps
1 Open the existing hosts file, that is located in the directory where the CLM installer bundle was extracted, with a plain-text editor such as vi.
2 Modify the entries for each component that the CLM servers will host so as to use their 1+1 redundancy versions. See 2.1.2 “Hosts file” (p. 41) for more information.
3 In the config.yml file, configure the auto_start parameter with a value of false.
4 Shutdown all the active processes on the active, standalone CLM system. Execute:
Release 20.9 September 2020 58 3HE-16174-AAAC-TQZZA Issue 1 Redundant installation and upgrade CLM To convert a standalone CLM system to a redundant CLM system
nspdctl --host
systemctl stop nspos-nspd ↵ where IP_address is the IP address of the desired CLM server
5 Install the CLM. Execute the following commands on one of the servers:
cd bin ↵
./install.sh --ask-pass ↵
6 On what was previously the active, standalone CLM system, execute:
systemctl start nspos-nspd ↵
nspdctl --host
7 On the standby CLM system, execute:
systemctl start nspos-nspd ↵
nspdctl --host
END OF STEPS
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 59 Redundant installation and upgrade CLM To convert a standalone CLM system to a redundant CLM system
Release 20.9 September 2020 60 3HE-16174-AAAC-TQZZA Issue 1 Post-installation activities CLM Introduction
4 Post-installation activities
4.1 Introduction
4.1.1 Overview
CAUTION
System operation The CLM cannot function until User Access Control is enabled. After you install or upgrade the CLM, you must configure and enable UAC. This chapter describes actions that are required, or that may be required, after a CLM installation or upgrade.
4.2 Configuring and enabling User Access Control
4.2.1 Overview CLM User Access Control is disabled by default in a newly installed CLM. When UAC is disabled, all authenticated users have read/write access to the CLM. After you enable UAC, the access privileges you assign to each user using the UAC application are enforced during login. If UAC is disabled, each authenticated user in the following administrative groups is assigned CLM administrator privileges: • admin • Administrator When UAC is enabled, each user in the ‘admin’ group has CLM administrator privileges. A user with CLM administrator privileges has: • read/write access to the CLM application • permissions to assign UAC privileges to groups • the ability to enable/disable the UAC functionality Boot-strapping the UAC If none of your authenticated users belong to a group which provides administrative access to the CLM, you can configure the CLM to grant administrative access to users in one or more other groups using a whitelist, as described in the following procedure. After the procedure, and when you subsequently enable UAC, the CLM no longer uses the whitelist, and only users who belong to groups that include a UAC role that has system administration privileges will be administrators of the CLM system. See the User Manager Application Help and your network administrator for information about configuring other UAC settings.
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 61 Post-installation activities CLM Configuring and enabling User Access Control
4.2.2 To enable the whitelist If UAC is disabled and no user is in a CLM administrative group, configure a whitelist to allow administrative CLM access to members of one or more external user groups.
1 Log in as the nsp user on the CLM server.
2 Open a console window.
3 Enter the following to stop the CLM server: bash$ nspdctl stop nspos-tomcat ↵ The CLM server stops.
4 Enter the following: bash$ cd /opt/nsp/os/tomcat/webapps/session-manager/WEB-INF/classes ↵
5 Open the following file using a plain-text editor such as vi: application.conf
6 Locate the section of the file that begins with the following: authorization {
7 Edit the following line to include the name of each external user group that requires administrative access; in the example, one user group is added:: The line must include nsp_internal_system_group; otherwise, CLM operation is affected. adminGroups: ["admin", "nsp_internal_system_group", "new_group", "Administrator"] where new_group is the name of the external user group
8 Save and close the file.
9 Enter the following to start the CLM server: bash$ nspdctl start nspos-tomcat ↵
Release 20.9 September 2020 62 3HE-16174-AAAC-TQZZA Issue 1 Post-installation activities CLM To uninstall a CLM system
The CLM server initializes. When the initialization is complete, each user in the specified external groups that logs in to the server is granted administrative CLM access.
10 Close the console window.
4.2.3 To assign UAC permissions
To assign which groups (besides the administrative groups) have read and/or write access to the CLM application, you use the UAC application to assign permissions to a role and assign roles to groups.
1 Log in to the CLM as a user with administrative privileges.
2 Define roles.
The access control settings are configured by an administrator. Nokia recommends that the following two roles be defined in User Manager: • clm_operator_role — a role for read/write CLM access in the Application Access settings • clm_read_only_role — a role for read-only CLM access in the Application Access settings
3 Create Groups and assign roles. When the CLM roles are defined, an administrator can create groups that correspond to the groups in their authentication system and assign these roles to the applicable group. Only authenticated users who belong to a group that contains a role with access to the CLM application can access the CLM application. The groups must correspond to the groups that are retrieved from the external authentication source.
4 Enable UAC. See the User Manager Application Help for more information about enabling access control.
4.3 To uninstall a CLM system
4.3.1 Purpose Use this procedure to uninstall either a standalone CLM system, or a redundant CLM system.
Note: The uninstall.sh utility communicates with remote target stations using an SSH session. To perform an operation on a remote station using the utility, you must do one of the following:
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 63 Post-installation activities CLM To enable CLM notification forwarding to NSP Fault Management application
• Configure the required SSH keys on the stations. • Use the --ask-pass argument when you run uninstall.sh, in which case each remote station must have the same root user password; for example: ./uninstall.sh --ask-pass --target remote_station
4.3.2 Steps
1 Perform one of the following: a. Modify the hosts file in the installer directory so as to contain the IP addresses of the systems from which the CLM software will be uninstalled. b. Create a new hosts file, as described in 2.2 “To install a standalone CLM system” (p. 48), that contains the IP addresses of the systems from which the CLM software will be uninstalled.
2 Execute the following commands:
cd bin/ ↵
./install.sh --ask-pass ↵ The CLM software is removed from all hosts declared in the hosts file.
END OF STEPS
4.4 To enable CLM notification forwarding to NSP Fault Management application
4.4.1 Purpose You can configure the CLM to forward notifications to the NSP Fault Management application. If forwarding is enabled, the CLM notifications are raised and cleared as Fault Management alarms. The synchronization of information between the CLM and Fault Management occurs at 30-second intervals. For example, if a CLM notification clears, the associated Fault Management alarm clears within 30 seconds.
4.4.2 Before you begin
Note: Before enabling notification forwarding, confirm the following requirements: • The CLM must be in the same subnet as the NSP system that hosts the Fault Management application. • The same PKI server used to install NSP must be used for the CLM installation. • The CLM and NSP must be at Release 19.6 or later. • The nspOS running Fault Management must have been installed in secure mode.
Release 20.9 September 2020 64 3HE-16174-AAAC-TQZZA Issue 1 Post-installation activities CLM To enable CLM notification forwarding to NSP Fault Management application
4.4.3 Steps
1 Stop the CLM by executing the following command:
nspdctl --host
2 Create a configuration file in: /opt/nsp/os/app1-tomcat/conf/applications/license-manager/ application.conf that contains the following:
app { alarmForwarder { fm { enabled: true locations: "IP_address_1:port;IP_address_2:port;[f30:: aede:48ff::44]:2282" } } } where IP_address_1 and IP_address_2 are the NSP host server addresses port 2282 is required
Note: An IPv6 address must be enclosed in square bracket.
Note: The configuration file must be named application.conf.
3 Change the owner and group of the application.conf file to ‘nsp’.
4 Restart the CLM by executing the following command:
nspdctl --host
5 If the CLM is installed in a redundant configuration, you must perform these steps on both CLM sites because configuration files are not replicated between CLM sites.
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 65 Post-installation activities CLM To change CLM application settings
After you have restarted both CLM instances, ensure that the proper CLM instance is set as the active server.
END OF STEPS
4.5 To change CLM application settings
4.5.1 Purpose Perform the following procedure to change CLM application settings to reflect the performance characteristic of your network.
You can change the following settings: • timeouts • threads • delays The application.conf file describes the configuration values.
4.5.2 Steps
1 Log in as the nsp user on the CLM server.
2 Open a console window.
3 Stop the CLM by executing the following command:
nspdctl --host
4 View the CLM base configuration file located here: /opt/nsp/os/app1-tomcat/webapps/license- manager/WEB-INF/classes/application.conf
5 Create a new file named application.conf at this location: /opt/nsp/os/app1-tomcat/conf/ applications/license-manager/application.conf.
6 Open the application.conf file using a plain-text editor such as vi.
Release 20.9 September 2020 66 3HE-16174-AAAC-TQZZA Issue 1 Post-installation activities CLM To change CLM application settings
7 Add entries to the file for the values you wish to override. The file must be a valid json file and follow the grouping of the CLM base application.conf file. For example, to override the value of the srosDeployedKeyAlarmCheckerInMins field the file must look like:
app { delays { srosDeployedKeyAlarmCheckerInMins = 240 // 4 hours } }
8 Save and close the file.
9 Restart the CLM by executing the following command:
nspdctl --host
10 Close the console window.
11 If the CLM is installed in a redundant configuration, you must perform these steps on both CLM sites because configuration files are not replicated between CLM sites. After you have restarted both CLM instances, ensure that the proper CLM instance is set as the active server.
END OF STEPS
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 67 Post-installation activities CLM To change CLM application settings
Release 20.9 September 2020 68 3HE-16174-AAAC-TQZZA Issue 1 CLM user accounts and security CLM Introduction
5 CLM user accounts and security
5.1 Introduction
5.1.1 Overview This chapter describes various tasks related to user accounts, authentication, and security-related tasks that may need to be performed during or after CLM deployment.
5.2 CLM and RHEL user accounts
5.2.1 CLM user accounts There are three types of CLM users: • system administrators, who automatically have read/write access to CLM • users with read/write access to CLM, as defined by the user access control settings of the User Manager application • users with read-only access to CLM, as defined by the user access control settings of the User Manager application The access control settings are configured by an administrator. See 4.2 “Configuring and enabling User Access Control” (p. 61).
5.2.2 RHEL user accounts The CLM also requires a RHEL user account called “nsp” in the nsp user group. The group and account is created at installation. Only the nsp user can start or stop a CLM server. Server uninstallation does not remove the nsp user account, user group, or home directory. The nsp home directory is /opt/nsp/. The initial nsp password is randomly generated, and must be changed by the root user. Root user privileges are required only for component installation or upgrade, and for low-level support functions.
5.3 CLM authentication
5.3.1 Description For increased security, local user authentication is not supported. The CLM requires an external authentication source that is specified during system installation. For example, RADIUS, LDAP, or TACACS+. See 2.1.4 “SSO configuration file parameters” (p. 43) for configuration information.
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 69 CLM user accounts and security CLM CLM login security
5.4 CLM login security
5.4.1 User login throttling User login throttling limits failed login attempts based on a user and client source IP address combination in order to suppress password guessing and other abuse scenarios. Login throttling is enabled by default. A login failure rate can be configured, as well as a lockout period, if login attempts exceed the defined failure rate. The throttling parameters are configured at installation in the config.yml file. After a failed login attempt, subsequent login attempts by the same user from the same source IP address during the login threshold period are blocked for the duration of the specified lockout period. The login threshold period is defined by two parameters: The rate_seconds parameter defines a time interval, in seconds, and the rate_threshold parameter defines the number of allowed login attempts during the time interval. The lockout_period parameter defines the interval, in seconds, during which further login attempts by the user from the same source address are blocked, if the login threshold is exceeded. See 2.1.4 “SSO configuration file parameters” (p. 43) for information about the login_throttling parameters in the CLM configuration file.
5.4.2 User login failures During CLM deployment, you can specify whether, and for how long, to lock out users that exceed a specified number of consecutive login failures. See 2.1.4 “SSO configuration file parameters” (p. 43) for information about the login_failure parameters in the CLM configuration file.
5.5 To suppress security warnings in CLM browser sessions
5.5.1 Description The following steps describe how to prevent the repeated display of security warnings in a browser that connects to the CLM using a private-CA-signed or self-signed TLS certificate.
Note: You do not need to perform the procedure if the certificate is signed by a public root CA, which is trusted by default.
5.5.2 Steps
1 Perform one of the following. a. If you deployed TLS using a PKI server, transfer the ca.pem certificate file from the PKI server to each client station on which you want to suppress the browser warnings. b. If you deployed TLS using the manual method, transfer your certificate file to each client station on which you want to suppress the browser warnings.
Release 20.9 September 2020 70 3HE-16174-AAAC-TQZZA Issue 1 CLM user accounts and security CLM CLM TLS configuration and management
2 Perform one of the following. a. Import the certificate to the certificate store of a client station OS. Perform the appropriate procedure in the OS documentation to import the certificate; specify the certificate file as the certificate source.
Note: Such a procedure varies by OS type and version. b. Import the certificate to the certificate store of a client browser. Perform the appropriate procedure in the browser documentation to import the certificate; specify the certificate file as the certificate source.
Note: Such a procedure varies by browser type and version.
3 Open a browser session and verify that CLM opens without the display of security warnings.
END OF STEPS
5.6 CLM TLS configuration and management
5.6.1 Automated TLS deployment using a PKI server To reduce the complexity of configuring TLS in a new CLM system, or adding components to an existing system, you can use a utility called a Public Key Infrastructure (PKI) server. Based on user input, a PKI server creates, signs, and distributes certificates to each entity that is configured to use the PKI server.
Note: A system upgrade preserves the TLS keystore and truststore files, which are used if no PKI server is specified during the upgrade.
Benefits of automated TLS deployment In addition to simplifying the implementation of TLS, using a PKI server has the following benefits: • no system downtime when adding components or during operations such as system conversion to redundancy • no complex CLI operations or manual file transfers • no operator requirement for knowledge of interface IP address or hostname assignments • compatible with current and future product releases • can generate a certificate, use an existing certificate, or use a certificate from a previous PKIserver instance, for example, if the original PKI server is no longer available See 5.7 “To configure and enable a PKI server” (p. 73) for information about using a PKI server to deploy TLS.
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 71 CLM user accounts and security CLM CLM TLS configuration and management
Functional description The PKI server is a standalone utility that implements TLS certificate signing requests (CSRs) from requesting entities in a CLM system. A PKI server is available on a station to which you extract a CLM software bundle.
Note: Only one PKI server instance is required for automated TLS deployment; the instance serves an entire CLM system.
Note: Nokia recommends that you run the utility from the installation location on a CLM server; optionally, however, you can run a copy of the utility on any station that is reachable by each requestor.
Note: The CLM messaging subsystems require a separate TLS certificate that is used internally. The certificate is generated and distributed automatically during an installation or during an upgrade and requires that the PKI server is running during the deployment. The separate internal certificate is required regardless of the TLS configuration method you choose from system-wide CLM communication. Initially, a PKI server attempts to import an existing TLS certificate; if no certificate is available, the server prompts the operator for certificate parameters and creates a local private root CA service. Subsequently, the PKI server polls for CSRs. Upon receiving a CSR, for example, from a CLM server, the PKI server directs the private root CA to sign the requestor certificate, and then returns the signed certificate to the requestor. The requestor uses the signed certificate to create the required keystore and truststore files, and then enables TLS on the required local interfaces. For a PKI server to implement TLS on a CLM component, the component configuration must include the PKI server information.
If a PKI server is specified: • but no keystore and truststore files are specified, the PKI server generates a TLS certificate using the specified alias, which is mandatory • but no keystore and truststore passwords are specified, the default password, which is available from technical support, is used
5.6.2 Managing TLS certificate expiry A CLM server checks the expiry date of each TLS certificate in the local keystore during initialization, and every 24 hours after initialization. If a certificate is expired or approaching expiry, a CLM notification displays on the GUI. If the forwarding function is enabled to forward CLM notifications to the Fault Management application, the following alarms are viewable in the Fault Management application: • a Warning alarm, if the certificate is to expire within 30 days of the current time • a Critical alarm, if the certificate is to expire within 7 days of the current time • a Critical alarm, if the certificate is expired When a TLS certificate is expired, the CLM server continues to operate normally, but some functions that depend on secure communication may be inoperable.
Release 20.9 September 2020 72 3HE-16174-AAAC-TQZZA Issue 1 CLM user accounts and security CLM To configure and enable a PKI server
Note: The Days Remaining value in an expiry alarm is based on the number of complete 24- hour periods until the certificate expiry time. If fewer than 24 hours remain until the expiry, the Days Remaining value is zero, but the CLM does not raise a notification about the expired certificate until the actual expiry time.
Note: If a keystore contains hierarchical certificates, the CLM checks the expiry date of each certificate in the hierarchy, starting with the lowest, and uses the earliest expiry date found as the reference point for raising a notification.
TLS certificate renewal The TLS certificate renewal process is the same as the initial configuration process.
5.7 To configure and enable a PKI server
5.7.1 Purpose The following procedure describes: • how to configure the parameters for TLS certificate generation on a PKI server • how to import an existing TLS certificate to the PKI server for distribution to requestors After you perform the procedure, the PKI server: • creates a local private root CA service • generates a TLS certificate and uses the CA service to sign it, or imports a certificate • polls for certificate requests • distributes the certificate to each requestor
Note: You require root user privileges on a station.
Note: If you are configuring the CLM to forward notifications to the NSP Fault Management application, the same PKI server used to install NSP must be used for the CLM installation.
5.7.2 Steps
1 A PKI server is installed by default on a CLM server station. You can run the utility from the default installation location, or can copy the utility to another station that is reachable by all requestors. The PKI server file path is: NSP_installer_directory/tools/pki where NSP_installer_directory is the directory where the CLM software package was extracted If you want to run the utility from another location, copy the pki-server file to the location.
2 Log in as the root user on the station on which you want to run the PKI server.
3
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 73 CLM user accounts and security CLM To configure and enable a PKI server
Open a console window.
4 Navigate to the directory that contains the pki-server file. The default installation location is: NSP_installer_directory/tools/pki where NSP_installer_directory is the directory where the CLM software package was extracted
5 If you need to use a backed-up PKI-server private key and public certificate from a previous PKI-server instance, copy the files to the directory that contains the pki-server file. The files must be named: • ca.key — private RSA key of the CA • ca.pem — X.509 public key certificate signed using ca.key
Note: The files must be located in the same directory as the pki-server file, and the user that invokes the PKI server requires read access to the files.
6 Perform one of the following. a. Enter the following to use the default PKI server port: # ./pki-server ↵ b. Enter the following to specify a port other than the default: # ./pki-server -port port ↵ where port is the port to use for receiving and responding to requests
Note: If you specify a port other than the default, you must specify the non-default port number when you configure each requestor to use the PKI server.
7 If you are using files from a previous PKI-server instance, as described in Step 5, or have previously configured the root CA parameters for the PKI server, go to Step 21.
8 If this is the first time that the PKI server is run on the station, the following message and prompt are displayed: ******************************************************************************************************** No External Root CA detected on the filesystem. ******************************************************************************************************** Create new External Root CA Identity [y/n]?
Release 20.9 September 2020 74 3HE-16174-AAAC-TQZZA Issue 1 CLM user accounts and security CLM To configure and enable a PKI server
9 Enter y ↵. The following prompt is displayed: Organization Name (eg, company) []:
10 Enter your company name. The following prompt is displayed: Country Name (2 letter code) []:
11 Enter the two-letter ISO alpha-2 code for your country. The following prompt is displayed: State or Province Name (full name) []:
12 Enter your state or province name. The following prompt is displayed: Validity (days) [3650]:
13 Enter the length of time, in days, for which the TLS certificate is valid, or press ↵ to accept the default. The following messages are displayed as the PKI server creates a local TLS root CA and begins to poll for TLS certificate requests: date time Root CA generated successfully.
14 If this is the first time that the PKI server is run on the station, the following message and prompt are displayed: ******************************************************************************************************** No Internal Root CA detected on the filesystem. ******************************************************************************************************** Creating new Internal Root CA Identity.
15 The following prompt is displayed: Organization Name (eg, company) []:
16 Enter your company name.
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 75 CLM user accounts and security CLM To configure and enable a PKI server
The following prompt is displayed: Country Name (2 letter code) []:
17 Enter the two-letter ISO alpha-2 code for your country. The following prompt is displayed: State or Province Name (full name) []:
18 Enter your state or province name. The following prompt is displayed: Validity (days) [3650]:
19 Enter the length of time, in days, for which the TLS certificate is valid, or press ↵ to accept the default. The following messages are displayed as the PKI server creates a local TLS root CA and begins to poll for TLS certificate requests: date time Root CA generated successfully. date time Using Root CA from disk, and serving requests on port port
20 Make a backup copy of the following private root CA files, which are in the current directory; store the files in a secure and remote location, such as a separate physical facility: • ca.key • ca.pem
21 When the PKI server receives a certificate request, the following is displayed: date time Received request for CA cert from IP_address:port If the PKI server successfully responds to the request, the following is displayed: date time Successfully returned a signed certificate valid for IPs: [IP_address_1...IP_address_n] and hostnames: [hostname_1...hostname_n]
22 The PKI server log is the pki-server.log file in the current directory. View the log to determine when the PKI server has distributed a certificate to each requestor.
23 When the PKI server has distributed a certificate to each requestor, enter CTRL+C to stop the PKI server.
Release 20.9 September 2020 76 3HE-16174-AAAC-TQZZA Issue 1 CLM user accounts and security CLM To migrate to the PKI server
Note: The PKI server must continue to run until the installation of all products that use the PKI server is complete.
24 Close the console window.
END OF STEPS
5.8 To migrate to the PKI server
5.8.1 Purpose Use this procedure to migrate to the PKI server if the deprecated ROOT CA method, which involves generating ca.jks and ca-cert.pem files, has been used previously.
Note: This procedure should only be used if deployment was configured using the deprecated ROOT CA method.
5.8.2 Steps
1 Copy over the ca.jks file, which is the ROOT CA keystore, and the ca-cert.pem file, which is the ROOT CA certificate.
2 Use the existing ca.jks file to create a new ca.key file. Execute the following commands:
Note: You must enclose a password that contains a special character in single quotation marks; for example: -srcstorepass 'MyStorepa$$word' -deststorepass 'MyStorepa$$word' path/keytool -importkeystore -srckeystore ca.jks -destkeystore keystore.p12 -srcstorepass storePassword -deststorepass storePassword -deststoretype PKCS12 openssl pkcs12 -in keystore.p12 -passin pass:keyPassword -nocerts -nodes -out ca.key where path is the path to the keytool utility storePassword is the password to access the contents of the keystore keyPassword is the password that is used to access the private key stored within the keystore
3 Move the new ca.key file to the PKI server location. By default, this is the NSP_installer_ directory/tools/pki directory, where NSP_installer_directory is the directory where the CLM software package was extracted.
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 77 CLM user accounts and security CLM To generate TLS keystore and truststore files
4 Copy the existing ca-cert.pem file to the PKI server location.
5 Rename the ca-cert.pem file to ca.pem.
6 Start the PKI server. Execute:
./pki-server
Note: The PKI server now uses the existing certificates within the file system. If ca.key and ca.pem files are not added as directed, the PKI server creates new files.
END OF STEPS
5.9 To generate TLS keystore and truststore files
5.9.1 Purpose A TLS keystore and truststore are security artifacts that are required in order to enable TLS in a CLM system. The procedure describes how to manually generate the files that contain the artifacts.
Note: A CLM keystore must be in JKS, or Java Key Store format. The Java keytool utility can generate a TLS keystore file that contains a self-signed security certificate. The keytool utility is included in each Java Development Kit, or JDK, and Java Runtime Environment, or JRE. The keytool utility that you use must be from the Java version that the CLM uses. After a CLM server installation, you can find the keytool utility in /opt/nsp/os/jre/bin on the server. If the CLM is not yet installed, you can use the keytool on another station that is at the same Java version as the CLM.
Note: You require root user privileges on the CLM server or alternate station.
Note: The Bash shell is the supported command shell for RHEL CLI operations.
Note: A leading # character in a command line represents the root user prompt, and is not to be included in a typed command.
5.9.2 Steps
1 Log in as the root user on the CLM or another RHEL station, as required.
Release 20.9 September 2020 78 3HE-16174-AAAC-TQZZA Issue 1 CLM user accounts and security CLM To generate TLS keystore and truststore files
2 Open a console window.
3 Use the Java keytool utility on the station to generate a keystore file. See the Oracle website for keytool information, if required.
Note: The keytool utility that you use must be from the Java version that the CLM uses. Depending on the certificate type, you must specify the following CLM server identifiers in the keytool command: • self-signed If hostnames are to be used, enter the CLM server DNS hostname in the san field. • public-CA-signed Typically, a public-CA-signed certificate includes an FQDN, rather than a short hostname or IP address, in which case you must enter server FQDNs in the CN and san fields.
Note: The san field can include IP addresses and hostnames, for example: san=IP:203.0.113.75,DNS:clm1.central.mycompany.com
Note: A file path in the keystore_file value, or in the name of any file generated in a subsequent step, must not include /opt/nsp/os. If you do not include a path, the file is generated in the current working directory, which must not be below /opt/nsp/os.
Note: You must enclose a password that contains a special character in single quotation marks; for example: -keypass 'Mypa$$word' -storepass 'Mypa$$word' # path/keytool -genkeypair -alias alias -keyalg RSA -keypass password -storepass password -keystore keystore_file -validity days -dname "CN=server_name, OU=org_unit, O=org_name, L=locality, S=state, C=country" -ext bc=ca:true -ext san=IP:CLM_server_1_IP,DNS:CLM_server_ 1_hostname,IP:CLM_server_2_IP,DNS:CLM_server_2_hostname ↵ where path is the path to the keytool utility alias is a case-insensitive alias that is required for subsequent keytool operations password is the password for the key and keystore
Note: The keypass and storepass passwords must be identical. keystore_file is the name of the keystore file to generate days is the number of days for which the certificate is to be valid server_name is the CLM server hostname, FQDN or IP address org_unit is a department or division name org_name is a company name locality is a city name
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 79 CLM user accounts and security CLM To generate TLS keystore and truststore files
state is a state or region name country is a country code, for example, US CLM_server_1_IP is the public IP address of a CLM server CLM_server_1_hostname is the hostname or FQDN of a CLM server
Note: The CLM_server_2 values in the san field are not required for a standalone system. CLM_server_2_IP is the public IP address of a server in a redundant deployment NSP_server_2_hostname is the hostname or FQDN of a CLM server in a redundant deployment
4 Record the alias and password values that you specify.
5 If you do not require a TLS certificate that is signed by a CA, such as in a lab or trial deployment, perform the following steps.
Note: You must enclose a password that contains a special character in single quotation marks; for example: -storepass 'Mypa$$word' 1. Enter the following to export the certificate from the keystore to a certificate file: # path/keytool -export -alias alias -keystore keystore_file -storepass password -file certificate_file ↵ where alias is the alias specified during keystore creation keystore_file is the source keystore file, for example, /opt/samserver.keystore password is the keystore password certificate_file is the name of the certificate file to generate 2. Go to Step 8.
6 Generate a certificate signing request, or CSR.
Note: The CLM_server_2 values in the san field are not required for a standalone system. 1. Enter the following: # path/keytool -certreq -alias alias -keystore keystore_file -file CSR_file -storetype JKS -ext san=IP:CLM_server_1_IP,DNS:CLM_server_ 1_hostname,IP:CLM_server_2_IP,DNS:CLM_server_2_hostname ExtendedKeyUsage=serverAuth,clientAuth ↵ where
Release 20.9 September 2020 80 3HE-16174-AAAC-TQZZA Issue 1 CLM user accounts and security CLM To generate TLS keystore and truststore files
alias is a case-insensitive alias that is required for subsequent keytool operations keystore_file is the keystore file generated in Step 3 CSR_file is the name of the CSR file to generate The following prompt is displayed: Enter keystore password: 2. Enter the keystore password. The following prompt is displayed: Enter key password for alias 3. Enter the key password. The utility generates the CSR file.
7 Send the CSR file to a CA for authentication. The CA returns a certificate file that contains a trusted root certificate in a hierarchical certificate chain.
8 Enter the following to import the certificate to a truststore file:
Note: If the certificate is signed by a CA, you must import the entire CA chain of certificates to the truststore file; see the CA documentation for information about importing trusted certificates.
Note: You must enclose a password that contains a special character in single quotation marks; for example: -storepass 'Mypa$$word' # path/keytool -import -trustcacerts -alias alias -file certificate_ file -keystore truststore_file -storepass password ↵ where alias is the keystore alias certificate_file is the self-signed or CA certificate file truststore_file is the truststore file that is to hold the certificate password is the truststore password
9 If the certificate is CA-signed, enter the following to import the certificate from the certificate file to a keystore file:
Note: You must import the entire CA chain of certificates to the keystore file; see the CA documentation for information about importing trusted certificates.
Note: You must enclose a password that contains a special character in single quotation marks; for example: -storepass 'Mypa$$word' # path/keytool -import -trustcacerts -alias alias -file certificate_ file -keystore keystore_file -storepass password ↵
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 81 CLM user accounts and security CLM Data privacy
where alias is the keystore alias certificate_file is the CA certificate file keystore_file is the keystore file that is to hold the certificate password is the truststore password
10 Configure the custom_keystore_path parameter in the TLS section of the CLM configuration file to point to the generated keystore file. You must also set the other parameters in the TLS section to match the parameters specified for the generation of the keystore.
END OF STEPS
5.10 Data privacy
5.10.1 Securing private data in the system The following table indicates how private data is handled within the CLM. The servers in a CLM deployment reside within the secure domain of the customer network.
Table 5-1 CLM data privacy
Category Description Network element data
Type of data • Username and password • IP address
Purpose • NE authentication • NE IP address for NE discovery/access
Storage • Local database • Logs Retention Data is retained in the database until an authorized user deletes it. Log retention can vary based on the log file size and number of log backups. Processing NE data is processed for the stated purpose. Access Authorized users
Release 20.9 September 2020 82 3HE-16174-AAAC-TQZZA Issue 1 CLM user accounts and security CLM To configure the CLM security statement
Table 5-1 CLM data privacy (continued)
Category Description
Safeguards • NEs are configured by authorized users • Database access is restricted to authorized users • Secure transit option is available • Passwords for NE users are encrypted before being stored • Log file access is restricted to authorized users
5.11 To configure the CLM security statement
5.11.1 Purpose Use this procedure to configure the security statement that is displayed on the CLM login page.
5.11.2 Steps
Install the CLM and start the nspOS
1
Perform one of the following: • Install your standalone CLM system, as described in 2.2 “To install a standalone CLM system” (p. 48). • Install your redundant CLM system, as described in 3.2 “To install a redundant CLM system” (p. 53).
2 Start the nspOS.
Configure the CLM security message
3 Sign in as an administrator user and launch the CLM application.
4 From the Launchpad, click User → NSP Settings.
5 Click System Settings.
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 83 CLM user accounts and security CLM To update the supported CLM TLS versions and ciphers
6 Type a security statement in the text field, and then select the check box to enable the security statement.
Note: The security statement will not be displayed the first time that the CLM login page is accessed.
END OF STEPS
5.12 To update the supported CLM TLS versions and ciphers
5.12.1 Purpose
CAUTION
Service Disruption This procedure involves a complete shutdown and restart of the CLM system. It is strongly recommended that you perform this procedure only during a scheduled maintenance period.
CAUTION
Potential Service Outage • A client that uses Java 7, update 94 or earlier, cannot connect to the CLM unless you enable TSLv1 on the CLM. • A client that uses Java 7, update 95 or later, can connect to the CLM only if you enable TLSv1.1 or TLSv1.2, as required, on the client station. To enable TLSv1.1 or TLSv1.2 for a client, you must add the protocol to the list of supported protocols defined by the jdk.tls.client.protocols Java system property on the client station, for example: jdk.tls.client.protocols=TLSv1.2 Outdated TLS versions or ciphers may present a security risk. Perform this procedure to update the lists of supported ciphers and TLS versions (for example, to also enable TLS 1.0) in a CLM system.
Note: By default, the CLM only supports TLS 1.2; TLS 2.0 is not supported.
5.12.2 Steps
1 Log in to the standalone or primary CLM server station as the nsp user.
2 Enter the following:
Release 20.9 September 2020 84 3HE-16174-AAAC-TQZZA Issue 1 CLM user accounts and security CLM To update the supported CLM TLS versions and ciphers
bash$ cd /opt/nsp/scripts/security ↵
Prepare new cipher files
3 Enter the following to create the default cipher list file: bash$ ./ciphers_and_tls_update.bash create -cdc default-ciphers-file ↵
4 Enter the following to copy the default ciphers file to a new file: bash$ cp default-ciphers-file new_ciphers_file ↵ where new_ciphers_file is the name to assign to the new ciphers file
5 Open new_ciphers_file using a plain-text editor such as vi.
6 Remove the ciphers that are not to be supported.
7 Save and close the file.
Prepare new TLS versions files
8 Enter the following to create the default TLS list file: bash$ ./ciphers_and_tls_update.bash create -cdt default-tls-file ↵
9 Enter the following to copy the default TLS versions file to a new file: bash$ cp default-tls-file new_tls_file ↵ where new_tls_file is the name to assign to the new TLS versions file
10 Open new_tls_file using a plain-text editor such as vi.
11 Remove the TLS versions that are not to be supported.
Note: TLSv1.2 is mandatory and must not be removed.
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 85 CLM user accounts and security CLM To update the supported CLM TLS versions and ciphers
12 Save and close the file.
Distribute files to system components
13 If the CLM system is redundant, distribute the required files to the standby CLM server station. 1. Log in to the standby CLM server station as the root user. 2. Enter the following: # cd /opt/nsp/scripts/security ↵ 3. Copy the required file(s) from the primary CLM server station to the current directory. The file(s) that appear depend on whether you prepared a new ciphers file and/or new TLS versions file(s). • /opt/nsp/scripts/security/new_ciphers_file • /opt/nsp/scripts/security/new_tls_file
Stop CLM system
14 If the CLM system is redundant, stop the standby CLM server.
15 Stop the standalone or primary CLM server.
Apply new cipher and/or TLS lists
16 Perform the following steps on each CLM server station to apply the new TLS configuration. 1. Log in as the nsp user. 2. Open a console window. 3. Enter the following: bash$ cd /opt/nsp/scripts/security ↵ 4. Enter the following: Note: The -fo parameter is optional, and sets the cipher priority according to the order in the specified file. If the parameter is not included, the cipher priority is set to the default order. bash$ ./ciphers_and_tls_update.bash apply -c new_ciphers_file -t new_tls_file -fo ↵ where new_ciphers_file is the updated ciphers file - if you are not updating the ciphers you can skip the -c argument
Release 20.9 September 2020 86 3HE-16174-AAAC-TQZZA Issue 1 CLM user accounts and security CLM To update the supported CLM TLS versions and ciphers
new_tls_file is the updated TLS versions file - if you are not updating the TLS list you can skip the -t argument The script applies the new configuration, and backs up the previous configuration in the following file: ciphers_and_tls_backup.timestamp.tar.gz
17 Close the open console windows.
Start CLM system
18 Start the standalone or primary main server.
19 If the CLM system is redundant, start the standby CLM server.
20 Close the open console windows.
END OF STEPS
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 87 CLM user accounts and security CLM To update the supported CLM TLS versions and ciphers
Release 20.9 September 2020 88 3HE-16174-AAAC-TQZZA Issue 1 Backup and restore CLM Introduction
6 Backup and restore
6.1 Introduction
6.1.1 Overview This chapter describes the procedures that must be performed in order to preserve crucial system data in the case of a catastrophic failure.
6.2 To manually backup the PostgreSQL database
6.2.1 Purpose Use this procedure to manually backup the contents of the PostgreSQL database.
Note: Scheduled database backups occur daily. The backup files are stored in the /opt/nsp/ backup/scheduled directory for up to seven days. A maximum of four backups taken on Wednesdays can be saved for up to one month. The /opt/nsp/scripts/db/nsp-backup.conf file can be modified in order to customize this automated backup schedule.
6.2.2 Steps
1 Log in to the primary CLM server as the nsp user.
2 Enter the following:
nspdctl --host
3 Verify that the backup has completed successfully. Execute:
nspdctl --host
4 As nsp user, transfer the backup files from /opt/nsp/backup/nspos_migration/ to the /tmp/ nspos_migration directory within the CLM server.
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 89 Backup and restore CLM To restore the PostgreSQL database
Note: If the CLM system was deployed in a redundant configuration, the backup files must be transferred to the active CLM server.
END OF STEPS
6.3 To restore the PostgreSQL database
6.3.1 Purpose Use this procedure to restore the PostgreSQL database from backups following a catastrophic system failure.
Note: All commands presented in this procedure must be executed as nsp user.
6.3.2 Before you begin Before restoring the databases, backups must be created using the nspdctl --host
6.3.3 Steps
1 Backup the PostgreSQL database as described in 6.2 “To manually backup the PostgreSQL database” (p. 89).
2 Copy all database backup files generated in Step 1 to the system where the CLM installer bundle was extracted.
3 Stop the CLM services. As nsp user, execute the following command on a standalone CLM server, or on both servers if the CLM system was deployed in a redundant configuration:
nspdctl --host
4 As root user, navigate to the tools/database directory on the system where the CLM installer bundle was extracted and execute the following command:
5 Enter the following:
db-restore.sh ↵
Release 20.9 September 2020 90 3HE-16174-AAAC-TQZZA Issue 1 Backup and restore CLM To restore the PostgreSQL database
6 When prompted, specify the path to the database backup file to be restored.
7 Repeat Step 4 and Step 6 for each database backup file to be restored.
8 Restart the nspd agent. As nsp user, execute the following command on a standalone CLM server, or on both servers if the CLM system was deployed in a redundant configuration:
nspdctl --host
END OF STEPS
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 91 Backup and restore CLM To restore the PostgreSQL database
Release 20.9 September 2020 92 3HE-16174-AAAC-TQZZA Issue 1 Obtaining CLM software and documentation CLM Software
A Obtaining CLM software and documentation
A.1 Software
A.1.1 Software download As a registered customer, you can download CLM software from the Nokia Support portal. If you are a new customer and require access, contact your sales or support representative for registration information. The CLM software on the Electronic Delivery→Downloads portal, also called ALED, is organized by release. You navigate through the hierarchy to select and download the packages you are licensed to use according to your purchase agreement. After you select items for download and click Next, you must choose a download method. Click Help for information about the available download methods.
Note: It is strongly recommended that you verify the checksum of each software package or file that you download from the Nokia Support portal. You can compare the checksum value on the download page with the output of the RHEL md5sum or sha256sum command. See the appropriate RHEL man page for information about a command.
A.2 Documentation
A.2.1 Documentation architecture
CLM documentation consists of: • application help • product-level documents
Application help The CLM help can be opened from a ? button in the application banner bar. You may be taken directly to the Help Center, or an in-context help menu will appear offering help topics relevant to the current view.
Product-level documents
CLM documentation consists of the following: • CLM User Guide • CLM Installation and Upgrade Guide • CLM Release Notice
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 93 Obtaining CLM software and documentation CLM Documentation
A.2.2 NSP Help Center Starting with CLM Release 19.6, CLM user documentation is delivered in an on-product application called the NSP Help Center. During CLM installation, the NSP Help Center loads the information content associated with each application in your CLM deployment.
Access The Help Center can be opened from a ? button available in the CLM application banner bar, as well as the NSP Launchpad. You can browse the documentation from menus on the Help Center home page, or use the searching and filtering capabilities to isolate information quickly.
Context-sensitive help When you click the ? button in an CLM application banner bar, a “Quick Help” menu opens with suggested topics related to the current perspective. Short topics may be read in-line, whereas longer topics open in the NSP Help Center.
Searching The Help Center application is centered on its robust search capabilities. Searches conducted from the home page search across documentation for all installed CLM and NSP components. As shown in the tooltip on the search bar, the boolean operators AND/OR/NOT are supported, as are the wildcard characters * (any string) and ? (any character). Exact-phrase search strings enclosed in quotation marks are also supported.
Note: Common, non-technical terms such as “the,” “and,” “on,” and others are ignored in all searches, including exact-string searches.
Search history is tracked as follows: • The Recent Searches list on the home page is per-user, and the Popular Searches list shows the trend across all users of the system. • When a search result link is clicked on the search results page, it is captured in the Recent Searches list and considered for forming the Popular Search list. Navigating to a page in any other way (for example, by browsing from the browse menu or following links within a browsed document) does not make the page eligible for capture in the Recent/Popular Searches list. Searched terms are not highlighted on the target page, but you can use the browser find function to see the hits within a page of content.
Filtering Filters on the left of the search results page display a count beside the filter facets which contain one or more hits on your searched terms. You can refine your search results by selecting one or more filter facets and clicking APPLY FILTERS.
You can filter by either or both of these facets: • Location Select one or more documentation sets to narrow your search results to those areas. • Information Type
Release 20.9 September 2020 94 3HE-16174-AAAC-TQZZA Issue 1 Obtaining CLM software and documentation CLM Documentation
Select one or more content types to narrow your search results to hits that match the content type. For example, if your search for a term and you only want to see procedural information, select “Procedure” as the content type.
Browsing From the home page, you can browse documentation under three menus: • APPLICATION GUIDES - CLM and User Manager documentation • NSP GUIDES - NSP product-level guides • TOOLS - NSP Alarm Search Tool (CLM does not support this tool) You can browse within a guide using the table of contents tree in the left navigation panel. Use the breadcrumbs in the search path to return to search results or the home page. Use the browser back button to return to any previously visited page.
A.2.3 Documentation delivery online The documentation delivered on product in the NSP Help Center is also available online in PDF on the Nokia Documentation Center. If you are a new user and require access to the service, contact your support representative.
From the CLM product documentation page in the Documentation Center, you can: • filter by release, category, content type, and format • sort the results by title, document number, most accessed, or issue date • search for documents • search inside documents • create a downloadable collection of your filtered documents User documentation is filed under the “Manuals and Guides” content type; Release Notices and Release Descriptions are filed under “Release Information”.
Documentation alerts To receive an e-mail when new or reissued CLM customer documents are available, subscribe to the notification service on the Documentation Alerts Subscription page.
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 95 Obtaining CLM software and documentation CLM Documentation
Release 20.9 September 2020 96 3HE-16174-AAAC-TQZZA Issue 1 How do I perform a manual switchover? CLM To execute a manual switchover of a redundant CLM system
B How do I perform a manual switchover?
B.1 To execute a manual switchover of a redundant CLM system
B.1.1 Purpose Use this procedure to execute a manual switchover of a redundant CLM system.
B.1.2 Steps
1 Log in as the nsp user on a CLM server.
2 Open a console window.
3 Enter the following to change the current active CLM to the standby:
nspdctl --host
4 Enter the following to change the original standby CLM to the active:
nspdctl --host
5 Close the console window.
6 Log out of the CLM server.
END OF STEPS
Release 20.9 September 2020 Issue 1 3HE-16174-AAAC-TQZZA 97 How do I perform a manual switchover? CLM To execute a manual switchover of a redundant CLM system
Release 20.9 September 2020 98 3HE-16174-AAAC-TQZZA Issue 1