sparek-3

Well-Known Member
Aug 10, 2002
2,148
265
388
cPanel Access Level
Root Administrator
I've got all of my servers set to do manual updates, i.e.

RPMUP=manual
SARULESUP=daily
STAGING_DIR=/usr/local/cpanel
UPDATES=manual


Yet it seems overnight last night, some of my servers updated some of the PHP 7.1 updates.

Not all servers updated this, I'm still trying to find out what's common amongst the ones that did update.

But was there an error some where within the cPanel update process that caused this?

Despite having manual updates enabled, /scripts/upcp runs every night. This upcp process (I presume) will always update some packages, specifically wordpress-cpaddon and it's related packages. I haven't figured out how to stop that update, but it's not a huge issue since wordpress-cpaddon is used solely by cPanel and isn't really a system-level package.

One of the packages updated on some of the servers was:

ea-php71-php-cli-7.1.28-1.1.1.cpanel.x86_64

Yet the package

ea-php71-7.1.28-1.1.1.cpanel.x86_64

was not updated.

All of this just seems strange.

I'm just wondering if some wires got crossed some where and some PHP 7.1 (PHP 5.6 and PHP 7.0 do not appear to be affected by this) got flagged as packages like wordpress-cpaddon and caused them to be updated in the nightly upcp run. This was caught and fixed at some point.

Anybody else using automatic updates and notice this last night?

Checking on this a bit further, I don't think this is related to upcp. Looks like the packages were updated on one server a couple of hours before upcp ran.
 

sparek-3

Well-Known Member
Aug 10, 2002
2,148
265
388
cPanel Access Level
Root Administrator
As is almost always the case, I post a query and then I dive deeper into it to answer my own question.

This appears to have been caused by the /usr/local/cpanel/whostmgr/docroot/cgi/cpaddons_report.pl --notify cron.

This is the process that runs and updates the wordpress-cpaddon packages.

Apparently (?) the updated wordpress-cpaddon-php71 package now requires ea-php71-php-iconv and ea-php71-php-mbstring, (from the best I can tell - the servers affected by this did not have these packages installed prior to the cpaddons_report.pl cron running) so when this update was triggered, the ea-php71-php-iconv and ea-php71-php-mbstring dependencies had to be satisfied, so they were installed. And probably because these packages (which are PHP 7.1.28) had dependencies on other php71 packages, those dependencies then had to be met. And this caused those packages to be updated as well. This is why there is a mix and match of PHP 7.1.27 (I had not gotten around to updated PHP on all server - remember I use manual updates) and PHP 7.1.28 packages.

Hope this helps to explain things. I understand why it happened now. I feel better now.
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,880
2,260
463
Hello @sparek-3,

You are correct. The iconv and mbstring PHP extensions were added as dependencies for the WordPress Manager package (these PHP extensions are required for wp-cli functionality). For reference, the case number was CPANEL-24343.

Let us know if you have any additional questions about this change.

Thank you.