Installing mcrypt on Centos 7 (and other PHP issues)

I've been struggling to get WHMCS working, along with a few other PHP based apps installed via Virtualmin Pro scripts (one that comes to mind is Simple Invoices.)

The basic issue I'm reporting here is

[Sat May 20 09:50:01.784768 2017] [fcgid:warn] [pid 22404] [client xx.xx.xxx.xx:58106] mod_fcgid: stderr: [WHMCS Application] ERROR: Whoops\\Exception\\ErrorException: PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/mcrypt.so' - /usr/lib64/php/modules/mcrypt.so: cannot open shared object file: No such file or directory in Unknown:0 Stack trace: #0 /home/virtual1/public_html/whmcs/vendor/filp/whoops/src/Whoops/Run.php(382): Whoops\\Run->handleError(32, 'PHP Startup: Un...', 'Unknown', 0) #1 [internal function]: Whoops\\Run->handleShutdown() #2 {main} {"exception":"[object] (Whoops\\\\Exception\\\\ErrorException(code: 32): PHP Startup: Unable to load dynamic library '/usr/lib64/php/modules/mcrypt.so' - /usr/lib64/php/modules/mcrypt.so: cannot open shared object file: No such file or directory at Unknown:0)"} []

It cannot find the file /usr/lib64/php/modules/mcrypt.so

Trying to install php-mcrypt:

php70w-common conflicts with php-common-5.6.30-1.el7.remi.x86_64

So, the specific isue relating to virtualmin is that I cannot get mcrypt to work on php 7 and therefore I cannot install WHMCS correctly.

This is what I've tried so far: I've tried installing PHP 5.6 as a side by side install to hopefully resolve the dependency. I've installed the remi repo and enabled multiple versions of PHP in the file called remi.repo

I've run various commands from the error output to update and upgrade packages in yum:

[root@host yum.repos.d]# yum install php-mcrypt
Loaded plugins: fastestmirror, replace
Loading mirror speeds from cached hostfile
Excluding mirror: mirror.de.leaseweb.net
* base: centosmirror.netcup.net
Excluding mirror: mirror.de.leaseweb.net
* epel: ftp-stud.hs-esslingen.de
Excluding mirror: mirror.de.leaseweb.net
* extras: centosmirror.netcup.net
* remi: mirror.23media.de
* remi-php55: mirror.23media.de
* remi-php56: mirror.23media.de
* remi-safe: mirror.23media.de
Excluding mirror: mirror.de.leaseweb.net
* updates: centosmirror.netcup.net
* webtatic: uk.repo.webtatic.com
Resolving Dependencies
--> Running transaction check
---> Package php-mcrypt.x86_64 0:5.6.30-1.el7.remi will be installed
--> Processing Dependency: php-common(x86-64) = 5.6.30-1.el7.remi for package: php-mcrypt-5.6.30-1.el7.remi.x86_64
--> Running transaction check
---> Package php-common.x86_64 0:5.6.30-1.el7.remi will be installed
--> Processing Dependency: php-pecl-jsonc(x86-64) for package: php-common-5.6.30-1.el7.remi.x86_64
--> Running transaction check
---> Package php-pecl-jsonc.x86_64 0:1.3.10-2.el7.remi.5.6 will be installed
--> Processing Conflict: php70w-common-7.0.18-1.w7.x86_64 conflicts php-common < 7.0
--> Finished Dependency Resolution
Error: php70w-common conflicts with php-common-5.6.30-1.el7.remi.x86_64
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest

It seems that there is a general dependency issue with earlier versions of PHP and the version of PHP 7 installed with virtualmin. Will it help to upgrade to PHP 7.2? Is there any assistance you can offer to help me resolve the conflict. Perhaps I need to completely remove PHP70 and reinstall but how can I do so without impacting existing virtual servers?

Similar issues have been reported here and here

Any help on this much appreciated.

Status: 
Active

Comments

Howdy -- well, we're not too familiar with using the repositories you're working with there. We've run into troubles with those in the past.

However, if you're interested in using the SCL repo, we have instructions for how to set that up. The SCL repo provides an mcrypt package.

Instructions for setting up SCL are here:

https://www.virtualmin.com/documentation/web/multiplephp

And you can see the mcrypt package here:

http://mirror.centos.org/centos/7/sclo/x86_64/sclo/sclo-php70/

To install the above, we'd recommend disabling all the third party repositories you have. You'd probably also want to remove the the third party packages that have been installed from them, and go back to the standard CentOS packages first.

Thanks for that.

I had actual started off trying to resolve by installing the SCL rep and the guide that you posted for multiple PHP, but that where I think I got stuff all messed up.

So, yes, I would like to revert repos to SCL.

Could you give me some guidance on how to go about doing that in yum. I'm not that familiar with yum at all, I've only got experience in working with apt. I know I could google it, but within the context of virtualmin, I'd appreciate some pointers from you.

You'd essentially want to disable repositories that are provided by a third party, and then delete packages installed from those third parties.

We can give you some guidance, though we don't have exact commands for all of that.

Let's start here though --

Is this a dedicated server, or a VPS?

Do you have the ability to make a full backup of your system before trying any of that?

It's a VPS and I have just taken a snapshot of the current state. I can rollback if needed. I have also just backed all virtual servers in case of problems.

Any damage I may have caused is limited activity yesterday only, I can't remember any new updates that were installed from the 3rd party repo, but I could be wrong.

I also just want to mention that this was a freshly installed host server and the problems I had with mcrypt are as a result of something going wrong with in SCL repo. The links I mentioned above refer to advice that you had given someone else experiencing a similar problem and advised them to use remi repo.

I don't really understand why mcrypt wasn't available all along? Maybe you can help me and other readers understand what I did wrong in the first place?

Well, the problem you're seeing at the moment is related to dependency issues with third party repositories. Over the years I've gone out of my way to not endorse any third party repositories (or at least I've tried not to!), if you see a comment that I've made that is suggesting using one, let me know so I can review that and possibly add a disclaimer :-)

I unfortunately don't know what the issue is that you were initially experiencing with SCL -- though I'll offer that mcrypt isn't available in the main PHP mcrypt repository. A second SCL repo needs to be added for that to work. But we'll certainly help you sort that out if we can get back to that issue again.t

Okay, so now that you have a backup -- the first thing to do is to go into /etc/yum.repos.d, and disable these third party repositories:

* remi
* remi-php55
* remi-php56
* remi-safe
* webtatic

After doing that, what is the output of this command:

rpm -qa | grep php

That will show us what PHP packages are installed.

Thanks very much for the help on this Andycheck

All mentioned repos are disabled

Output of rpm -qa | grep php

[root@host yum.repos.d]# rpm -qa | grep php
php70-php-xml-7.0.19-1.el7.remi.x86_64
php70-php-process-7.0.19-1.el7.remi.x86_64
php70-php-pecl-zip-1.14.0-1.el7.remi.x86_64
php70-php-tidy-7.0.19-1.el7.remi.x86_64
php70-php-gd-7.0.19-1.el7.remi.x86_64
php70-php-pecl-memcache-3.0.9-0.7.20161124gitdf7735e.el7.remi.x86_64
rh-php56-runtime-2.3-1.el7.x86_64
rh-php56-php-process-5.6.25-1.el7.x86_64
rh-php56-2.3-1.el7.x86_64
php-pear-1.10.4-1.el7.remi.noarch
php70w-common-7.0.18-1.w7.x86_64
php70w-odbc-7.0.18-1.w7.x86_64
php70w-snmp-7.0.18-1.w7.x86_64
php70w-xml-7.0.18-1.w7.x86_64
php70-runtime-1.0-5.el7.remi.x86_64
php70-1.0-5.el7.remi.x86_64
php70w-pdo-7.0.18-1.w7.x86_64
php70w-7.0.18-1.w7.x86_64
php70w-mysql-7.0.18-1.w7.x86_64
php70w-gd-7.0.18-1.w7.x86_64
php70w-mbstring-7.0.18-1.w7.x86_64
php70w-imap-7.0.18-1.w7.x86_64
php70w-xmlrpc-7.0.18-1.w7.x86_64
php70-php-mysqlnd-7.0.19-1.el7.remi.x86_64
php70-php-pecl-apcu-5.1.8-1.el7.remi.x86_64
php70-php-pecl-imagick-3.4.3-1.el7.remi.x86_64
php70-php-mcrypt-7.0.19-1.el7.remi.x86_64
wbm-php-pear-1.6-1.noarch
php70-php-pspell-7.0.19-1.el7.remi.x86_64
php70-php-pear-1.10.4-1.el7.remi.noarch
php70-php-opcache-7.0.19-1.el7.remi.x86_64
php70-php-soap-7.0.19-1.el7.remi.x86_64
php70-php-mbstring-7.0.19-1.el7.remi.x86_64
php70-php-pecl-geoip-1.1.1-1.el7.remi.x86_64
rh-php56-php-pecl-jsonc-1.3.6-3.el7.x86_64
rh-php56-php-cli-5.6.25-1.el7.x86_64
rh-php56-php-pdo-5.6.25-1.el7.x86_64
rh-php56-php-pear-1.9.5-4.el7.noarch
rh-php56-php-mysqlnd-5.6.25-1.el7.x86_64
sclo-php56-php-mcrypt-5.6.28-1.el7.x86_64
php70-php-json-7.0.19-1.el7.remi.x86_64
php70-php-cli-7.0.19-1.el7.remi.x86_64
php70-php-pdo-7.0.19-1.el7.remi.x86_64
php70-php-pecl-apcu-bc-1.0.3-1.el7.remi.x86_64
php70-php-devel-7.0.19-1.el7.remi.x86_64
php70-php-pecl-xmldiff-1.1.2-6.el7.remi.x86_64
php70-php-xmlrpc-7.0.19-1.el7.remi.x86_64
php70-php-pecl-json-post-1.0.1-3.el7.remi.x86_64
rh-php56-php-common-5.6.25-1.el7.x86_64
rh-php56-php-xml-5.6.25-1.el7.x86_64
remi-php56more-epel-7-x86_64-1-2.noarch
php70w-cli-7.0.18-1.w7.x86_64
php70w-pgsql-7.0.18-1.w7.x86_64
php70w-process-7.0.18-1.w7.x86_64
php70-php-common-7.0.19-1.el7.remi.x86_64

Okay, thanks!

You're going to want to remove all of those packages. You can do that using the "rpm -e PACKAGE_NAME" command.

You can technically do it quicker using Webmin -> Software Packages and search for all the PHP packages in that -- but I'd probably suggest using the slower command line method. You're deleting a lot of stuff here, and automated tools can make it easy to accidentally delete more than you bargained for, and/or allow you to miss warnings or problems that yum/rpm is showing.

Once all the PHP packages are removed, reinstall the base CentOS packages with this command:

yum install php php-xml php-gd php-imap php-mysql php-odbc php-pear php-pgsql php-snmp php-xmlrpc php-mbstring

Following that, next perform the steps to install PHP 7 using the SCL repo here:

https://www.virtualmin.com/documentation/web/multiplephp#toc-installing-...

Let us know once you've completed that, and re-run the Re-Check Config in Virtualmin.

Okay, thanks!

You're going to want to remove all of those packages. You can do that using the "rpm -e PACKAGE_NAME" command.

You can technically do it quicker using Webmin -> Software Packages and search for all the PHP packages in that -- but I'd probably suggest using the slower command line method. You're deleting a lot of stuff here, and automated tools can make it easy to accidentally delete more than you bargained for, and/or allow you to miss warnings or problems that yum/rpm is showing.

Once all the PHP packages are removed, reinstall the base CentOS packages with this command:

yum install php php-xml php-gd php-imap php-mysql php-odbc php-pear php-pgsql php-snmp php-xmlrpc php-mbstring

Following that, next perform the steps to install PHP 7 using the SCL repo here:

https://www.virtualmin.com/documentation/web/multiplephp#toc-installing-...

Let us know once you've completed that, and re-run the Re-Check Config in Virtualmin.

Hi Andrycheck

That didn't go so well. I had to restore the backup after performing the above steps. I ended up downloading php files whenever I tried to load anything php related. If I understand correctly, that means php was not running.

This was after httpd restart.

I think I'm in slightly over my head here. Perhaps I should get someone to resolve this for me? Can you suggest anyone?

Perhaps I needed to disable more repos than I had done. Which repos should be enabled?

The list of Repos are

CentOS-Base.repo CentOS-SCLo-scl-rh.repo
remi-php56more-epel-7-x86_64.repo
virtualmin.repo.rpmnew CentOS-CR.repo
CentOS-Sources.repo
remi-php70.repo
virtualmin.repo.rpmsave CentOS-Debuginfo.repo
CentOS-Vault.repo
remi-php71.repo
webtatic-archive.repo CentOS-fasttrack.repo
epel.repo
remi.repo
webtatic.repo CentOS-Media.repo
epel-testing.repo
remi-safe.repo
webtatic-testing.repo CentOS-SCLo-scl.repo
remi-php54.repo
virtualmin.repo

If I run yum repolist enabled

Loaded plugins: fastestmirror, replace Loading mirror speeds from cached hostfile * base: mirror.23media.de Excluding mirror: mirror.de.leaseweb.net Excluding mirror: mirror.nl.leaseweb.net * epel: mirror.23media.de * extras: mirror.23media.de * remi: mirror.23media.de * remi-php55: mirror.23media.de * remi-php56: mirror.23media.de * remi-safe: mirror.23media.de * updates: mirror.23media.de * webtatic: uk.repo.webtatic.com

repo id repo name status base/7/x86_64 CentOS-7 - Base 9,363 centos-sclo-rh/x86_64 CentOS-7 - SCLo rh 4,975 centos-sclo-sclo/x86_64 CentOS-7 - SCLo sclo 402 *epel/x86_64 Extra Packages for Enterprise Linux 7 - x86_64 11,661 extras/7/x86_64 CentOS-7 - Extras 337 remi Remi's RPM repository for Enterprise Linux 7 - x86_64 3,827 remi-php55 Remi's PHP 5.5 RPM repository for Enterprise Linux 7 - x86_64 389 remi-php56 Remi's PHP 5.6 RPM repository for Enterprise Linux 7 - x86_64 389 remi-php56more-epel-7-x86_64 php56more - epel-7-x86_64 341 remi-safe Safe Remi's RPM repository for Enterprise Linux 7 - x86_64 2,035 updates/7/x86_64 CentOS-7 - Updates 1,646 virtualmin/7/x86_64 RHEL/CentOS/Scientific 7 - x86_64 - Virtualmin 80 virtualmin-universal Virtualmin Distribution Neutral Packages 59 webtatic/x86_64 Webtatic Repository EL7 - x86_64 477

You're actually pretty close!

The issue you're seeing just means that there's a PHP config tweak that needs to be made.

It's setup by default on new installs, but you've reminded me that reinstalling PHP would require making that tweak again.

All you'd have to do is edit /etc/httpd/conf.d/php.conf, and comment out the two lines beginning with "SetHandler".

Then restart Apache.

If you continue to see that issue, let us know what output you receive after running this command:

find /etc/httpd | xargs grep -i sethandler

Hi Andrychek

Sorry, I still cannot get this working

When I run find /etc/httpd | xargs grep -i sethandler before I make any changes:

[root@host ~]# find /etc/httpd | xargs grep -i sethandler
grep: /etc/httpd: Is a directory
grep: /etc/httpd/conf: Is a directory
grep: /etc/httpd/conf.d: Is a directory
/etc/httpd/conf.d/php.conf:#    SetHandler application/x-httpd-php
/etc/httpd/conf.d/php.conf:#    SetHandler application/x-httpd-php-source
grep: /etc/httpd/conf.modules.d: Is a directory
grep: /etc/httpd/logs: Is a directory
grep: /etc/httpd/modules: Is a directory
grep: /etc/httpd/run: Is a directory
[root@host ~]#

After I make all the changes that needs to be made, including modifications to php.conf and I run find /etc/httpd | xargs grep -i sethandler

[root@host /]# find /etc/httpd | xargs grep -i sethandler
grep: /etc/httpd: Is a directory
grep: /etc/httpd/conf: Is a directory
grep: /etc/httpd/conf.d: Is a directory
/etc/httpd/conf.d/php.conf.rpmsave:#    SetHandler application/x-httpd-php
/etc/httpd/conf.d/php.conf.rpmsave:#    SetHandler application/x-httpd-php-source
/etc/httpd/conf.d/php.conf:#    SetHandler application/x-httpd-php
/etc/httpd/conf.d/php.conf:#    SetHandler application/x-httpd-php-source
grep: /etc/httpd/conf.modules.d: Is a directory
grep: /etc/httpd/logs: Is a directory
grep: /etc/httpd/modules: Is a directory
grep: /etc/httpd/run: Is a directory
[root@host /]#

No sites load - the apache error log shows the following

[root@host /]# tail -f /var/log/httpd/error_log
[Fri May 26 17:37:10.878853 2017] [fcgid:warn] [pid 2207] mod_fcgid: process 2707 graceful kill fail, sending SIGKILL
[Sat May 27 03:58:14.078240 2017] [fcgid:warn] [pid 2207] mod_fcgid: process 30433 graceful kill fail, sending SIGKILL
[Sat May 27 10:42:46.193672 2017] [mpm_prefork:notice] [pid 1559] AH00170: caught SIGWINCH, shutting down gracefully
[Sat May 27 10:42:48.791630 2017] [suexec:notice] [pid 14510] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Sat May 27 10:42:48.853894 2017] [ssl:warn] [pid 14510] AH02292: Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)
[Sat May 27 10:42:48.950176 2017] [auth_digest:notice] [pid 14510] AH01757: generating secret for digest authentication ...
[Sat May 27 10:42:48.951492 2017] [lbmethod_heartbeat:notice] [pid 14510] AH02282: No slotmem from mod_heartmonitor
[Sat May 27 10:42:48.970285 2017] [ssl:warn] [pid 14510] AH02292: Init: Name-based SSL virtual hosts only work for clients with TLS server name indication support (RFC 4366)
[Sat May 27 10:42:49.080097 2017] [mpm_prefork:notice] [pid 14510] AH00163: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips mod_fcgid/2.3.9 PHP/5.4.16 SVN/1.7.14 configured -- resuming normal operations
[Sat May 27 10:42:49.080172 2017] [core:notice] [pid 14510] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'
php7.0.fcgi: line 10: /bin/php70-cgi: No such file or directory
php7.0.fcgi: line 10: /bin/php70-cgi: No such file or directory
php7.0.fcgi: line 10: /bin/php70-cgi: No such file or directory
php7.0.fcgi: line 10: /bin/php70-cgi: No such file or directory

Just for reference and to avoid scrolling all the way to the top, the following is the list of PHP70 packages before I delete them:

[root@host ~]# rpm -qa | grep php
php70-php-xml-7.0.19-1.el7.remi.x86_64
php70-php-process-7.0.19-1.el7.remi.x86_64
php70-php-pecl-zip-1.14.0-1.el7.remi.x86_64
php70-php-tidy-7.0.19-1.el7.remi.x86_64
php70-php-gd-7.0.19-1.el7.remi.x86_64
php70-php-pecl-memcache-3.0.9-0.7.20161124gitdf7735e.el7.remi.x86_64
rh-php56-runtime-2.3-1.el7.x86_64
rh-php56-php-process-5.6.25-1.el7.x86_64
rh-php56-2.3-1.el7.x86_64
php-pear-1.10.4-1.el7.remi.noarch
php70w-pgsql-7.0.19-1.w7.x86_64
php70w-imap-7.0.19-1.w7.x86_64
php70w-snmp-7.0.19-1.w7.x86_64
php70-runtime-1.0-5.el7.remi.x86_64
php70-1.0-5.el7.remi.x86_64
php70-php-mysqlnd-7.0.19-1.el7.remi.x86_64
php70-php-pecl-apcu-5.1.8-1.el7.remi.x86_64
php70-php-pecl-imagick-3.4.3-1.el7.remi.x86_64
php70-php-mcrypt-7.0.19-1.el7.remi.x86_64
wbm-php-pear-1.6-1.noarch
php70-php-pspell-7.0.19-1.el7.remi.x86_64
php70-php-pear-1.10.4-1.el7.remi.noarch
php70-php-opcache-7.0.19-1.el7.remi.x86_64
php70-php-soap-7.0.19-1.el7.remi.x86_64
php70-php-mbstring-7.0.19-1.el7.remi.x86_64
php70-php-pecl-geoip-1.1.1-1.el7.remi.x86_64
rh-php56-php-pecl-jsonc-1.3.6-3.el7.x86_64
rh-php56-php-cli-5.6.25-1.el7.x86_64
rh-php56-php-pdo-5.6.25-1.el7.x86_64
rh-php56-php-pear-1.9.5-4.el7.noarch
rh-php56-php-mysqlnd-5.6.25-1.el7.x86_64
sclo-php56-php-mcrypt-5.6.28-1.el7.x86_64
php70w-common-7.0.19-1.w7.x86_64
php70w-cli-7.0.19-1.w7.x86_64
php70w-mysql-7.0.19-1.w7.x86_64
php70w-odbc-7.0.19-1.w7.x86_64
php70w-process-7.0.19-1.w7.x86_64
php70w-xml-7.0.19-1.w7.x86_64
php70w-gd-7.0.19-1.w7.x86_64
php70-php-json-7.0.19-1.el7.remi.x86_64
php70-php-cli-7.0.19-1.el7.remi.x86_64
php70-php-pdo-7.0.19-1.el7.remi.x86_64
php70-php-pecl-apcu-bc-1.0.3-1.el7.remi.x86_64
php70-php-devel-7.0.19-1.el7.remi.x86_64
php70-php-pecl-xmldiff-1.1.2-6.el7.remi.x86_64
php70-php-xmlrpc-7.0.19-1.el7.remi.x86_64
php70-php-pecl-json-post-1.0.1-3.el7.remi.x86_64
rh-php56-php-common-5.6.25-1.el7.x86_64
rh-php56-php-xml-5.6.25-1.el7.x86_64
remi-php56more-epel-7-x86_64-1-2.noarch
php70w-pdo-7.0.19-1.w7.x86_64
php70w-7.0.19-1.w7.x86_64
php70w-mbstring-7.0.19-1.w7.x86_64
php70w-xmlrpc-7.0.19-1.w7.x86_64
php70-php-common-7.0.19-1.el7.remi.x86_64


The following is the list of PHP packages after reinstallation

[root@host yum.repos.d]# rpm -qa | grep php
rh-php56-runtime-2.3-1.el7.x86_64
rh-php56-php-process-5.6.25-1.el7.x86_64
rh-php56-2.3-1.el7.x86_64
php-cli-5.4.16-42.el7.x86_64
php-5.4.16-42.el7.x86_64
php-gd-5.4.16-42.el7.x86_64
php-xmlrpc-5.4.16-42.el7.x86_64
rh-php70-php-common-7.0.10-2.el7.x86_64
rh-php70-php-pear-1.10.1-3.el7.noarch
php-pdo-5.4.16-42.el7.x86_64
php-xml-5.4.16-42.el7.x86_64
php-pear-1.9.4-21.el7.noarch
php-mysql-5.4.16-42.el7.x86_64
php-pgsql-5.4.16-42.el7.x86_64
php-imap-5.4.16-3.el7.x86_64
php-snmp-5.4.16-42.el7.x86_64
wbm-php-pear-1.6-1.noarch
rh-php56-php-pecl-jsonc-1.3.6-3.el7.x86_64
rh-php56-php-cli-5.6.25-1.el7.x86_64
rh-php56-php-pdo-5.6.25-1.el7.x86_64
rh-php56-php-pear-1.9.5-4.el7.noarch
rh-php56-php-mysqlnd-5.6.25-1.el7.x86_64
sclo-php56-php-mcrypt-5.6.28-1.el7.x86_64
rh-php70-runtime-2.3-1.el7.x86_64
rh-php70-php-zip-7.0.10-2.el7.x86_64
rh-php70-php-cli-7.0.10-2.el7.x86_64
rh-php70-php-process-7.0.10-2.el7.x86_64
rh-php70-php-pdo-7.0.10-2.el7.x86_64
rh-php70-2.3-1.el7.x86_64
rh-php56-php-common-5.6.25-1.el7.x86_64
rh-php56-php-xml-5.6.25-1.el7.x86_64
remi-php56more-epel-7-x86_64-1-2.noarch
php-common-5.4.16-42.el7.x86_64
php-process-5.4.16-42.el7.x86_64
php-odbc-5.4.16-42.el7.x86_64
php-mbstring-5.4.16-42.el7.x86_64
rh-php70-php-json-7.0.10-2.el7.x86_64
rh-php70-php-xml-7.0.10-2.el7.x86_64
rh-php70-php-mysqlnd-7.0.10-2.el7.x86_64

Hi Andrychek

I'd like to take a few steps back on this issue.

My original problem was installing mcrypt. I've since got it working by installing the remi repo. My whole mission now is to revert to the correct repos based on your advice.

The issue is that there were some PHP packages conflicting with others and seemed to point to those packages installed from webtatic repo. I don't remember installing webtatic myself.

So far things are working fine and I think I'm just panicking based on your advice to use the correct repos, which is fine and I'd like to do that eventually and I'll probably purchase paid support for that.

For now, I think I should close this issue. "If it ain't broke...." you know the rest

What are the risks for now, what will happen as a result of not using the SCL repos for future PHP updates?

Ah, reviewing the errors you were receiving, I think the issue is that some of your domains were configured to use the PHP 7 version from the REMI repo, and the path of the PHP binary in that repo is different from the path in the SCL repo.

If it's working fine, there's no need to change it -- but if you're ever looking to try again in the future, what I'd suggest is first switch all your domains back to the standard CentOS PHP version, run the Virtualmin Re-Check Config (in Systems Settings), which will ensure Virtualmin knows about all your PHP versions -- and then go back in and change all the domains you want on PHP 7 to that PHP version.

Doing that should set it up with the proper PHP location.

As far as the risks -- software versions that come with CentOS, and software from official repositories, are much better tested. There's a lower risk of bugs and security issues, and a lower risk of problems while updating. Some folks also have problems when initially configuring alternate repositories, as the PHP config can sometimes conflict with the way Virtualmin configures FCGID/CGI.

However, if it's working for you, there's certainly others using it too!