Server becomes unresponsive

[patrickkasie]

Dear DirectAdmin forum,

After a routine update with

yum update

and

cd /usr/local/directadmin/custombuild
./build update_da
./build update
./build versions

ioncube has suddenly stopped working. And everything else around it has become a mess. I'm in a little of a panic mode, as this is the daddy of all servers and I'm not sure what's going on with it.

Yesterday afternoon, I had executed the above commands and everything seemed to be going alright. This included a check to see if our website was still up and running. And it still is right now. However, the ioncube environment has not been touched, and yet it is saying it's not working with the following error in the webbrowser:

ionCube loader niet geïnstalleerd op PHP 7.4.30.​

ioncube loader has not been installed on PHP 7.4.30
The webserver Apache apache2.4:2.4.54: has always made use of PHP 7.4 for the website in question. So I figured it must be server-wide, which is odd considering the CLI has always been running fine on PHP 5.6.40 up until now. So I've made symlinks to match PHP 7.4

Old:
19690935 lrwxrwxrwx   1 root root    9 Jun 26  2019 phar -> phar.phar*
19690934 -rwxr-xr-x   1 root root  15K Jun 26  2019 phar.phar*
19690921 -rwxr-xr-x   1 root root  39M Jun 26  2019 php*
19690924 -rwxr-xr-x   1 root root  39M Jun 26  2019 php-cgi*
19690933 -rwxr-xr-x   1 root root 3.4K Jun 26  2019 php-config*
19690987 -rwxr-xr-x   1 root root  46M Jun 26  2019 phpdbg*
19690932 -rwxr-xr-x   1 root root 4.5K Jun 26  2019 phpize*

New:
16906690 lrwxrwxrwx   1 root root   25 Sep  7 09:17 pecl -> /usr/local/php74/bin/pecl*
19690935 lrwxrwxrwx   1 root root    9 Jun 26  2019 phar -> phar.phar*
19690934 -rwxr-xr-x   1 root root  15K Jun 26  2019 phar.phar*
16906688 lrwxrwxrwx   1 root root   26 Sep  7 09:17 php -> /usr/local/php74/bin/php74*
19690924 -rwxr-xr-x   1 root root  39M Jun 26  2019 php-cgi*
16906691 lrwxrwxrwx   1 root root   31 Sep  7 09:17 php-config -> /usr/local/php74/bin/php-config*
19690987 -rwxr-xr-x   1 root root  46M Jun 26  2019 phpdbg*
16906692 lrwxrwxrwx   1 root root   27 Sep  7 09:17 phpize -> /usr/local/php74/bin/phpize*

I didn't give much thought to the fact those were all files and not symlinks to begin with. I carried on. It still gave the error from, so I've tried a ./build all, and it spouts out the following:

 custombuild]# ./build all
######################################################################## 100.0%

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now
The source path for majordomo does not exist.  Make sure the correct path is set in majordomo.sh

So I've checked majordomo, it does exist but it seems empty. So I've tried unzipping it, to which it results in the following:

custombuild]# ls -al /usr/bin/majordomo.sh
ls: cannot access /usr/bin/majordomo.sh: No such file or directory
[root@vps06 custombuild]# ls -al majordomo-1.94.5
majordomo-1.94.5/                majordomo-1.94.5-patched.tar.gz
custombuild]# ls -al majordomo-1.94.5
total 12
drwxr-xr-x  2 root root    6 Sep  7 09:15 .
drwx------. 8 root root 8192 Sep  7 09:53 ..
custombuild]# unzip majordomo-1.94.5-patched.tar.gz
Archive:  majordomo-1.94.5-patched.tar.gz
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
unzip:  cannot find zipfile directory in one of majordomo-1.94.5-patched.tar.gz or
        majordomo-1.94.5-patched.tar.gz.zip, and cannot find majordomo-1.94.5-patched.tar.gz.ZIP, period.

Judging it's a package from 2000, I've tried building PHP 5.6 again, with obviously the same result.

I'm at a genuine loss at how this suddenly came to be just last night. There were no obvious updates that would break the system besides a PHP 8.0 update, but we don't use that on the system. I could always recover a backup, but it's not exactly the solution that would make things future proof.

Patrick

 

[patrickkasie]

I must add doing a

php -v

results in the following error, that has been present for at least a year at this point:

Failed loading /usr/local/lib/ioncube/ioncube_loader_lin_7.4.so:  /usr/local/lib/ioncube/ioncube_loader_lin_7.4.so: cannot open shared object file: No such file or directory
PHP 7.4.30 (cli) (built: Jun 13 2022 16:03:07) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies

 

[smtalk]

It's been fixed already, please try updating CustomBuild and running the commands again.

 

[patrickkasie]

It's been fixed already, please try updating CustomBuild and running the commands again.

I have updated CustomBuild through the gui now, it seems to work fine. Just now after the PHP 5.6 build, also executed on the gui, the CLI has gone from 7.4 to 5.6. What's the deal here? Poor configuration on my end?