PHP 7 wird nach der Installation von EGroupware-docker per deb-Datei unter Debian 9 als nicht mehr benötigt markiert - nach apt autoremove funktionionsunfähiger apache2 (startet dann nicht mehr)

Sophia_2004 2020-01-23 11:35:35 UTC #1

Nachdem die Installation der aktuellsten Version von EGroupware-Docker per deb-Datei erfolgreich verlief, fiel mir einige Tage später im Rahmen eines regulären “apt-get -u upgrade” auf, dass unter anderem PHP 7.0 als nicht mehr benötigt und als per autoremove zu entfernen empfohlen wurde.

Hier ist die komplette Liste benötigten Pakete, die im Zuge der Entfernung der alten EGroupware-Version von Debian 9-apt bzw. apt-get als nicht mehr benötigt eingestuft wurden:

libgd3 libfontconfig1 fontconfig-config php7.0-tidy libtidy5 lib
webp6 libxpm4 php-zip libzip4 mariadb-client php-bcmath php-bz2 php7.0-bcmath php7.0-xml php-ldap php-mbstring php-mysql

Der Befehl dpkg -C zeigte keine Probleme innerhalb der Paketverwaltung an.

Um diese Meldung zu entfernen und apt-get zu “fixen” musste zunächst ein “apt autoremove” durchgeführt werden.

Da nun PHP 7.0 deinstalliert war startete der Apache Webserver nicht mehr, was zu einer Funktionsunfähigkeit der EGroupware führte!

Nach der Analyse der dpkg-Logdateien von 9.1.2020 konnten die per autoremove entfernten Pakete im Nachhinein identifiziert werden.

Ein

“apt-get install libgd3 libfontconfig1 fontconfig-config php7.0-tidy libtidy5 lib
webp6 libxpm4 php-zip libzip4 mariadb-client php-bcmath php-bz2 php7.0-bcmath php7.0-xml php-ldap php-mbstring php-mysql”

bewirkte wieder einen funktionsfähigen Apache-Webserver mit allen sonst gewünschten sinnvollen deb-Archiven.

Ob es sich nun um einen Bug des deb-Installationspaketes für Debian 9 oder um einen generellen Debian-Bug handelt mag dahingestellt sein.

Fest steht, dass mit einem einfachen apt autoremove eine vorher funktionsfähige EGroupware-Docker-Installation - mitsamt alles webbasierdender Dienste auf dem Server - ausfällt. Der zeitliche Aufwand für die Problembehebung ist nicht unerheblich.

RalfBecker 2020-01-24 08:27:53 UTC #2

Da EGroupware das PHP auf dem Host überhaupt nicht mehr verwendet, gehe ich mal davon aus, das es nichts mit EGroupware zu tun hat.

Wenn Du das error.log des Webservers nach dem Entfernen von PHP nochmal anschaust, wird da vermutlich drin stehen das Apache versucht hat das PHP Module (mod_php*) zu laden. Irgendwie hat die Deinstallation das vermutlich nicht automatisch entfernt.

Ralf

Sophia_2004 2020-01-28 10:26:22 UTC #3

Dass Egroupware Docker das System-PHP, d.h. unter Debian 9 PHP 7.0, nicht benutzt war mir bekannt.

Ein Durchsehen des error.log des Apache2 brauchte das folgende Ergebnis:

[Tue Jan 14 11:48:50.395125 2020] […] PHP Warning: PHP Startup: Unable to load dynamic library ‘/usr/lib/php/20151012/mysqlnd.so’ - /usr/lib/php/2015101/mysqlnd.so: cannot open shared object file: No such file or directory in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library ‘/usr/lib/php/20151012/xml.so’ - /usr/lib/php/20151012/xml.so: cannot open shared object file: No such file or directory in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library ‘/usr/lib/php/20151012
/bcmath.so’ - /usr/lib/php/20151012/bcmath.so: cannot open shared object file: No such file or directory in Unknown on line
[…]

Die dpkg-Logdateien während der Installation von EGroupware-Docker habe ich hier, sollten der Länge (ca. 43 KB / 606 Zeilen) wegen aber nicht im Klartext gepostet werden. Auf Wunsch kann ich es gerne per E-Mail schicken; das Hinzufügen von Anhängen ist in privaten Forumnachrichten nicht vorgesehen.

Faktisch bewirkte apt autoremove folgendes:

2020-01-14 11:46:29 remove php-gd:all 1:7.0+49
2020-01-14 11:46:30 remove php7.0-gd:amd64 7.0.33-0+deb9u6
2020-01-14 11:46:33 remove libapache2-mod-php:all 1:7.0+49
2020-01-14 11:46:34 remove php-apcu-bc:amd64 1.0.3-2
2020-01-14 11:46:34 remove php-apcu:amd64 5.1.8+4.0.11-1
2020-01-14 11:46:35 remove libapache2-mod-php7.0:amd64 7.0.33-0+deb9u6
2020-01-14 11:46:38 remove php-tidy:all 1:7.0+49
2020-01-14 11:46:38 remove php7.0-tidy:amd64 7.0.33-0+deb9u6
2020-01-14 11:46:40 remove php-zip:all 1:7.0+49
2020-01-14 11:46:41 remove php7.0-zip:amd64 7.0.33-0+deb9u6
2020-01-14 11:46:42 remove php-bcmath:all 1:7.0+49
2020-01-14 11:46:43 remove php-bz2:all 1:7.0+49
2020-01-14 11:46:43 remove php7.0-bcmath:amd64 7.0.33-0+deb9u6
2020-01-14 11:46:44 remove php7.0-xml:amd64 7.0.33-0+deb9u6
2020-01-14 11:46:45 remove php-ldap:all 1:7.0+49
2020-01-14 11:46:45 remove php-mbstring:all 1:7.0+49
2020-01-14 11:46:46 remove php-mysql:all 1:7.0+49
2020-01-14 11:46:46 remove php7.0-bz2:amd64 7.0.33-0+deb9u6
2020-01-14 11:46:47 remove php7.0-cli:amd64 7.0.33-0+deb9u6
2020-01-14 11:46:47 remove php7.0-readline:amd64 7.0.33-0+deb9u6
2020-01-14 11:46:48 remove php7.0-json:amd64 7.0.33-0+deb9u6
2020-01-14 11:46:48 remove php7.0-ldap:amd64 7.0.33-0+deb9u6
2020-01-14 11:46:49 remove php7.0-mbstring:amd64 7.0.33-0+deb9u6
2020-01-14 11:46:46 remove php-mysql:all 1:7.0+49
2020-01-14 11:46:46 remove php7.0-bz2:amd64 7.0.33-0+deb9u6
2020-01-14 11:46:47 remove php7.0-cli:amd64 7.0.33-0+deb9u6
2020-01-14 11:46:47 remove php7.0-readline:amd64 7.0.33-0+deb9u6
2020-01-14 11:46:48 remove php7.0-json:amd64 7.0.33-0+deb9u6
2020-01-14 11:46:48 remove php7.0-ldap:amd64 7.0.33-0+deb9u6
2020-01-14 11:46:49 remove php7.0-mbstring:amd64 7.0.33-0+deb9u6
2020-01-14 11:46:49 remove php7.0-mysql:amd64 7.0.33-0+deb9u6
2020-01-14 11:46:50 remove php7.0-opcache:amd64 7.0.33-0+deb9u6
2020-01-14 11:46:50 remove php7.0-common:amd64 7.0.33-0+deb9u6
2020-01-14 11:46:51 remove php-common:all 1:49

Auf dem EGroupware-Testsystem, das auf Ubuntu 18.04 läuft und PHP 7.2 verwendet, wurde hingegen PHP nicht als nicht mehr benötigtes Paket im Rahmen von autoremove markiert.

Einzig allein libllvm8 befand sich dort als autoremove-Eintrag. Dessen Entfernung verursachte keine Probleme.

Eine Durchsicht der ~/.bash_history unter Debian 9 zeigt, dass keine manuelle Deinstallation von PHP, auch nicht im Nachhinein, erfolgte:

apt-key add gpg [vorher heruntergelandener public key für Docker; der für Egroupware war bereits importiert]
apt-key fingerprint 0EBFCD88
apt-get install add-apt-repository
apt-get install software-properties-common
add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/debian $(lsb_release -cs) stable"
apt-get update
apt-get install egroupware-docker

RalfBecker 2020-01-28 10:52:13 UTC #4

Schau doch einfach mal, ob mod_php noch im Apache konfiguriert ist:

grep -ri mod_php /etc/apache2

Dann kannst Du es per a2dismod entfernen, BEVOR Du per autoremove das php deinstallierst:
https://manpages.ubuntu.com/manpages/bionic/en/man8/a2enmod.8.html

Das egroupware-docker Paket selbst braucht - wie gesagt - kein PHP. Allerdings kann es sein, das Du noch eines der abgekündigten egroupware-epl-* Pakete (Wiki, Wissensdatenbank, SiteMgr) installiert hast, die von egroupware-docker nicht ersetzt werden. Wenn Du die noch brauchst, können sie auf dem Host verbleiben und werden von der EGroupware eingebunden, oder Du kannst sie löschen.

Ralf

RalfBecker 2020-01-28 10:58:12 UTC #5

sorry, Kommando muss wie folgt lauten:

grep -ri php /etc/apache2

Ausgabe sieht dann z.B. auf einem Ubuntu 16.04 mit eingeschaltetem mod_php wie folgt aus:

/etc/apache2/mods-available/php7.0.conf:    SetHandler application/x-httpd-php
/etc/apache2/mods-available/php7.0.conf:<FilesMatch ".+\.phps$">
/etc/apache2/mods-available/php7.0.conf:    SetHandler application/x-httpd-php-source
/etc/apache2/mods-available/php7.0.conf:    # Deny access to raw php sources by default
/etc/apache2/mods-available/php7.0.conf:# Deny access to files without filename (e.g. '.php')
/etc/apache2/mods-available/php7.0.conf:# Running PHP scripts in user directories is disabled by default
/etc/apache2/mods-available/php7.0.conf:# To re-enable PHP in user directories comment the following lines
/etc/apache2/mods-available/php7.0.conf:        php_admin_flag engine Off
/etc/apache2/mods-available/php7.0.load:# Conflicts: php5
/etc/apache2/mods-available/php7.0.load:LoadModule php7_module /usr/lib/apache2/modules/libphp7.0.so
/etc/apache2/mods-available/dir.conf:	DirectoryIndex index.html index.cgi index.pl index.php index.xhtml index.htm
/etc/apache2/sites-available/default-ssl.conf:		<FilesMatch "\.(cgi|shtml|phtml|php)$">
/etc/apache2/sites-available/000-default.conf:	#	AuthName "PHP Info"

Ralf

Sophia_2004 2020-01-28 11:16:02 UTC #6

Die momentan installieren Egroupware-Pakete sind:

user@host:$ dpkg --get-selections | grep "egroupware"
egroupware-collabora-key install
egroupware-docker install
egroupware-epl deinstall
egroupware-epl-core deinstall
egroupware-epl-groups install
egroupware-rocketchat install

… falls diese Information etwas weiterhelfen sollte.

Weil auf dem Server noch andere PHP-Skripte für die sonstigen Webseiten laufen, wird die Debian-System-PHP, weiterhin benötigt.

Der Befehl “grep -ri php /etc/apache2” zeigt nach der manuellen Neusinstallation an:

/etc/apache2/mods-available/php7.0.load:# Conflicts: php5
/etc/apache2/mods-available/php7.0.load:LoadModule php7_module /usr/lib/apache2/modules/libphp7.0.so
/etc/apache2/mods-available/dir.conf: DirectoryIndex index.html index.cgi index.pl index.php index.xhtml index.htm
/etc/apache2/mods-available/php7.0.conf: SetHandler application/x-httpd-php
/etc/apache2/mods-available/php7.0.conf:<FilesMatch “.+.phps$”>
/etc/apache2/mods-available/php7.0.conf: SetHandler application/x-httpd-php-source
/etc/apache2/mods-available/php7.0.conf: # Deny access to raw php sources by default
/etc/apache2/mods-available/php7.0.conf:# Deny access to files without filename (e.g. ‘.php’)
/etc/apache2/mods-available/php7.0.conf:# Running PHP scripts in user directories is disabled by default
/etc/apache2/mods-available/php7.0.conf:# To re-enable PHP in user directories comment the following lines
/etc/apache2/mods-available/php7.0.conf: php_admin_flag engine Off

RalfBecker 2020-01-28 12:17:43 UTC #7

Jetzt bin ich verwirrt, warum hast Du PHP dann überhaupt deinistalliert?

Ralf

Sophia_2004 2020-01-28 12:45:33 UTC #8

Sorry für die Verwirrung: Die Deinstallation erfolgte per autoremove, falls beispielsweise ein anderer Admin Jahre später wegen anderer Debian-Pakete in der autoremove-Liste (aus welchen Gründen auch immer PHP 7 dort drin stand) dieses ausführen sollte und dabei versehentlich PHP 7.0 nicht gleich mit deinstalliert.