Category: Cloudlinux

ipset: error while loading shared libraries: libipset.so.13: cannot open shared object file: No such file or directory

Troubleshooting Imunify360 Installation on Linux: Resolving Missing Libraries

When installing security tools like Imunify360 on a Linux system, dependency issues can arise due to missing libraries or incompatible configurations. This guide walks you through resolving a common error encountered during installation:

—

The Problem

During installation, you might see an error similar to this:

[root@stack10 ~]# bash i360deploy.sh IPL  
...  
ipset: error while loading shared libraries: libipset.so.13: cannot open shared object file: No such file or directory  
[2022-12-21 04:44:14] Your OS virtualization technology kvm has limited support for ipset in containers. Please, contact Imunify360 Support Team.

The key issue here is the missing libipset.so.13 library, which is required by ipset, a tool used by Imunify360 for managing firewall rules.

—

Step-by-Step Solution

1. Install the ipset-libs Package

Run this command to install the missing library:


sudo yum install ipset-libs -y

—

2. Verify Library Installation

Confirm the library exists:


ls /usr/lib64/libipset.so.13

—

3. Update Dynamic Linker Cache

Update the system’s dynamic linker cache:


sudo ldconfig

—

4. Retry Imunify360 Installation

Re-run the installer:


bash i360deploy.sh IPL

—

5. Address KVM Virtualization Warning

If the error persists:

  • If using a container (e.g., LXC, Docker) or nested virtualization: Contact Imunify360 Support for guidance.
  • For critical systems: Install Imunify360 on a bare-metal or non-containerized environment.

—

Why Does This Happen?

  • Missing Dependencies: The ipset-libs package provides libipset.so.13, which Imunify360 requires.
  • Outdated Repositories: Unupdated package managers may lack the latest versions of required packages.

—

Additional Checks

1. Update Package Repositories


sudo yum clean all  
sudo yum makecache

2. Check ipset Version


ipset --version  
rpm -q ipset ipset-libs

If outdated, reinstall with:


sudo yum reinstall ipset ipset-libs -y

3. Check for Conflicting Packages


rpm -qa | grep ipset

Uninstall conflicting versions if found.

—

Final Notes

  • Documentation First: Always check the Imunify360 documentation for the latest steps.
  • Contact Support: If issues persist, provide:
    • Full error logs.
    • Output of uname -a (system details).
    • Output of rpm -qa | grep ipset.

—

Stay Secure & Updated

By following these steps, you can resolve dependency issues and ensure a smooth Imunify360 installation. Keep your system’s packages updated and verify dependencies before deploying security tools!

Leave a comment below if you encountered other errors during installation—we’re here to help!

Keywords: Imunify360 installation error, libipset.so.13 missing, KVM virtualization limitation, ipset-libs CentOS.

Error: Package: 1:ea-php74-php-cli-7.4.15-1.el7.cloudlinux.x86_64 (cl-ea4) – Requires: ea-openssl11 = 1:1.1.1h

Error Details

The error appears when you try to run easyapache or try to install PHP 7.4 on Cloudlinux 7.9, it puts you on the following error:

Error: Package: 1:ea-php74-php-cli-7.4.15-1.el7.cloudlinux.x86_64 (cl-ea4)
Requires: ea-openssl11 = 1:1.1.1h
Installed: 1:ea-openssl11-1.1.1i-1.el7.cloudlinux.x86_64 (@cl-ea4)
ea-openssl11 = 1:1.1.1i-1.el7.cloudlinux
Available: 1:ea-openssl11-1.1.1d-1.el7.cloudlinux.x86_64 (cl-ea4)
ea-openssl11 = 1:1.1.1d-1.el7.cloudlinux
Available: 1:ea-openssl11-1.1.1f-1.el7.cloudlinux.x86_64 (cl-ea4)
ea-openssl11 = 1:1.1.1f-1.el7.cloudlinux
Available: 1:ea-openssl11-1.1.1g-1.el7.cloudlinux.x86_64 (cl-ea4)
ea-openssl11 = 1:1.1.1g-1.el7.cloudlinux
Available: 1:ea-openssl11-1.1.1h-1.el7.cloudlinux.x86_64 (cl-ea4)
ea-openssl11 = 1:1.1.1h-1.el7.cloudlinux

Error Fix:

It is trying to look into a sub-sub version of openssl, which is 1h for PHP 7.4, but 1i is installed by default which is not an exact match with 1h, hence the error is appearing. To fix the problem, you can not just run yum update on openssl and fix this as you technically already have the latest version. To work with this, you need to first uninstall the ea-openssl rpm and install the require version. You may do this in the following way:

[root@stack4 yum.repos.d]# rpm -qa|grep ea-openssl
ea-openssl11-devel-1.1.1i-1.el7.cloudlinux.x86_64
ea-openssl-1.0.2u-1.el7.cloudlinux.x86_64
ea-openssl11-1.1.1i-1.el7.cloudlinux.x86_64
[root@stack4 yum.repos.d]# yum install ea-openssl11-1.1.1h-1.el7.cloudlinux.x86_64
Loaded plugins: fastestmirror, rhnplugin, universal-hooks
This system is receiving updates from CLN.
Loading mirror speeds from cached hostfile
 * cpanel-plugins: 185.125.185.32
 * cloudlinux-x86_64-server-7: xmlrpc.cln.cloudlinux.com
Package matching 1:ea-openssl11-1.1.1h-1.el7.cloudlinux.x86_64 already installed. Checking for update.
Nothing to do

Fix it with the following:

[root@stack4 yum.repos.d]# rpm -e --nodeps ea-openssl11-1.1.1i-1.el7.cloudlinux.x86_64
[root@stack4 yum.repos.d]# yum install ea-openssl11-1.1.1h-1.el7.cloudlinux.x86_64

Remember to use rpm uninstaller instead of yum remove, as yum also removes the dependencies, but with rpm you can skip the dependency uninstallation and patch it the above way.

Troubleshooting: Imunify360 database is corrupt. Application cannot run with corrupt database

Error Message:

# service imunify360 start
Starting imunify360: WARNING [+ 3743ms] defence360agent.utils.check_db|DatabaseError detected: database disk image is malformed
WARNING [+ 3766ms] defence360agent.cli.subparsers.common.server|Imunify360 database is corrupt. Application cannot run with corrupt database. Please, contact Imunify360 support team at https://cloudlinux.zendesk.com

Detail Information & Explanation:

If you are using imunify360, an application firewall for linux servers by Cloudlinux team, you might incur an error where it says the database is corrupt. You might first see ‘Imunify360 is not started’ error from the WHM panel and end up getting the above error message as stated. Imunify360 uses a SQL database, located under ‘/var/imunify360/imunify360.db’. This image is checked everytime Imunfi360 tries to start, and if the database is malformed, it would not start. Fortunately, imunify360 comes with tools to handle this database and recover if corrupted.

How to Fix:

First, we start by running database integrity check. This can be done using the following:

imunfiy360-agent checkdb

(From Imunify360 Doc: checkdb  – Check database integrity)

Once done, you can now use ‘migratedb’ to repair and restore if the database is corrupted.

imunify360-agent migratedb

(From Imunify360 Doc: migratedb – Check and repair database if it is corrupted.)

If migratedb fails, the only way to recover this is to reinstall imunify360.

[Tue Dec 19 20:40:07.097202 2017] [lsapi:error] [pid 532140:tid 139848266454784] [client IP.IP.IP.IP:25021] mod_lsapi: [host domain.com] [req GET / HTTP/1.1] Could not connect to lsphp backend: connect to lsphp refused: 111 (possibly memory limit for LVE ID 1789 too small), referer: domain.com

If you are running Cloudlinux, cagefs and lsapi with cpanel, you are probably familiar with the error. If the error is appearing for one or two sites, then it is probably because the user is hitting the VM/PM limit you have set through Cloudlinux. But if the error is appearing for all the sites, then it is because the cagefs fails with the suexec permission for some reason.

[Tue Dec 19 20:40:07.097202 2017] [lsapi:error] [pid 532140:tid 139848266454784] [client *:25021] mod_lsapi: [host *] [req GET / HTTP/1.1] Could not connect to lsphp backend: connect to lsphp refused: 111 (possibly memory limit for LVE ID 1789 too small), referer: http://*/

One way to solve the problem is to remount all the users. Sometimes, it doesn’t work and you may require to reinitialize cagefs again:

cagefsctl –remount-all
cagefsctl -r

I have seen times, when nothing works, but reinstalling cagefs does the trick. If cagefs doesn’t work, you may try disabling virtual memory from the CloudLinux LVE manager to see if that fix the problem. CloudLinux also has a known Virtual Memory 503 error issue with LSAPI.