WebApp und PHP 7.3
cblaha last edited by
Hello, from when does the WebApp support the PHP version 7.3?
Thanks and best Regards
Are you referring to Debian 10? In that case you can already give the master build a try.
cblaha last edited by
I wanted to run PHP 7.3 on Debian 9. I need at least PHP 7.1 for my Nextcloud installation
WebApp needs a php-mapi for that version.
So you probably have to compile kopano-core yourself.
Moving this to the KC topics.
lukistellar last edited by lukistellar
I got the same problem on my private server.
My way to fix it:
- Download both versions of kopano, the Debian 9 and also die Debian 10 version.
- Use the php7-mapi installer for Debian 10, and the other packages for Debian 9, there are the precompiled modules for php7.3, cause this is the main php version for Debian 10.
@Kopano: Why are you not including newer versions of the mapi.so module into your installers? For me it would make more sense to include modules for supported php versions, also if they are not the main version of the distribution. Also your postinstall script places the config files in the folder for the newest version of php on the system - this doesn’t make sense for me.
The postinst script from php7-mapi_188.8.131.52.95f63d2ab-0+297.1_amd64.deb:
#! /bin/sh set -e if [ -d /etc/php/7.3 ]; then BASE="/etc/php/7.3" elif [ -d /etc/php/7.2 ]; then BASE="/etc/php/7.2" elif [ -d /etc/php/7.0 ]; then BASE="/etc/php/7.0" else BASE="/etc/php5" fi DIST="/usr/share/kopano/php/mapi/mapi.ini" if [ -x /usr/sbin/phpenmod -o -x /usr/sbin/php5enmod ]; then # modern approach, used by distros with PHP >= 5.4 echo "php-mapi: using mods-available directory" mkdir -p "$BASE/mods-available" # just in case cp "$DIST" "$BASE/mods-available/kopano.ini" if [ -x /usr/sbin/phpenmod ]; then phpenmod kopano else php5enmod kopano fi else # for older distros, such as Ubuntu 12.04 echo "php-mapi: not using mods-available directory" mkdir -p "$BASE/apache2/conf.d" # just in case cp "$DIST" "$BASE/apache2/conf.d/kopano.ini" mkdir -p "$BASE/conf.d" # just in case cp "$DIST" "$BASE/conf.d/kopano.ini" fi service apache2 try-restart || : /bin/echo -e "\n\nIf you use a PHP executor other than Apache (like FPM), you may need to manually restart it.\n\n"
The “data” content from php7-mapi_184.108.40.206.95f63d2ab-0+297.1_amd64.deb:
. ./usr ./usr/lib ./usr/lib/php ./usr/lib/php/20151012 ./usr/lib/php/20151012/mapi.so ./usr/share ./usr/share/kopano ./usr/share/kopano/php ./usr/share/kopano/php/mapi ./usr/share/kopano/php/mapi/mapi.ini ./usr/share/doc ./usr/share/doc/php7-mapi ./usr/share/doc/php7-mapi/copyright ./usr/share/doc/php7-mapi/changelog.Debian.gz
In this case, the config file will be located in the folder for php7.3, but only the module for php7.0 will get installed.
Why are you not including newer versions of the mapi.so module into your installers? For me it would make more sense to include modules for supported php versions, also if they are not the main version of the distribution.
We are using a local installation of https://build.opensuse.org/ to build and package Kopano for the individual distributions. This essentially means that when we are building packages for e.g. Debian 9 only packages that this distributions provides from its own repository can be pulled in as build dependencies (additionally its also not [easily] doable to pull in additional packages during build as build roots do not have access to the internet). These circumstances contribute to the fact that we cannot simply provide additional mapi.so for any given distribution, but have restricted ourselves to the php version that the distribution provides by default.
Also your postinstall script places the config files in the folder for the newest version of php on the system - this doesn’t make sense for me.
Yes, the postinst is not really beautiful, but allows us to use the same postinst for all our debian packaging.
All in all:
- If you want to use a newer php version than the one that your distribution provides -> pick another distribution that provides this version by default
- Are you running an additional application on the same host as your Kopano, that requires a very specific version of php -> make use of virtualization and/or containerization to properly separate these two systems.