Forum Stats

  • 3,825,270 Users
  • 2,260,492 Discussions
  • 7,896,474 Comments

Discussions

PHP + Oniguruma

andreas.dijkman
andreas.dijkman Member Posts: 92 Bronze Badge
edited May 17, 2021 6:23AM in Oracle Linux

Oracle has updated their oniguruma-package to 6.8.2, the same as the upstream-epel-version. But now the update breaks php-mbstring (with at least 7.4) from OL7 breaks with the updated version of oniguruma, as it depends on the older version.

@Avi Miller-Oracle I hope this is a known issue with the package-team?

Best Answer

Answers

  • Sergio-Oracle
    Sergio-Oracle Member Posts: 2,660 Employee

    If I understand the problem correctly, you should disable the EPEL repo if you intend to use PHP and related packages from base OL7 repo.

  • andreas.dijkman
    andreas.dijkman Member Posts: 92 Bronze Badge

    It doesn't say that anymore on the PHP-page of yum.oracle.com: http://yum.oracle.com/oracle-linux-php.html

    I have enabled the Oracle-version of EPEL and this is the error:

    --> Finished Dependency Resolution
    Error: Package: php-mbstring-7.4.19-1.0.1.el7.x86_64 (@monthly-oraclelinux7-x86_64-php74)
               Requires: libonig.so.2()(64bit)
               Removing: oniguruma-5.9.5-3.el7.x86_64 (@monthly-epel7-oraclelinux7-x86_64)
                   libonig.so.2()(64bit)
               Updated By: oniguruma-6.8.2-1.el7.x86_64 (monthly-epel7-oraclelinux7-x86_64)
                  ~libonig.so.5()(64bit)
    

    Where should I get libonig.so.2, that is needed by php-mbstring, other than EPEL (from Oracle)?

  • andreas.dijkman
    andreas.dijkman Member Posts: 92 Bronze Badge
    edited May 17, 2021 6:28AM

    To answer my own question, oniguruma 5.9.5 is available in Oracle Linux 7 Latest repository.

    But the PHP-install-page doesn't mention EPEL anymore and I think it's a bit odd that you have to disable EPEL these days. I've fixed the problem by excluding oniguruma from the (Oracle) EPEL-repository.

  • Sergio-Oracle
    Sergio-Oracle Member Posts: 2,660 Employee
    Answer ✓

    This behavior seems to be due to a recent change in PHP. As of PHP 7.4 mbstring no longer bundles oniguruma.

    As you point our, OL7 Latest has the version of oniguruma that meets the Requires for mbstring included with PHP7.4, but with EPEL enabled, you'll see interference from a newer upstream version of oniguruma.

  • DEWUnix
    DEWUnix Member Posts: 3 Blue Ribbon

    Our team has raised a service request with Oracle on this as this breaks Ol Manager updates - as any single package update failure will fail out the entire target server patch update.

    Excluding EPEL is not an option as it's used often by many applications

    Excluding PHP MB-String from EPEL also is not good as it permanently locks php-mbstring to an old version.

    What if PHP-mbstring has a published CVE and it requires an update

    The only work arounds could be

    1 - Use another repo combination that allows PHP and mbstring - eg RHEL

    2 - Compile our own PHP mbstring and have that as a local repo used by our server fleet enrolled in OL Manager

    I am interested how others have solved this issue - beyond the obvious workarounds previously posted in this forum.

  • andreas.dijkman
    andreas.dijkman Member Posts: 92 Bronze Badge
    [ol7_developer_EPEL]
    name=Oracle Linux $releasever EPEL Packages for Development ($basearch)
    baseurl=https://yum$ociregion.$ocidomain/repo/OracleLinux/OL7/developer_EPEL/$basearch/
    gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
    gpgcheck=1
    enabled=1
    exclude=oniguruma
    

    We have excluded oniguruma from EPEL, so it's not installed or upgraded (last line of the code above).

    But I agree, the better fix would be to fix the compile-issue and upgrade it with a newer version of oniguruma.

  • DEWUnix
    DEWUnix Member Posts: 3 Blue Ribbon

    Yes that is what we have done to some servers but its a hack as you have now placed that package into 'cold storage' forever until the repo it comes from bothers to upgrade it.

    Its really not an acceptable solution unfortunately.

  • andreas.dijkman
    andreas.dijkman Member Posts: 92 Bronze Badge

    Well, I think in this case it is not a hack, as the PHP-packages are built on top of the base OL7-packages, where onigurama 5.x is included by Oracle. The EPEL-community decided to include oniguruma 6.x, not Oracle.

    I agree that it would suite everyone best if Oracle would update there own version of oniguruma to a compatible version that is included in EPEL, but I doubt that is happening this late in the cycle of OL7. OL9 is right around the corner and even OL8(.6) is a better match for PHP-versions these days ( PHP 8.0, finally! 🤗 ) than the aging OL7 with PHP 7.4.

    The best solution in this case would be to migrate/upgrade to OL8 (or even OL9 when it is released) and just leave OL7 wherever it is now (TLSv1.3 for example...)

  • DEWUnix
    DEWUnix Member Posts: 3 Blue Ribbon

    Its good to hear OL9 may be a better option - but in reality Enterprise do not run bleeding edge versions of OL.

    Most run N-1 to ensure a more stable platform.

    I get your point on OL7 being low on Oracle's radar and I agree it was out of Oracle's control.

    We are in the process of looking at OL8 now but that will be some time away.