Installing conda command line in various systems with miniconda and create a simple python environment

Conda is yet another package, dependency and environment management for multiple languages like Python, C/C++, JavaScript, Java, Scala and many more
For example, with Conda the user could create python environment with the exact versions he needs! And it could be used under any Linux distribution or even Windows.

This article is to show how to install the command-line version of the Conda, which is part of the bigger platform Anaconda. The command-line version is distributed with the name Miniconda. In fact, Miniconda is a free installer for Conda, which includes only the basic set to run conda and conda install to install more than 8000 packages from the Anaconda repositories.

The Anaconda repositories could be found here: https://anaconda.org/anaconda/repo

Advantages of Miniconda:

  1. Minimal installation. 400 Mbytes, not 3G for the Anaconda platform.
  2. simple command-line interface. Couple of simple commands and their instructions are enough to bring up a complex environment for scientific or development purposes.
  3. The creating of a specific environment could be automated.
  4. No strange or not friendly GUI.
  5. Easy installation under most of the Linux distribution and Windows.
  6. The whole installation could occur only under a user’s home directory. No files require to be installed by the administrator or under global administrative path.

Keep on reading!

Debug options for LXC and lxc-start when lxc container could not start

Setup and running LXC container is really easy, but sometimes it is unclear why the LXC container could not start. Most of the time, there is a generic error, which says nothing for the real reason:

root@srv ~ # lxc-start -n test-lxc
lxc-start: test-lxc: lxccontainer.c: wait_on_daemonized_start: 867 Received container state "ABORTING" instead of "RUNNING"
lxc-start: test-lxc: tools/lxc_start.c: main: 306 The container failed to start
lxc-start: test-lxc: tools/lxc_start.c: main: 309 To get more details, run the container in foreground mode
lxc-start: test-lxc: tools/lxc_start.c: main: 311 Additional information can be obtained by setting the --logfile and --logpriority options

No specific reason why the LXC container test-lxc can not be started and the lxc-start command failed. There is just an offer to use the logging options and here is how the administrator of the box may do it by including the following lxc-start options:

-l DEBUG –logfile=test-lxc.log –logpriority=9

Here is a real-world example of an old kernel trying to run LXC 4.0
Keep on reading!

Gentoo – bash: su: command not found – missing su flag

Upgrading multiple packages may lead to interesting results especially if the queue has not finished yet or the fails with an error! Apparently, there are two main ways to have the basic command SU in the system installed:

  1. sys-apps/shadow
  2. sys-apps/util-linux

At some point, the default inclusion of su flags in the above packages had changed from sys-apps/shadow to sys-apps/util-linux, which may lead to the following interesting error:

user@srv ~ $ su
bash: /bin/su: command not found

Just check, which of the above packages includes the su flag and re-emerge it. At present, sys-apps/util-linux includes it by default and it should work without any explicit activation in portage package use (i.e. /etc/portage/package.use/mybase or /etc/portage/make.conf, for example) file.

At the moment, here is the default:

user@srv ~ # emerge -vp shadow util-linux

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R    ] sys-apps/shadow-4.11.1:0/4::gentoo  USE="acl (audit) nls pam (selinux) (split-usr) xattr -bcrypt -cracklib -skey -su" 0 KiB
[ebuild   R    ] sys-apps/util-linux-2.37.2-r3::gentoo  USE="(audit) (caps) cramfs hardlink logger ncurses nls pam python readline (selinux) (split-usr) su suid udev (unicode) -build -cryptsetup -fdformat -kill -magic (-rtas) -slang -static-libs -systemd -test -tty-helpers" ABI_X86="32 (64) (-x32)" PYTHON_TARGETS="python3_8 -python3_9 -python3_10" 0 KiB

Total: 2 packages (2 reinstalls), Size of downloads: 0 KiB

su flag is missing in sys-apps/shadow and is included in sys-apps/util-linux

Installing single node Elasticsearch 7.16 and Kibana 7.16 behind nginx web server under CentOS 8

This article will show how to install two big software – Elasticsearch to store information and Kibana to visualize the information under CentOS 8. Elasticsearch is ideal to store big data such as logs from user activities or server logs – one central repository for data, which is structured properly and it could be easily accessed and manipulated with various software.
Kibana is used mainly for visualizing the data stored in the Elasticseach server and manage the Elasticsearch service by the web. ste

Here is a simple example: send the web servers logs in Elasticsearch and visual statistical data with Kibana.

Using the rpm repository for the two software is the best option for installation and in future upgrades.

STEP 1) Install the CentOS 8.

How to install CentOS 8 could be found here – How to do a network installation of CentOS 8 (8.0.1950) – minimal server installation.
Or if a container approach is needed, there is a how to with LXC containerRun LXC CentOS 8 container with bridged network under CentOS 8.

STEP 2) Install the Elasticsearch.

This installation and configuration is for single node server setup.
First, create a rpm repository file /etc/yum.repos.d/elasticsearch.repo and fill it with the Elasticsearch repository information:

[elasticsearch]
name=Elasticsearch repository for 7.x packages
baseurl=https://artifacts.elastic.co/packages/7.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1
type=rpm-md

Then import the Elasticsearch GPG key and install the Elasticsearch software:

[root@loganalyzer ~]# rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch
[root@loganalyzer ~]# dnf install elasticsearch
Last metadata expiration check: 0:00:19 ago on 11.12.2021 (Sat) 12:43:24 UTC.
Dependencies resolved.
==========================================================================================================================================
 Package            Architecture             Version                     Repository                                Size
==========================================================================================================================================
Installing:
 elasticsearch      x86_64                   7.16.0-1                    elasticsearch                             327 M

Transaction Summary
=========================================================================================================================================
Install  1 Package

Total download size: 327 M
Installed size: 526 M
Is this ok [y/N]: y
Downloading Packages:
elasticsearch-7.16.0-x86_64.rpm                                                                                 43 MB/s | 327 MB     00:07    
------------------------------------------------------------------------------------------------------------------------------------------
Total                                                                                                           43 MB/s | 327 MB     00:07     
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                                                                                                                                     1/1 
  Running scriptlet: elasticsearch-7.16.0-1.x86_64                                                                                                                                       1/1 
Creating elasticsearch group... OK
Creating elasticsearch user... OK

  Installing       : elasticsearch-7.16.0-1.x86_64                                                                                                                                       1/1 
  Running scriptlet: elasticsearch-7.16.0-1.x86_64                                                                                                                                       1/1 
### NOT starting on installation, please execute the following statements to configure elasticsearch service to start automatically using systemd
 sudo systemctl daemon-reload
 sudo systemctl enable elasticsearch.service
### You can start elasticsearch service by executing
 sudo systemctl start elasticsearch.service

Created elasticsearch keystore in /etc/elasticsearch/elasticsearch.keystore

[/usr/lib/tmpfiles.d/elasticsearch.conf:1] Line references path below legacy directory /var/run/, updating /var/run/elasticsearch → /run/elasticsearch; please update the tmpfiles.d/ drop-in file accordingly.

  Verifying        : elasticsearch-7.16.0-1.x86_64                                                                                                                                       1/1 

Installed:
  elasticsearch-7.16.0-1.x86_64                                                                                                                                                              

Complete!

The configuration files are placed in /etc/elasticsearch/:
Keep on reading!

Kernel building failure – unable to initialize decompress status for section .debug_info

Upgrading the Gentoo system may lead to some glitches especially if not emerge the world slot very often!
In fact, leaving older packages living with the new one using slots may also lead to glitches of the same type! Here is one example, where leaving old packages may prevent the user to build some packages or the Linux kernel itself.

.....
.....
  x86_64-pc-linux-gnu-ld.bfd -r -m elf_x86_64 --build-id=sha1  -T scripts/module.lds -o lib/slub_kunit.ko lib/slub_kunit.o lib/slub_kunit.mod.o;  true
  x86_64-pc-linux-gnu-ld.bfd -r -m elf_x86_64 --build-id=sha1  -T scripts/module.lds -o lib/ts_bm.ko lib/ts_bm.o lib/ts_bm.mod.o;  true
  x86_64-pc-linux-gnu-ld.bfd -r -m elf_x86_64 --build-id=sha1  -T scripts/module.lds -o lib/ts_fsm.ko lib/ts_fsm.o lib/ts_fsm.mod.o;  true
  x86_64-pc-linux-gnu-ld.bfd -r -m elf_x86_64 --build-id=sha1  -T scripts/module.lds -o lib/ts_kmp.ko lib/ts_kmp.o lib/ts_kmp.mod.o;  true
  x86_64-pc-linux-gnu-ld.bfd -r -m elf_x86_64 --build-id=sha1  -T scripts/module.lds -o mm/kfence/kfence_test.ko mm/kfence/kfence_test.o mm/kfence/kfence_test.mod.o;  true
  x86_64-pc-linux-gnu-ld.bfd -r -m elf_x86_64 --build-id=sha1  -T scripts/module.lds -o net/6lowpan/6lowpan.ko net/6lowpan/6lowpan.o net/6lowpan/6lowpan.mod.o;  true
  x86_64-pc-linux-gnu-ld.bfd -r -m elf_x86_64 --build-id=sha1  -T scripts/module.lds -o net/6lowpan/nhc_dest.ko net/6lowpan/nhc_dest.o net/6lowpan/nhc_dest.mod.o;  true
  x86_64-pc-linux-gnu-ld.bfd -r -m elf_x86_64 --build-id=sha1  -T scripts/module.lds -o net/6lowpan/nhc_fragment.ko net/6lowpan/nhc_fragment.o net/6lowpan/nhc_fragment.mod.o;  true
  x86_64-pc-linux-gnu-ld.bfd -r -m elf_x86_64 --build-id=sha1  -T scripts/module.lds -o net/6lowpan/nhc_ghc_ext_dest.ko net/6lowpan/nhc_ghc_ext_dest.o net/6lowpan/nhc_ghc_ext_dest.mod.o;  true
x86_64-pc-linux-gnu-ld.bfd: mm/kfence/kfence_test.o: unable to initialize decompress status for section .debug_info
x86_64-pc-linux-gnu-ld.bfd: mm/kfence/kfence_test.o: unable to initialize decompress status for section .debug_info
x86_64-pc-linux-gnu-ld.bfd: mm/kfence/kfence_test.o: unable to initialize decompress status for section .debug_info
x86_64-pc-linux-gnu-ld.bfd: mm/kfence/kfence_test.o: unable to initialize decompress status for section .debug_info
mm/kfence/kfence_test.o: file not recognized: file format not recognized
  x86_64-pc-linux-gnu-ld.bfd -r -m elf_x86_64 --build-id=sha1  -T scripts/module.lds -o net/6lowpan/nhc_ghc_ext_frag.ko net/6lowpan/nhc_ghc_ext_frag.o net/6lowpan/nhc_ghc_ext_frag.mod.o;  true
make[3]: *** [/var/tmp/portage/sys-kernel/gentoo-kernel-5.15.5/work/linux-5.15/scripts/Makefile.modfinal:59: mm/kfence/kfence_test.ko] Error 1
make[3]: *** Waiting for unfinished jobs....
  x86_64-pc-linux-gnu-ld.bfd -r -m elf_x86_64 --build-id=sha1  -T scripts/module.lds -o net/6lowpan/nhc_ghc_ext_hop.ko net/6lowpan/nhc_ghc_ext_hop.o net/6lowpan/nhc_ghc_ext_hop.mod.o;  true
  x86_64-pc-linux-gnu-ld.bfd -r -m elf_x86_64 --build-id=sha1  -T scripts/module.lds -o net/6lowpan/nhc_ghc_ext_route.ko net/6lowpan/nhc_ghc_ext_route.o net/6lowpan/nhc_ghc_ext_route.mod.o;  true
  x86_64-pc-linux-gnu-ld.bfd -r -m elf_x86_64 --build-id=sha1  -T scripts/module.lds -o net/6lowpan/nhc_ghc_icmpv6.ko net/6lowpan/nhc_ghc_icmpv6.o net/6lowpan/nhc_ghc_icmpv6.mod.o;  true
  x86_64-pc-linux-gnu-ld.bfd -r -m elf_x86_64 --build-id=sha1  -T scripts/module.lds -o net/6lowpan/nhc_ghc_udp.ko net/6lowpan/nhc_ghc_udp.o net/6lowpan/nhc_ghc_udp.mod.o;  true
make[2]: *** [/var/tmp/portage/sys-kernel/gentoo-kernel-5.15.5/work/linux-5.15/scripts/Makefile.modpost:140: __modpost] Error 2
make[1]: *** [/var/tmp/portage/sys-kernel/gentoo-kernel-5.15.5/work/linux-5.15/Makefile:1783: modules] Error 2
make[1]: Leaving directory '/var/tmp/portage/sys-kernel/gentoo-kernel-5.15.5/work/build'
make: *** [Makefile:219: __sub-make] Error 2
 * ERROR: sys-kernel/gentoo-kernel-5.15.5::gentoo failed (compile phase):
 *   emake failed
 * 
 * If you need support, post the output of `emerge --info '=sys-kernel/gentoo-kernel-5.15.5::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=sys-kernel/gentoo-kernel-5.15.5::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/sys-kernel/gentoo-kernel-5.15.5/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/sys-kernel/gentoo-kernel-5.15.5/temp/environment'.
 * Working directory: '/var/tmp/portage/sys-kernel/gentoo-kernel-5.15.5/work/linux-5.15'
 * S: '/var/tmp/portage/sys-kernel/gentoo-kernel-5.15.5/work/linux-5.15'

>>> Failed to emerge sys-kernel/gentoo-kernel-5.15.5, Log file:

>>>  '/var/tmp/portage/sys-kernel/gentoo-kernel-5.15.5/temp/build.log'

 * Messages for package sys-kernel/gentoo-kernel-5.15.5:

 * ERROR: sys-kernel/gentoo-kernel-5.15.5::gentoo failed (compile phase):
 *   emake failed
 * 
 * If you need support, post the output of `emerge --info '=sys-kernel/gentoo-kernel-5.15.5::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=sys-kernel/gentoo-kernel-5.15.5::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/sys-kernel/gentoo-kernel-5.15.5/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/sys-kernel/gentoo-kernel-5.15.5/temp/environment'.
 * Working directory: '/var/tmp/portage/sys-kernel/gentoo-kernel-5.15.5/work/linux-5.15'
 * S: '/var/tmp/portage/sys-kernel/gentoo-kernel-5.15.5/work/linux-5.15'

The problem appears to be leaving multiple old sys-devel/binutils:

 sys-devel/binutils
    selected: 2.31.1-r3 2.32-r1 2.34 2.35.2  
   protected: none 
     omitted: 2.37_p1-r1

Removing the old versions of sys-devel/binutils 2.31.1-r3 2.32-r1 2.34 2.35.2 and leaving only the latest one solves the problem with the above error “unable to initialize decompress status for section .debug_info”.

emerge -vaC "<sys-devel/binutils-2.37_p1-r1"

Of course, an older version of sys-devel/binutils or a buggy one could lead to such an error! Update the sys-devel/binutils or change the version if the above error is hit.

Elasticsearch failed to set password apm_system error in initial setup

A relatively typical error when installing a single node Elastic Elasticsearch software is when the passwords are set:

[root@loganalyzer elasticsearch]# ./bin/elasticsearch-setup-passwords -v auto

Initiating the setup of passwords for reserved users elastic,apm_system,kibana,kibana_system,logstash_system,beats_system,remote_monitoring_user.
The passwords will be randomly generated and printed to the console.
Please confirm that you would like to continue [y/N]y



Connection failure to: http://192.168.0.4:9200/_security/user/apm_system/_password?pretty failed: Read timed out


ERROR: Failed to set password for user [apm_system].

Such error may prevent the initial password setting of several important passwords and compromise the Elasticsearch software security model. Even including the

discovery.type: single-node

in the /etc/elasticsearch/elasticsearch.yml would lead to such error. The missing option in the configuration /etc/elasticsearch/elasticsearch.yml is:

discovery.seed_hosts: ["node-1"]

By default, this option is commented out and it should be set on initial installation, though it is not required when starting the elasticsearch node (with no security model enabled)!
This is an array with all the servers’ hostnames in the cluster setup. In single-node mode, this option (discovery.seed_hosts) should be set only to the hostname of the single node like in this case “node-1”. This is the hostname of the server. The user must include the user’s current server hostname, not this example name “node-1”!

Setting the right hostname for discovery.seed_hosts in /etc/elasticsearch/elasticsearch.yml would let the user to set all password with the Elasticsearch tool elasticsearch-setup-passwords

The error may occur in a cluster setup with multiple servers, too, if the hosts are not filled in this option – discovery.seed_hosts.
Here is what to expect when executing elasticsearch-setup-passwords (even with some RED indexes):

[root@loganalyzer ~]# cd /usr/share/elasticsearch/
[root@loganalyzer elasticsearch]# ./bin/elasticsearch-setup-passwords -v auto

Your cluster health is currently RED.
This means that some cluster data is unavailable and your cluster is not fully functional.

It is recommended that you resolve the issues with your cluster before running elasticsearch-setup-passwords.
It is very likely that the password changes will fail when run against an unhealthy cluster.

Do you want to continue with the password setup process [y/N]y

Initiating the setup of passwords for reserved users elastic,apm_system,kibana,kibana_system,logstash_system,beats_system,remote_monitoring_user.
The passwords will be randomly generated and printed to the console.
Please confirm that you would like to continue [y/N]y


Changed password for user apm_system
PASSWORD apm_system = judakai2Wai9Saiph8ah

Changed password for user kibana_system
PASSWORD kibana_system = eisiadit3CieG4Requie

Changed password for user kibana
PASSWORD kibana = bi3NohquohLoonaizei1

Changed password for user logstash_system
PASSWORD logstash_system = AhC2kue5eeR4eK1LeeZa

Changed password for user beats_system
PASSWORD beats_system = reeyu8ooj8Eebee5ni2c

Changed password for user remote_monitoring_user
PASSWORD remote_monitoring_user = aeshahx9Ohkoph3rai6a

Changed password for user elastic
PASSWORD elastic = beiPhei4xu5iXailocei

No errors and the password are set successfully.

logrotate stopped rotating a log file

logrotate under CentOS 7 had worked perfectly till one day when a web server log stopped being rotated! All the other logs were rotated successfully. Apparently, there was no reason for this, and the logrotate status file was pointing to the very web server log file was rotated successfully during the night, but it wasn’t really!

The problem appeared to be the presence of an uncompressed file, despite the compressed file of the same file being generated.

Apparently, the logrotate or the compressing process was interrupted and the uncompressed file was left in place. After that, every time rotation happened it just stopped on this step for this log file. So the solution is to remove the compressed file and then the normal rotation will continue as it should be.

The logrotate status file is /var/lib/logrotate/logrotate.status and it is just a text file with the time of the last rotation for each log file:

"/var/log/nginx/error.log" 2021-11-2-9:33:26
"/var/log/nginx/media.static.log" 2021-11-2-9:33:26
"/var/log/php-fpm/www.access.log" 2021-11-2-9:33:26
"/var/log/yum.log" 2021-11-2-9:31:49
"/var/log/httpd/*log" 2021-11-2-9:0:0
"/var/log/wtmp" 2021-11-2-9:33:26
"/var/log/chrony/*.log" 2021-9-25-3:0:0
....

But the file has been one big file for the last 30 days:

[root@srv nginx]# ls -altr |tail -n 15
-rw-r-----.  1 nginx adm         1199 Oct  2 02:42 media.static.error.log-20211002.gz
-rw-r-----.  1 nginx adm         1919 Oct  2 02:54 error.log-20211002.gz
-rw-r-----.  1 nginx adm     39174314 Oct  2 03:16 media.static.log-20211002.gz
-rw-r-----.  1 nginx adm       307922 Oct  2 03:16 access.log-20211002.gz
-rw-r-----.  1 nginx adm         1461 Oct  3 02:16 media.static.error.log-20211003.gz
-rw-r-----.  1 nginx adm         1892 Oct  3 02:42 error.log-20211003.gz
-rw-r-----.  1 nginx adm       518079 Oct  3 03:38 access.log-20211003.gz
-rw-r-----.  1 nginx adm   1666744662 Oct  3 03:38 media.static.log-20211003
drwxr-xr-x.  2 root  root       20480 Oct  4 03:31 .
-rw-r-----.  1 nginx adm     23642112 Oct  4 03:31 media.static.log-20211003.gz
-rw-r-----.  1 nginx adm       633643 Nov  2 06:29 media.static.error.log
-rw-r-----.  1 nginx adm       680493 Nov  2 09:30 error.log
drwxr-xr-x. 16 root  root        4096 Nov  2 09:31 ..
-rw-r-----.  1 nginx adm    279561983 Nov  2 09:43 access.log
-rw-r-----.  1 nginx adm  29415439068 Nov  2 09:43 media.static.log

Debug the problem

Executing the logrotate manually will just report that the log files does not need rotation based on the time in the logrotate status file is /var/lib/logrotate/logrotate.status and in the status file it says the file has been rotated on “2021-11-2-9:33:26”!
But executing with force option reveals the real problem:
There is an uncompressed file and a compressed one with the same only with the suffix .gz.
So the uncompressed log file was wrong left in place after compression (or probably the compression or rotation process was interrupted). After the event (probably interruption of the rotating process) every day the logrotate outputted error when rotating this very same log file, but it had been written in the logrorate status file as such the rotating was successful with the latest date and time.

[root@srv nginx]# logrotate -vf /etc/logrotate.conf 
....
rotating log /var/log/nginx/media.static.log, log->rotateCount is 1000
dateext suffix '-20211102'
glob pattern '-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'
compressing log with: /bin/gzip
set default create context to system_u:object_r:httpd_log_t:s0
error: error creating output file /var/log/nginx/media.static.log-20211003.gz: File exists

rotating pattern: /var/log/php-fpm/*log  forced from command line (4 rotations)
empty log files are not rotated, old logs are removed
....

The solution

First, remove the compressed file force logrotate to rotate the logs.

[root@srv nginx]# rm media.static.log-20211003.gz
[root@srv nginx]# logrotate -vf /etc/logrotate.conf
reading config file /etc/logrotate.conf
including /etc/logrotate.d
reading config file chrony
reading config file nginx
reading config file php-fpm
....
rotating log /var/log/nginx/media.static.log, log->rotateCount is 1000
dateext suffix '-20211003'
glob pattern '-[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'
compressing log with: /bin/gzip
set default create context to system_u:object_r:httpd_log_t:s0
destination /var/log/nginx/media.static.log-20211003 already exists, skipping rotation
....

No error, just skipping the rotation (the renaming of the file) and compressing it.

Install and make GNU GCC 10 default in Ubuntu 20.04 Focal

The best way to install and use GNU GCC 10 is to install first, build-essential package, which will pull in the GNU GCC 9.2, and then install the GNU GCC 10. In fact, it is possible to install only GNU GCC 10 packages, but build-essential brings with it many additional packages, which are mandatory for the configuration and compiling stages.
GNU GCC is included in the official Ubuntu Focal repository! It just needs to be installed and made to be the default compiler.

Install build-essential ensures all generic packages to be installed, which are involved in the building process of a software product.

There are three steps to install and use GNU GCC 10 under Ubuntu 20.04:

  1. Install build-essential package.
  2. Install gcc-10 packages (g++, too).
  3. Make GNU GCC 10 default compiler – use update-alternatives to point the GNU GCC 10 as the default compiler

Four simple lines and the third is a little bit more complex:

apt update -y
apt upgrade -y
apt install -y build-essential
apt install -y gcc-10 g++-10 cpp-10
update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-10 100 --slave /usr/bin/g++ g++ /usr/bin/g++-10 --slave /usr/bin/gcov gcov /usr/bin/gcov-10

Always update and upgrade before installing new software. Use sudo before each command, if installation is performed by a user other than root:

sudo apt update -y
sudo apt upgrade -y
sudo apt install -y build-essential
sudo apt install -y gcc-10 g++-10 cpp-10
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-10 100 --slave /usr/bin/g++ g++ /usr/bin/g++-10 --slave /usr/bin/gcov gcov /usr/bin/gcov-10

It is a good idea to install cmake package, in addition to the above, because cmake is not included in build-essential:

apt install -y cmake

The apt output of installing GNU GCC 10

Many additional packages like multiple perl modules, libraries and make are installed.
Keep on reading!

Changing the queueing discipline – Error: Cannot delete qdisc with handle of zero.

If trying to delete a qdisc root to set no rules and no queuing algorithm probably for the purpose to add a new one a replace command is the right option!
An error saying there are no existing rules:

[root@srv ~]# tc qdisc del dev ens1f0 root
Error: Cannot delete qdisc with handle of zero.

Changing the qdisc with another. The example below replaces the MQ (multiqueues) with FQ (Fair Queue policy):

[root@srv ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens1f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP group default qlen 1000
    link/ether b4:96:54:9f:10:71 brd ff:ff:ff:ff:ff:ff
    inet 84.16.231.24/26 brd 84.16.231.63 scope global noprefixroute ens1f0
       valid_lft forever preferred_lft forever
    inet6 fe80::b696:91ff:fe8e:860/64 scope link 
       valid_lft forever preferred_lft forever
[root@srv ~]# tc qdisc replace dev ens1f0 root fq
[root@srv ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens1f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether b4:96:54:9f:10:71 brd ff:ff:ff:ff:ff:ff
    inet 84.16.231.24/26 brd 84.16.231.63 scope global noprefixroute ens1f0
       valid_lft forever preferred_lft forever
    inet6 fe80::b696:91ff:fe8e:860/64 scope link 
       valid_lft forever preferred_lft forever

The replace command is used,but the add command has the same effect in this case. del cannot remove the queueing discipline from a physical network device. noqueue might be only special devices like loopback (i.e. localhost), bonding network devices and so on.

In CentOS, for additional kernel modules use kernel-modules-extra package if some qdiscs are missing.