500 Error on Grommunio Web

[AndrewMRQuinn]

Commit bcda7c7 seems to have introduced an error in Grommunio Web, at least when running on RHEL9. Grommunio Web will not load, simply presenting a HTTP 500 status error.
There is some discussion in the community forum although there may be several different causes of 500 errors in that post.
In my case, reverting the changes to lines 1709, 1734, and 1949 on ‎class.baserecurrence.php in that commit solves the problem (i.e. replace $this->sortExceptionStart(...) with [$this, "sortExceptionStart"] and $this->sortStarttime(...) with [$this, "sortStarttime"]).

Unfortunately I have to re-edit the file every time I update Grommunio.
I'm not familiar enough with PHP that I'd feel comfortable submitting a PR to revert it, in case it causes a problem for people on other distros. Hopefully this is sufficient for someone more knowledgeable in that area to pick it up.

[gromandreas]

Hi @AndrewMRQuinn ,

which PHP version is currently installed on your RHEL 9 system? Are you considering upgrading to RHEL 10?

[AndrewMRQuinn]

Hi @gromandreas
The default PHP version that comes with RHEL 9 is PHP 8.0. I have this installed, with latest updates (8.0.30).
RHEL 9 also has optional application streams for PHP 8.1, 8.2, and 8.3; so I could try changing to one of those if it is likely to make a difference?
I would consider updating to RHEL 10 once it is supported. Judging by the Grommunio roadmap, this should be in the next release.

[gromandreas]

Hi @AndrewMRQuinn ,

yes, changing to PHP 8.2 will likely make a difference. It would be great if you could try that and provide feedback.

[AndrewMRQuinn]

I gave it a try @gromandreas
It looks like Grommunio depends on some packages from EPEL (php-pecl-igbinary, php-pecl-msgpack, php-pecl-redis5, php-sodium). These EPEL packages are only available for the default RHEL 9 application stream PHP 8.0, so attempting to switch to another version of PHP on RHEL 9 blocks due to missing dependencies.

I did give the unofficial "Remi's" repo a try instead of Red Hat's to see how that fared. It had all of the necessary modules, but didn't seem to play nicely with the MAPI module (error about being compiled with different module APIs).

[gromandreas]

Hi @AndrewMRQuinn ,

thank you for the feedback. It's a pity that it didn't work out with a higher PHP version.

I'll raise the issue internally how we may solve until RHEL 10 is fully supported.

[dfied]

@gromandreas Todays version of mapi-header-php (2.0.2.b915f62) still has the issue @AndrewMRQuinn reported.
The workaround Andrew found by editing the file class.baserecurrence.php isn't working any more - I guess due to other code changes in the project.
So for now grommunio-web is fullly broken on my Rocky Linux 9 (EL9) box.

Is there any chance a php developer may find a working solution for php 8.0+ for these three "lines of code"?
My php times ended more than 15 years ago - so I even don't understand the syntax with "..." in the function call.

The other solution would be to offer a php-mapi module for EL9 that is build against remi php dnf modules - I also tried moving to a new php version with the some result as Andrew mentioned above. The module can be loaded into php if we switch to a newer version which makes sense to me.

Thank you!
Daniel

[dfied]

Little update from my side: the three code changes @AndrewMRQuinn suggested, are still valid. I now understood that this is a php 8.1 syntax for a closure which can be replaced by the old syntax. By reverting the to [a,b] the code is valid again.

But since 2.0.2b915f62 code changes to "?false" seem to cause problems with php 8.0. These can be found in class.baserecurrence.php, class.meetingrequest.php, class.recurrence.php and class.taskrecurrence.php about return values that require php 8.2 as far as I could check that:

example from class.baserecurrence.php:
abstract public function processOccurrenceItem(array &$items, false|int $start, int $end, false|int $basedate, mixed $startocc, mixed $endocc, mixed $tz, mixed $reminderonly): ?false;

If I replace "?false" with "bool|null" the php 8.0 linter says the code is okay. Maybe this could also be done for the other files but that cannot be the solution.

The underlying problem could be that devs are moving towards current php versions without regarding the EL9 dependency against php 8.0.

[segro21]

I just tried to upgrade to php8.1 or 8.2 but this would not work (on EL9)

[root@mail ~]# dnf install @php:8.2
Last metadata expiration check: 0:13:33 ago on Mo 27 Okt 2025 15:04:51 CET.
Error:
 Problem 1: problem with installed package php-sodium-8.0.30-2.el9.x86_64
  - package php-sodium-8.0.30-2.el9.x86_64 from @System requires php(api) = 20200930-64, but none of the providers can be installed
  - package php-sodium-8.0.30-2.el9.x86_64 from @System requires php(zend-abi) = 20200930-64, but none of the providers can be installed
  - package php-sodium-8.0.30-2.el9.x86_64 from epel requires php(api) = 20200930-64, but none of the providers can be installed
  - package php-sodium-8.0.30-2.el9.x86_64 from epel requires php(zend-abi) = 20200930-64, but none of the providers can be installed
  - cannot install both php-common-8.2.28-1.module_el9.6.0+165+cf879a7c.x86_64 from appstream and php-common-8.0.30-3.el9_6.x86_64 from @System
  - conflicting requests
  - package php-common-8.0.30-3.el9_6.x86_64 from appstream is filtered out by modular filtering
 Problem 2: problem with installed package php-pecl-redis5-5.3.7-1.el9.x86_64
  - package php-pecl-redis5-5.3.7-1.el9.x86_64 from @System requires php(api) = 20200930-64, but none of the providers can be installed
  - package php-pecl-redis5-5.3.7-1.el9.x86_64 from @System requires php(zend-abi) = 20200930-64, but none of the providers can be installed
  - package php-pecl-redis5-5.3.7-1.el9.x86_64 from epel requires php(api) = 20200930-64, but none of the providers can be installed
  - package php-pecl-redis5-5.3.7-1.el9.x86_64 from epel requires php(zend-abi) = 20200930-64, but none of the providers can be installed
  - cannot install both php-common-8.2.28-1.module_el9.6.0+165+cf879a7c.x86_64 from appstream and php-common-8.0.30-3.el9_6.x86_64 from @System
  - package php-cli-8.2.28-1.module_el9.6.0+165+cf879a7c.x86_64 from appstream requires php-common(x86-64) = 8.2.28-1.module_el9.6.0+165+cf879a7c, but none of the providers can be installed
  - conflicting requests
  - package php-common-8.0.30-3.el9_6.x86_64 from appstream is filtered out by modular filtering
 Problem 3: problem with installed package php-pecl-msgpack-2.1.2-4.el9.x86_64
  - package php-pecl-msgpack-2.1.2-4.el9.x86_64 from @System requires php(api) = 20200930-64, but none of the providers can be installed
  - package php-pecl-msgpack-2.1.2-4.el9.x86_64 from @System requires php(zend-abi) = 20200930-64, but none of the providers can be installed
  - package php-pecl-msgpack-2.1.2-4.el9.x86_64 from epel requires php(api) = 20200930-64, but none of the providers can be installed
  - package php-pecl-msgpack-2.1.2-4.el9.x86_64 from epel requires php(zend-abi) = 20200930-64, but none of the providers can be installed
  - cannot install both php-common-8.2.28-1.module_el9.6.0+165+cf879a7c.x86_64 from appstream and php-common-8.0.30-3.el9_6.x86_64 from @System
  - package php-fpm-8.2.28-1.module_el9.6.0+165+cf879a7c.x86_64 from appstream requires php-common(x86-64) = 8.2.28-1.module_el9.6.0+165+cf879a7c, but none of the providers can be installed
  - conflicting requests
  - package php-common-8.0.30-3.el9_6.x86_64 from appstream is filtered out by modular filtering
 Problem 4: problem with installed package php-pecl-igbinary-3.2.13-1.el9.x86_64
  - package php-pecl-igbinary-3.2.13-1.el9.x86_64 from @System requires php(api) = 20200930-64, but none of the providers can be installed
  - package php-pecl-igbinary-3.2.13-1.el9.x86_64 from @System requires php(zend-abi) = 20200930-64, but none of the providers can be installed
  - package php-pecl-igbinary-3.2.13-1.el9.x86_64 from epel requires php(api) = 20200930-64, but none of the providers can be installed
  - package php-pecl-igbinary-3.2.13-1.el9.x86_64 from epel requires php(zend-abi) = 20200930-64, but none of the providers can be installed
  - cannot install both php-common-8.2.28-1.module_el9.6.0+165+cf879a7c.x86_64 from appstream and php-common-8.0.30-3.el9_6.x86_64 from @System
  - package php-mbstring-8.2.28-1.module_el9.6.0+165+cf879a7c.x86_64 from appstream requires php-common(x86-64) = 8.2.28-1.module_el9.6.0+165+cf879a7c, but none of the providers can be installed
  - conflicting requests
  - package php-common-8.0.30-3.el9_6.x86_64 from appstream is filtered out by modular filtering
 Problem 5: problem with installed package grommunio-web-3.15.48.g1e5aa58af-345.1.noarch
  - package grommunio-web-3.15.48.g1e5aa58af-345.1.noarch from @System requires php-sodium, but none of the providers can be installed
  - package grommunio-web-3.15.48.g1e5aa58af-345.1.noarch from grommunio requires php-sodium, but none of the providers can be installed
  - package php-sodium-8.0.30-2.el9.x86_64 from @System requires php(api) = 20200930-64, but none of the providers can be installed
  - package php-sodium-8.0.30-2.el9.x86_64 from @System requires php(zend-abi) = 20200930-64, but none of the providers can be installed
  - package php-sodium-8.0.30-2.el9.x86_64 from epel requires php(api) = 20200930-64, but none of the providers can be installed
  - package php-sodium-8.0.30-2.el9.x86_64 from epel requires php(zend-abi) = 20200930-64, but none of the providers can be installed
  - cannot install both php-common-8.2.28-1.module_el9.6.0+165+cf879a7c.x86_64 from appstream and php-common-8.0.30-3.el9_6.x86_64 from @System
  - package php-xml-8.2.28-1.module_el9.6.0+165+cf879a7c.x86_64 from appstream requires php-common(x86-64) = 8.2.28-1.module_el9.6.0+165+cf879a7c, but none of the providers can be installed
  - conflicting requests
  - package php-common-8.0.30-3.el9_6.x86_64 from appstream is filtered out by modular filtering
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

[dfied]

@segro21 confirmed, @AndrewMRQuinn and me saw this on our EL9 systems as well - please see #6 (comment)

Also the remi repos don't work. They offer the needed packages but php_mapi fails to load as the Grommunio repo package is built against php8 on EL9.

We need to find a solution with Grommunio to make grommunio-web available on EL9 again.

[robert-scheck]

A major RPM packaging mistake from my point of view is that /usr/lib64/php/modules/mapi.so is part of the gromox RPM package; /usr/lib64/php/modules/mapi.so should be moved to an own RPM package, e.g. "php-gromox".

Another issue is that mapi.so (the PHP MAPI extension for gromox) can't be built easily without building gromox – at least from my understanding, I'm happy to be corrected.

However, once /usr/lib64/php/modules/mapi.so is in an own RPM package, it would be possible for grommunio to build the gromox package against each supported RHEL 9 Application Stream, e.g. PHP 8.2 and 8.3. This would lead to two different RPM packages, thus users could switch between PHP 8.2 and 8.3 from the RHEL 9 Application Streams as needed. Note that this needs, aside of unique NEVRA, proper Requires: and/or regular RHEL-typical dependency handling (e.g. Requires: php(api) = 20230831-64 and Requires: php(zend-abi) = 20230831-64), not the SUSE-isms that slip all the time into the grommunio packages for RHEL. The approach of having a separate RPM package for mapi.so would even allow (others) to build more flavors of mapi.so against e.g. 3rd-party PHP repositories, if needed.

Alternatively, if grommunio only supports one specific PHP version for RHEL 9 (could be an option as well), the gromox package should be built simply against this specific supported PHP version of the corresponding RHEL 9 Application Stream – which currently is unfortunately not the case. Because as of writing, the gromox RPM package on RHEL 9 targets obviously the RHEL 9 Full Life Application Stream, which is PHP 8.0, which the recent code change in this GitHub project does no longer support.

Finally, it is important to understand, that PHP modules/extensions, such as mapi.so can be only built against one specific PHP (minor) version. Thus one mapi.so supports either PHP 8.0 or 8.1 or 8.2 or 8.3, depending on which PHP version it was built against. Proper RHEL RPM packaging also takes this information into the package (as mentioned with an example above).

Another approach could be to avoid hunting for the latest PHP language syntax in this GitHub project, but to keep a compatibility baseline with PHP language backwards compatibility for PHP 8.0. No enterprise-suited Linux distribution will always ship the latest PHP version, and enterprises might not be interested in running bleeding edge Linux distributions.

So, please fix your RPM packaging.