Zabbix 3.4.15 compatibility issue with PHP version rh-php72

[subeesh]

Hi ,

Currently I am using the Zabbix server (3.4.15) along with PHP 5.4.16. I need to upgrade the PHP to latest version 7.2 for fixing the vulnerability .

Could someone suggest me, does current Zabbix support PHP7.2 (rh-php72-1-2.el7.x86_64 ?



Thanks
SUBEESH

[tim.mooney]

If you're using Red Hat Enterprise Linux 7's default OS version of php 5.4, then Red Hat is backporting security fixes for vulnerabilities discovered in later versions. Even though the PHP developers may no longer support PHP 5.4.16, one of the benefits you get from using a distro with a very long support life is that Red Hat takes responsibility to backport security fixes.

In other words, as long as you apply the latest package releases from Red Hat for php 5.4.16, you should get the fixes.

See: Red Hat PHP versions and the page on Red Hat security backports

Many security scanning tools will generate false positives when scanning e.g. apache httpd or php on distros like Red Hat, where you can't just look at the version the software reports (e.g. apache httpd 2.4.6 or php 5.4.16), because it's not really apache httpd 2.4.6, it's Apache 2.4.6 + a bunch of Red Hat patches, including security patches.

As far as PHP 7.2, you should check the installation sections of the Zabbix manual for the appropriate version of Zabbix, to see what the software requirements are. PHP 7.2 brings many improvements to the language and some versions of Zabbix do support it. Check the manual for more information.

[subeesh]

Thank you very much for your support,


Redhat changed the package name php to rh-php and zabbix 4.0 is not recognizing this change in the package level. While installing the Zabbix 4.0 it is looking only for php instead of rh-php.

Would you know how to resolve this issue? Advance thank you

[tim.mooney]

The right way to fix it is to build your own packages from a source RPM, following the guidelines for packaging with Software Collections.

There's another way to fix it, but it's a hack and it's difficult to explain and it still involves building custom packages. You would essentially build "wrapper" packages that satisfy the original package name requirements while actually themselves requiring the SCL packages.