GLIBCXX_3.4.25 and cannot support c++17.GLIBCXX Issues

If you have compiled a new appication in an updated GCC-12.3 and still wondering why the Error still surfacing like the message below when you run the binary that was compiled in the GCC-12.3 and not the system GCC

GLIBCXX version in Wildfly using “strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX” and found the latest version in Cluster is only GLIBCXX_3.4.25 and cannot support c++17.

First step in troubleshooting is really to find out what the binary used for its Shared Object Dependencies.

$ ldd main_fcc
./main_fcc: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by ./main_fcc)
./main_fcc: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by ./main_fcc)
linux-vdso.so.1 (0x00007fffffbd1000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f4827ea1000)
libm.so.6 => /lib64/libm.so.6 (0x00007f4827b1f000)
libgomp.so.1 => /lib64/libgomp.so.1 (0x00007f48278e7000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f48276cf000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f48274af000)
libc.so.6 => /lib64/libc.so.6 (0x00007f48270ea000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4828236000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f4826ee6000)

For the above example, “libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f4827ea1000)”, the application seems to be pointing back to the system libraries rather than the libraries you are using. You many want to “module load …….” if you are using Module Environment or configure the PATH, LD_LIBRARY_PATH, MANPATH and CPLUS_INCLUDE_PATH of the GCC you . In the end, the Shared Object Dependencies should be pointing to

$ ldd main_fcc
linux-vdso.so.1 (0x00007fffffbd1000)
libstdc++.so.6 => /usr/local/gnu/gcc-12.3/libstdc++.so.6 (0x00007f4827ea1000)
libm.so.6 => /usr/local/gnu/gcc-12.3/libm.so.6 (0x00007f4827b1f000)
libgomp.so.1 => /usr/local/gnu/gcc-12.3/libgomp.so.1 (0x00007f48278e7000)
libgcc_s.so.1 => /usr/local/gnu/gcc-12.3/libgcc_s.so.1 (0x00007f48276cf000)
libpthread.so.0 => /usr/local/gnu/gcc-12.3/libpthread.so.0 (0x00007f48274af000)
libc.so.6 => /usr/local/gnu/gcc-12.3/libc.so.6 (0x00007f48270ea000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4828236000)
libdl.so.2 => /usr/local/gnu/gcc-12.3/libdl.so.2 (0x00007f4826ee6000)

We have experience in VS Code Environment, where the Shared Object Dependencies was observed to be pointing back to the System Libraries even when using Environment Modules. Then it is best to put in .bashrc something the one below.

# .bashrc

# Source global definitions
if [ -f /etc/bashrc ]; then
. /etc/bashrc
fi

# User specific aliases and functions
alias rm='rm -i'
alias cp='cp -i'
alias mv='mv -i'
alias ls='ls --color=auto'
alias egrep='egrep --color=auto'
alias fgrep='fgrep --color=auto'
alias grep='grep --color=auto'

# Uncomment the following line if you don't like systemctl's auto-paging feature:
# export SYSTEMD_PAGER=

module load gnu/gcc-12.3
module load gnu/gdb-14.2

# User specific aliases and functions

Shortening BASH Commands (Part 1)

I had a casual read on the book “Bash Idioms” by Carl Albing. I scribbled what I learned from what stuck me the most. There are so much more. Please read the book instead.

Lesson 1: “A And B” are true only if both A and B are true…..

Example 1: If the cd command succeeds, then execute the “rm -Rv *.tmp” command

cd tmp && rm -Rv *.tmp

Lesson 2: If “A is true”, “B is not executed” and vice versa.

Example 2: Change Directory, if fail, put out the message that the change directory failed and exit

cd /tmp || { echo "cd to /tmp failed" ; exit ; }

Lesson 3: When do we use the [ ] versus [[ ]]?

I learned that the author advises BASH users to use the [[ ]] unless when avoidable. The Double Bracket helps to avoid confusing edge case behaviours that a single bracket may exhibit. If however, the main goal is portability across various platform to non-bash platforms, single quota may be advisable.

Building LAMMPS using CMAKE with OpenMPI on Rocky Linux 8

What is LAMMPS (briefly)?

LAMMPS is a classical molecular dynamics code with a focus on materials modeling. It’s an acronym for Large-scale Atomic/Molecular Massively Parallel Simulator. More Information on the software, do take a look at https://www.lammps.org/

Where to Download?

You can download the latest stable from Download LAMMPS

Step 1: Ensure Prerequisites are present

Step 2: Download and build LAMMPS

For more information, do take a look at https://docs.lammps.org/Install_tarball.html

$ tar -zxvf lammps-stable.tar.gz
$ cd lammps-2Aug203
$ mkdir build
$ touch setup.sh
$ vim setup.sh

Inside the setup.sh

cmake   -C ../cmake/presets/most.cmake ../cmake             \
-D CMAKE_INSTALL_PREFIX=/usr/local/lammps-2Aug2023 \
-D BUILD_MPI=on \
-D BUILD_SHARED_LIBS=yes \
-D FFT=FFTW3 \
-D FFTW3_INCLUDE_DIRS=${FFTW_INC} \
-D FFTW3_LIBRARIES=${FFTW_LIB}/libfftw3_mpi.a

Notes:
The -C ../cmake/presets/most.cmake command adds the packages that don’t need extra libraries.

Make and Compile……

$ make -j 16 
$ make install

References:

  1. Compiling LAMMPS and using it with Python
  2. Building LAMMPS using CMake

Compiling FFTW-3.3.10 with OpenMPI on Rocky Linux 8

For detailed explanation and information, do take a look at FFTW Installation on UNIX. For my installation.

We will be focusing on using Nvidia hpcx only for this blog. To compile Nvidia hpcx, do take a look at Installing and using Mellanox HPC-X Software Toolkit

You may want to module use which come in the hpcx installation

export HPCX_HOME=/usr/local/hpcx-v2.15-gcc-MLNX_OFED_LINUX-5-redhat8-cuda12-gdrcopy2-nccl2.17-x86_64
module use $HPCX_HOME/modulefiles

Next, I used the following parameters that suit my HPC Environment. The default installation is already double-precision. I needed MPI, OPenMPI and needs AVX512…..

# ./configure --prefix=/usr/local/fftw-3.3.10 --enable-threads --enable-openmp --enable-mpi --enable-avx512
# make && make install

References:

  1. FFTW Installation on UNIX

Installing ORCA-5.0.4 on Rocky Linux 8 with OpenMPI

ORCA is a general-purpose quantum chemistry package that is free of charge for academic users. The Project and Download Website can be found at ORCA Forum. The current version is 5.0.4.

The current prerequisites that I have used were OpenMPI-4.1.1 and System GNU which is 8.5.

Unless I have missed something, the packages of ORCA-5.0.4 has been split into 3 different packages which you have to untar and combine together

  • orca_5_0_4_linux_x86-64_openmpi411_part1
  • orca_5_0_4_linux_x86-64_openmpi411_part2
  • orca_5_0_4_linux_x86-64_openmpi411_part3

How do I untar the packages?

The first thing is to untar all the packages separately first. Assuming you are untarring at the /usr/local/

$ tar -xf orca_5_0_4_linux_x86-64_openmpi411_part1.tar.xz
$ tar -xf orca_5_0_4_linux_x86-64_openmpi411_part2.tar.xz
$ tar -xf orca_5_0_4_linux_x86-64_openmpi411_part3.tar.xz

How do I do with all the untarred packages?

Copy all the untar files into /usr/local/orca-5.0.4.

cp -rv ../orca_5_0_4_linux_x86-64_openmpi411_part1/* .
cp -rv ../orca_5_0_4_linux_x86-64_openmpi411_part2/* .
cp -rv ../orca_5_0_4_linux_x86-64_openmpi411_part3/* .

How to Compile OpenMPI-4.1.1?

Although the Compiling OpenMPI-4.1.5 for ROCEv2 with GNU-8.5 is of a higher version of OpenMPI, the principle and parameters can still be used.

How do I Put them Together?

If you are not using the Module Environment, you can consider installing. For more information do take a look at Installing Environment Modules on Rocky Linux 8.5. All you need to do is then is to load the additional module such as OpenMPI as a prerequisites. Alternatively, you can set the PATH, LD_LIBRARY_PATH of OpenMPI something like this.

export OPENMPI_HOME=/usr/local/openmpi-4.1.1
export PATH=$PATH:$OPENMPI_HOME/bin
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$OPENMPI_HOME/lib:$OPENMPI_HOME/lib64
export MANPATH=$MANPATH:$OPENMPI_HOME/share
export PATH=$PATH:/usr/local/orca-5.0.4

If you are using without Module Environment, you may want to

orca $INPUT > $OUTPUT

References:

  1. Installing ORCA

Nvidia-smi slow startup fix

If you encounter slow nvidia-smi before the information is shown. For my 8 x A40 Cards, it took about 26 seconds to initialise.

The reason for slow initialization might be due to the driver persistence issue. For more background on the issue, do take a look at Nvidia Driver Persistence. According to the article,

The NVIDIA GPU driver has historically followed Unix design philosophies by only initializing software and hardware state when the user has configured the system to do so. Traditionally, this configuration was done via the X Server and the GPUs were only initialized when the X Server (on behalf of the user) requested that they be enabled. This is very important for the ability to reconfigure the GPUs without a reboot (for example, changing SLI mode or bus settings, especially in the AGP days).

More recently, this has proven to be a problem within compute-only environments, where X is not used and the GPUs are accessed via transient instantiations of the Cuda library. This results in the GPU state being initialized and deinitialized more often than the user truly wants and leads to long load times for each Cuda job, on the order of seconds.

NVIDIA previously provided Persistence Mode to solve this issue. This is a kernel-level solution that can be configured using nvidia-smi. This approach would prevent the kernel module from fully unloading software and hardware state when no user software was using the GPU. However, this approach creates subtle interaction problems with the rest of the system that have made maintenance difficult.

The purpose of the NVIDIA Persistence Daemon is to replace this kernel-level solution with a more robust user-space solution. This enables compute-only environments to more closely resemble the historically typical graphics environments that the NVIDIA GPU driver was designed around.

Nvidia Driver Persistence

The Solution is very easy. Just start and enable nvidia-persistenced

# systemctl enable nvidia-persistenced
# systemctl start nvidia-persistenced

Immediately, the nvidia-smi command becomes more responsive

Errors with sirius-7.5.2 packages during installation

If you are installing based on Installing CP2K with Nvidia HPCX on Rocky Linux 8.5 and if you encounter the issue

.....
Installing from scratch into /usr/local/software/cp2k/tools/toolchain/install/sirius-7.5.2
for (auto it : unit_cell_.spl_num_paw_atoms()) {
^
/usr/local/software/cp2k/tools/toolchain/build/SIRIUS-7.5.2/src/potential/potential.hpp:710:9: error: expected iteration declaration or initialization
for (auto it : unit_cell_.spl_num_paw_atoms()) {
^~~
/usr/local/software/cp2k/tools/toolchain/build/SIRIUS-7.5.2/src/potential/potential.hpp:717:5: warning: no return statement in function returning non-void [-Wreturn-type]
}
.....

The reason is that the sirius package is installed by default. The issue can be issued if you put the parameters “–with-sirius=no”

% cd cp2k
% cd /usr/local/software/cp2k/tools/toolchain
% ./install_cp2k_toolchain.sh --no-check-certificate --with-openmpi --with-sirius=no

/usr/bin/ld: cannot find -liberty on Rocky Linux 8

I was trying to install CP2K on Rocky Linux 8 using the Installing CP2K with Nvidia HPCX on Rocky Linux 8.5 and I encountered an issue

libtool: warning: library '/usr/local/hpcx-v2.17.1-gcc-mlnx_ofed-redhat8-cuda12-x86_64/ucc/lib/libucc.la' was moved.
/usr/bin/ld: cannot find -liberty
collect2: error: ld returned 1 exit status

The Resolution can be done by installing binutils-devel

# dnf install binutils-devel

How to disable vulnerable ciphers and encryption modes in Rocky Linux 8 to mitigate Terrapin Attack (CVE-2023-48795)

For more information on the Terrapin Attack (CVE-2023-48795), do take a look at Terrapin Attack (CVE-2023-48795): SSH Protocol Impacted.

As mentioned, in the blog entry, Terrapin Attack (CVE-2023-48795): SSH Protocol Impacted, the attack is possible only if you use vulnerable ciphers and encryption modes: ChaCha20-Poly1305, CTR-EtM, CBC-EtM. Note that the cyphers and the encryption modes themselves are not vulnerable, but their input (sequence number) can be manipulated by the attacker.

The mitigation is similar to How to disable CBC Mode Ciphers in RHEL 8 or Rocky Linux 8 except that you have to remove the “chacha20-poly1305@openssh.com” besides the CBC Mode Ciphers.

Step 1: Edit /etc/sysconfig/sshd and uncomment CRYPTO_POLICY line:

CRYPTO_POLICY=

Edit /etc/ssh/sshd_config file. Add Ciphers, MACs and KexAlgorithms have been added

KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256

Ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com

After making changes to the configuration file, you may want to do a sanity check on the configuration file

# sshd -t

Restart sshd services

# systemctl restart sshd

To test if weak CBC Ciphers and  ChaCha20-Poly1305 are enabled

$ ssh -vv -oCiphers=chacha20-poly1305@openssh.com,3des-cbc,aes128-cbc,aes192-cbc,aes256-cbc IP-Address-of-your-Server

You should receive a similar message

Unable to negotiate with 172.21.33.11 port 22: no matching cipher found. Their offer: aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

To verify that the Terrapin Attack Vulnerability is mitigated, take a look at Vulnerability Scanner. Pre-built binaries for all major platforms and the source code are available on GitHub.

./Terrapin_Scanner_Linux_amd64 -connect XXX.XXX.XXX.XXX

If you are not vulnerable, you may have an output like this.

References:

  1. Terrapin Attack (CVE-2023-48795): SSH Protocol Impacted
  2. Terrapin Attack
  3. Terrapin (CVE-2023-48795): New Attack Impacts the SSH Protocol
  4. SSH protocol flaw – Terrapin Attack CVE-2023-48795: All you need to know

Terrapin Attack (CVE-2023-48795): SSH Protocol Impacted

What is Terrapin Attack (CVE-2023-48795)?

Researchers from Ruhr University announced the discovery of new vulnerabilities impacting the SSH Protocol. Detailed Information of the Terrapin Attack can be found at Terrapin Attack.

According to FOSSA Terrapin (CVE-2023-48795): New Attack Impacts the SSH Protocol

Terrapin is a man-in-the-middle attack; the flaw allows an attacker to corrupt data being transmitted. This can result in a loss of information or bypass critical security controls such as keystroke timing protections or SHA-2 cryptographic hash requirements, allowing the threat actor to downgrade to SHA-1. Doing so opens up the possibility of other attacks on downstream applications, components, or environments that use SSH. ​​These associated vulnerabilities have been assigned CVE-2023-46445 (Rogue Extension Negotiation Attack in AsyncSSH) and CVE-2023-46446 (Rogue Session Attack in AsyncSSH).

Terrapin (CVE-2023-48795): New Attack Impacts the SSH Protocol

How do I know that I am vulnerable?

The attack is possible only if you use vulnerable ciphers and encryption modes: ChaCha20-Poly1305, CTR-EtM, CBC-EtM. Note that the cyphers and the encryption modes themselves are not vulnerable, but their input (sequence number) can be manipulated by the attacker.

How do I mitigate the attack?

To mitigate the attack, either you upgrade OpenSSH to their latest version 9.6 or disable the affected ciphers and encryption modes.

Vulnerability Impacts

According to FOSSA Terrapin (CVE-2023-48795): New Attack Impacts the SSH Protocol, their assessment of the Attack are:

  • Limited Impacts: Terrapin can delete consecutive portions of encrypted messages, which in isolation will typically result in a stuck connection. Some of the most serious impacts identified are in downstream applications implementing SSH, such as AsyncSSH. An attacker may be able to disable certain keylogging obfuscation features, enabling them to conduct a keylogging attack; or, worst case, a threat actor can sign a victim’s client into another account without the victim noticing, enabling phishing attacks.
  • Difficult to Expliot: An active man-in-the-middle attacker and specific encryption modes are prerequisites for the exploit. Intercepting SSH traffic requires a detailed understanding of a target’s environment, limiting real-world applicability.

How do I check?

You may want to explore the vulnerablilty tool published by the Ruhr University Researchers:

For more information, do take look at Vulnerability Scanner. Pre-built binaries for all major platforms and the source code are available on GitHub.

Usage is very simple, after downloading the relevant binary, just use the command

./Terrapin_Scanner_Linux_amd64 -connect XXX.XXX.XXX.XXX

If you are not vulnerable, you may have a output something like this.

If you are vulnerable, the scanner will flag as expected.

References:

  1. Terrapin Attack
  2. Terrapin (CVE-2023-48795): New Attack Impacts the SSH Protocol
  3. SSH protocol flaw – Terrapin Attack CVE-2023-48795: All you need to know