Forum Stats

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

Discussions

Categories

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?

· Share on TwitterShare on Facebook

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.

    · Share on TwitterShare on Facebook
  • 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)?

    · Share on TwitterShare on Facebook
  • 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.

    · Share on TwitterShare on Facebook
  • 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.

    https://www.php.net/manual/en/mbstring.installation.php

    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.

    · Share on TwitterShare on Facebook
  • 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.

    · Share on TwitterShare on Facebook
  • andreas.dijkman
    andreas.dijkman Member Posts: 92 Bronze Badge
    https://community.oracle.com/tech/apps-infra/discussion/comment/16838162#Comment_16838162 
    [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.

    · Share on TwitterShare on Facebook
  • 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.

    · Share on TwitterShare on Facebook
  • 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...)

    · Share on TwitterShare on Facebook
  • 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.

    · Share on TwitterShare on Facebook