This morning I got a notice from my CentOS 7 and Interworx v. 6 server that says, “Yum update failing: yum update --disablerepo=interworx-cp*”. I realize this may be more of a CentOS question than an Interworx question, so feel free to let me know if that is the case.
I enabled remi-php80 a couple of days ago to begin testing with PHP 8.0. The affected files all appear to be related to PHP 8.0.
This is the output I get when I try to run Nodeworx → Server → Software Updates, Available Updates, Install Updates:
±-----------------------------------------------------------------------------+
| InterWorx YUM Update Management |
±-----------------------------------------------------------------------------+
Update Process Began: 2020-11-30 12:10:30
±-----------------------------------------------------------------------------+
| Updating specified packages |
±-----------------------------------------------------------------------------+
Resolving Dependencies–>
Running transaction check—>
Package php.x86_64 0:7.4.13-1.el7.remi will be updated—>
Package php.x86_64 0:8.0.0-1.el7.remi will be an update—>
Package php-cli.x86_64 0:7.4.13-1.el7.remi will be updated—>
Package php-cli.x86_64 0:8.0.0-1.el7.remi will be an update—>
Package php-common.x86_64 0:7.4.13-1.el7.remi will be updated–>
Processing Dependency: php(api) = 20190902-64 for package: php-ioncube-loader-10.4.5-1.el7.remi.7.4.x86_64–>
Processing Dependency: php(zend-abi) = 20190902-64 for package: php-ioncube-loader-10.4.5-1.el7.remi.7.4.x86_64—>
Package php-common.x86_64 0:8.0.0-1.el7.remi will be obsoleting—>
Package php-devel.x86_64 0:7.4.13-1.el7.remi will be updated—>
Package php-devel.x86_64 0:8.0.0-1.el7.remi will be an update—>
Package php-fpm.x86_64 0:7.4.13-1.el7.remi will be updated—>
Package php-fpm.x86_64 0:8.0.0-1.el7.remi will be an update—>
Package php-gd.x86_64 0:7.4.13-1.el7.remi will be updated—>
Package php-gd.x86_64 0:8.0.0-1.el7.remi will be an update—>
Package php-imap.x86_64 0:7.4.13-1.el7.remi will be updated—>
Package php-imap.x86_64 0:8.0.0-1.el7.remi will be an update—>
Package php-intl.x86_64 0:7.4.13-1.el7.remi will be updated—>
Package php-intl.x86_64 0:8.0.0-1.el7.remi will be an update—>
Package php-json.x86_64 0:7.4.13-1.el7.remi will be obsoleted—>
Package php-mbstring.x86_64 0:7.4.13-1.el7.remi will be updated—>
Package php-mbstring.x86_64 0:8.0.0-1.el7.remi will be an update—>
Package php-mysqlnd.x86_64 0:7.4.13-1.el7.remi will be updated—>
Package php-mysqlnd.x86_64 0:8.0.0-1.el7.remi will be an update—>
Package php-opcache.x86_64 0:7.4.13-1.el7.remi will be updated—>
Package php-opcache.x86_64 0:8.0.0-1.el7.remi will be an update—>
Package php-pdo.x86_64 0:7.4.13-1.el7.remi will be updated—>
Package php-pdo.x86_64 0:8.0.0-1.el7.remi will be an update—>
Package php-pecl-mcrypt.x86_64 0:1.0.3-1.el7.remi.7.4 will be updated—>
Package php-pecl-mcrypt.x86_64 0:1.0.3-4.el7.remi.8.0 will be an update—>
Package php-pecl-zip.x86_64 0:1.19.2-1.el7.remi.7.4 will be updated—>
Package php-pecl-zip.x86_64 0:1.19.2-1.el7.remi.8.0 will be an update—>
Package php-process.x86_64 0:7.4.13-1.el7.remi will be updated—>
Package php-process.x86_64 0:8.0.0-1.el7.remi will be an update—>
Package php-soap.x86_64 0:7.4.13-1.el7.remi will be updated—>
Package php-soap.x86_64 0:8.0.0-1.el7.remi will be an update—>
Package php-sodium.x86_64 0:7.4.13-1.el7.remi will be updated—>
Package php-sodium.x86_64 0:8.0.0-1.el7.remi will be an update—>
Package php-xml.x86_64 0:7.4.13-1.el7.remi will be updated–>
Processing Dependency: php-xml(x86-64) = 7.4.13-1.el7.remi for package: php-xmlrpc-7.4.13-1.el7.remi.x86_64—>
Package php-xml.x86_64 0:8.0.0-1.el7.remi will be an update–>
Running transaction check—>
Package php-common.x86_64 0:7.4.13-1.el7.remi will be updated–>
Processing Dependency: php(api) = 20190902-64 for package: php-ioncube-loader-10.4.5-1.el7.remi.7.4.x86_64–>
Processing Dependency: php(zend-abi) = 20190902-64 for package: php-ioncube-loader-10.4.5-1.el7.remi.7.4.x86_64—>
Package php-pecl-xmlrpc.x86_64 0:1.0.0~DEV.20200602-4.el7.remi.8.0 will be obsoleting—>
Package php-xmlrpc.x86_64 0:7.4.13-1.el7.remi will be obsoleted–>
Finished Dependency Resolution
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
To my inexperienced eyes, it looks like there are some broken dependencies for PHP 8.0. Am I jumping the gun with PHP 8.0, and just need to wait a bit to try running it in Interworx v. 6/CentOS 7? Skipping the broken dependencies doesn’t sound alike a good approach to me. From what I can tell, the command:
rpm -aV --nofiles --nodigest
just “checks the consistency of installed packages,” whatever that means, and doesn’t sound like a fix.
We use remi-safe for PHP8 and turning on remi-php8 does indeed bring those issues.
So I would consider @iworx-brandon to be correct and it is trying to replace some packages belonging to php7.4 as well
I did not think php8 was fully released as yet, thought it was RC5 and still no ioncube loader available I think.
If you want to test it, I woudl disbale remi-php8 and enable remi-safe which should install packages you showed (see pciture) but a warning, remi-safe may try to update other php versions to remi-safe
I would be very interested to know what @iworx-brandon finds if you open a support
I do have remi-safe enabled, and I still have PHP 7.3 and 7.4 enabled.
If I’m correctly understanding what you’re both saying, it sounds like I should wait until things with PHP 8.0 settle down and try again. I don’t need PHP 8.0 yet, I was just going to install it to do some testing. It’s not worth a support ticket at this point.
I think it’s fine to install php 8.0 in your multiple PHP settings. I think the issue is that enabling the way you have has caused them to conflict with the system PHP version. Its tough to know exactly what might have happened without actually seeing your repo files, etc.
The offer still stands if you’d like us to take a look.
@iworx-brandon - it looks likely our 7hi server is setup very similar to linux4me, as if we enable remi-php8, we see the same errors
I will open a support ticket so you can look at our server to see whats happening, as we used IW multiphp to install php8, with SSH to install packages for it.
There is absolutely no rush on this, it’s if you have time or interest and I never thought of system php been the php version it was trying to change. If so, as softaculous relies on system PHP detection to work (and I appreciate you can preset it so it no longer detects php version) and system php presumably does not need to be fully working (sorry of I am wrong) then it maybe alright to update php8 - but no ioncube for php8 which may stop softculous
@d2d4j please post the fix here if you get one. I’m in no hurry, either, and it will be while before things calm down enough for me to pursue this with a support ticket, so I appreciate you doing so.
I set this up on one of my test VMs and was able to reproduce the error you’re seeing. It’s 100% related to the fact that there is no ioncube-loader in PHP 8.0. Running it from the command line gave me a little more clarity on the issue it was facing:
The above is basically saying “you told me to update the files that ioncube-loader relies on, but ioncube-loader is still using the previous version, so we don’t want to do anything until you sort that out”. If you really want to use PHP 8.0 as your SystemPHP version, you’ll likely need to uninstall ioncube-loader.
Having said that, PHP 8.0 should be fine to run for domains as a Multi-PHP version. If you’re already using Multi-PHP, I’m not sure what advantage using PHP 8 as a system PHP version gets you. Though I am open to heard from actual hosters on what advantages you might see from doing so.
It seems that at this point, until ioncube-loader is available for PHP 8.0 (and potentially other missing packages that we haven’t come across yet), it’s best to leave the System PHP version on 7.4 or 7.3, which ships with InterWorx (at least recently).
@iworx-brandon, Maybe it was @d2d4j that was trying to use PHP 8.0 as the system PHP version? I was just trying to make it available for Multi-PHP. Ioncube usually does seem to lag a bit behind the new PHP releases, so a new, PHP 8.0 version may be out for it soon and solve this.
@linux4me Your output would suggest otherwise. Multi-PHP versions are packaged as phpXX-php, for instance php74-php. Based on the output you provided, the update is looking to update just plain php which is the system version.
If you set the enabled flag in /etc/yum.repos.d/remi-php80.repo to enabled, you’d be updating the System PHP not Multi-PHP.
Please check the /etc/yum.repos.d/remi-php80.repo file and ensure that the enabled field is set to 0 like below:
[remi-php80]
name=Remi's PHP 8.0 RPM repository for Enterprise Linux 7 - $basearch
#baseurl=http://rpms.remirepo.net/enterprise/7/php80/$basearch/
#mirrorlist=https://rpms.remirepo.net/enterprise/7/php80/httpsmirror
mirrorlist=http://cdn.remirepo.net/enterprise/7/php80/mirror
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-remi
I believe the problem in this case was behind the keyboard. I think what I was doing wrong was enabling the remi-php80 repository in Software Updates thinking I needed to do that to make PHP 8.0 available for Multi-PHP. I have it disabled there now.
I just went Nodeworx → Web Server → Multi-PHP versions and enabled PHP 8.0. When I run: yum list installed *php8*
all the packages appear to be there, except for Ioncube, of course.
That brings up another question. Assuming I want to stick with the default system PHP version for a nice, stable system, which version(s) of PHP should I have enabled in Nodeworx → Software Updates → Yum Software Repositories. Currently, both remi-php73 and remi-php74 are enabled.
Yep, that would do it. I was focusing on the yum.repos.d file since that is usually how I enable/disable repos. The main point was that the repo was enabled (however it was done). You do not need to manually enable any repos to install a PHP version for use with Mutli-PHP, the software handles that for you. This is a failing on our part regarding the explanation of this principle.
The remi-php73 is enabled by default on all new installs, so I suppose that would be considered the most “stable” or at least most in line with what support usually sees.
The only reason I started to suspect that you and John were both enabling the repos was that both your servers had 7.4 as the System PHP version. That’s not something we typically see.
If most of your domains are using a Multi-PHP version, there isn’t really much that the System PHP version is doing. I believe at that point it would basically just be handling softaculous stuff (since InterWorx has it’s own PHP version for handling itself).
Thanks @iworx-brandon. I guess the system uses the latest version that’s enabled in the repos. Should I only have one repo enabled with a remi-phpXX version for the system?
It has been a while, but if I remember correctly I had an issue with WHMCS using the system version to run a cron job and complaining about it. The system version at the time was 7.3, I think, and WHMCS was on a subdomain still using PHP 7.2 (all it supported at the time). So maybe cron still uses the system version?
You can have multiple repos enabled, it will just install the latest version that is enabled. Just like how yum will update a package from package-1.0 if it sees package-1.1 is available, it will treat the newest version as an update to the older versions and install that version. I hope that makes sense.
It is likely that cron uses the system version of PHP by default based on the default PATH for crontabs. Having said that, you can change your PATH variable for different crontabs, so depending on what was being required, you could limit it to the specific php executable that you desired in /opt/remi/phpXX/root/usr/bin/ (for versions 7.1 and above). If you find yourself running into a lot of issues with that, updating System PHP is a perfectly acceptable option. Just another way to go about things.
@iworx-brandon@linux4me - I think the issue as described with whmcs and cron jobs is as follows:
when a siteworx user changes the PHP version, it does not change the default PHP version assigned to the account
Sorry that sounds confusing, so if you look at the pictures, you will see a siteworx account from reseller edit mode, showing default PHP version (in this case PHP7.2) but if you then look at the siteworx user PHP version, you will see it is PHP7.3 and finally, as we are using whmcs as an example, you will the system health status showing a mismatch between cron PHP versions, PHP7.2 to PHP7.3
This behaviour may have changed though as it has been highlighted on the forums before, could even be @linux4me who raised the issue, sorry cannot remember and I am not sure what the outcome was. May have been a note to devs
I guess I’ll need to spin up another server and test latest IW v7 anyway, but too close to christmas
I am sorry, it was not me who wanted system PHP to PHP8, I only pointed out that if I enabled the same remi repo, then the same errors happened.
I am confused now over the repos but a few days I think I will get it, hopefully and I think it has changed from previous IW versions and just not realised.
In summary, using the UI, in Nodeworx v. 6, Server -> Software Updates -> Yum software repositories, the latest remi-PHPXX you have enabled will be the system PHP version used for Softaculous and cron, and you only need to have one enabled.
In System -> Web Services -> Web Server -> Multiple PHP Versions, you can select whichever PHP versions you want available to Siteworx users and don’t have to enable the corresponding “remi-phpXX” repository for them because they are taken from the “remi-safe” repo.
I think my workaround for the WHMCS cron job was to use “/usr/bin/php7X” for the cron command.
Sounds like you’ve got it. I will admit that it can be confusing and I wasn’t sure I was explaining myself well enough to get that across, so I’m glad you’ve got it.
/usr/bin/php7X is just a symbolic link to the /opt/remi/php7X/root/user/bin/php path that I mentioned above so really just another way to get to the same end. Whatever works, right?!
Got it! Yes, you did explain it well. From my point of view, this one is solved, though @d2d4j sounds like he has some remaining questions that are over my head.
@linux4me sorry I always have questions but sometimes go quiet to think or not confuse further.
I understood @iworx-brandon but wanted time for it to sink in and make sure I understood. This was different to how it used to be and even when multiphp came, so was not aware of the change or to used to manually doing it by SSH. Perhaps this should be published on the forums or made clear on the version history page of IW as I have been advising users to enable the repos as we used to. Oh dear…
My point I was trying to make re whmcs as an example you listed, is the default PHP set on the siteworx account never is updated when the siteworx user logs into their account and changes the PHP version (I woudl expect the default PHP to change to the chosen version) however, checking shows their vhost file does update to chosen PHP version.
So why does whmcs health check show crons using php 7.2 and whmcs using PHP 7.3.
strangely though, whmcs shpws as using system PHP from (etc/php.ini) which is version PHP 7.3
I do know whmcs has an advanced cron problem solver and expressly shows using your methods to tell which PHP to use for cron jobs, so maybe it does not matter anyway.
The only other thought I had was, if IW multi php is using remi safe, then the php options from webserver should show the multi PHP version as remi-safe. This I had not seen except after I enabled Remi-safe, so just wanted to test this on a new server
Sorry for my ramblings, but hope you now understand a little better
At first, I had a little trouble wrapping my head around being able to install a version of PHP (with Multi-PHP in the Web Server section) without enabling the repo corresponding to the version I wanted, but it makes perfect sense that the UI would handle that for us.
