Tag: cloudlinux

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.

How “Niceness” impacts shared servers!

A very well known word in linux server is “nice” value. I have seen many people discussing about the effectiveness of Apache/Mysql tweaking, but eventually, if the throughput of your linux system isn’t good enough, apahce/mysql tweaking can fail. In this article, I am going to try explaining how “Nice” value of linux system can impact the performance of linux shared servers.

Continue reading “How “Niceness” impacts shared servers!”