3 / 22
Dec 2022

Ich habe heute 3.12.22 unter Debian 11 eine Neuinstallation auf einer Minimal-Installation durchgeführt.
Das ganze bei IONOS.
Installiert wurde egroupware-docker apache2 egroupware-mail.

Leider bekomme ich immer einen “502 Bad Gateway”.

Zur Sicherheit dann noch Let´s Encrypt und eine SSL-konfiguration des Apache2 eingestellt, gleiches Problem.

Ein “docker logs egroupware -f” bringt eine “Dauerschleife” mit folgender Fehlermeldung:

Installation failed --> exiting!

Installing of EGroupware failed!
PHP Warning: Undefined global variable $egw_domain in /usr/share/egroupware/setup/inc/functions.inc.php on line 33
EGroupware\Api\Cache::get_provider(Instance) no provider found (error instanciating provider EGroupware\Api\Cache\Files: EGroupware\Api\Cache\Files::__construct() can’t create basepath !)!EGroupware\Api\Cache::get_provider:700 / EGroupware\Api\Cache::get_provider:664 / EGroupware\Api\Cache::getCache:298 / EGroupware\Api\Cache::getTree:425 / EGroupware\Api\Translation::init:179 / EGroupware\Api\Translation::translate:223 / try_lang:35(An error happened) / _egw_log_exception:66 / EGroupware\Api\Db->_connect:556 / EGroupware\Api\Db->connect:354 / EGroupware\Api\Db->quote:1543 / EGroupware\Api\Db->create_database:1163 / setup_cmd_database->create:193 / setup_cmd_database->exec:117 / admin_cmd->run:239
EGroupware\Api\Cache::get_provider(Tree) no provider found ()!EGroupware\Api\Cache::get_provider:700 / EGroupware\Api\Cache::getCache:298 / EGroupware\Api\Cache::getTree:425 / EGroupware\Api\Translation::init:179 / EGroupware\Api\Translation::translate:223 / try_lang:35(An error happened) / _egw_log_exception:66 / EGroupware\Api\Db->_connect:556 / EGroupware\Api\Db->connect:354 / EGroupware\Api\Db->quote:1543 / EGroupware\Api\Db->create_database:1163 / setup_cmd_database->create:193 / setup_cmd_database->exec:117 / admin_cmd->run:239
/usr/bin/php8.1 -d memory_limit=-1 /usr/share/egroupware/setup/setup-cli.php --setup-cmd-database sub_command=create_db ‘domain=default’ ‘db_type=mysqli’ ‘db_host=db’ ‘db_port=3306’ ‘db_name=egroupware’ ‘db_user=egroupware’ ‘db_pass=|Px@[0Utsjk3?[WY’ ‘db_root=root’ ‘db_root_pw=e18f0edb17f4465ff01cacf735705565’ 'db_grant_host=%'
Can not connect to mysqli database mysql on host db:3306 using user root! (ADOdb::Connect(db:3306, root, $Password, mysql) failed.)
/usr/share/egroupware/setup/inc/class.setup_cmd_database.inc.php (158)

Installation failed --> exiting!

Retrying EGroupware installation in 3 seconds …

Ich habe auch schon die Pakete deinstalliert, überprüft ob bei docker alles gelöscht wurde und nochmal neu drüber installiert - gleiches Problem.

Dann habe ich lokal eine Debian 11 und eine Ubuntu 22.04 VM aufgesetzt.
Bei Ubuntu 22.04 ist während des Installationsvorganges folgende Fehlermeldung aufgetaucht:

No EGroupware MariaDB container, nor able to change MariaDB or MySQL to bind on docker0 addresss (172.17.0.1)!
/var/lib/dpkg/info/egroupware-mail.postinst: 57: mysql: not found
Can NOT connect to EGroupware database as user ‘root’, you need to create and add DB credentials to dovecot/my.cnf postfix/sql-{aliases,mailboxes,domains}.cf

Der Container egroupware-db läuft, Logs bringen folgende Fehlermeldung:

2022-12-03 7:42:07 259 [Warning] Access denied for user ‘egroupware’@‘172.18.0.3’ (using password: YES)

Selbstverständlich ist das unter Debian identisch.

Auf dem IONOS Server unter Debian 11 ist zusätzlich zum Datenbank user egroupware auch noch root im Logfile

2022-12-03 7:37:00 4570 [Warning] Access denied for user ‘root’@‘172.18.0.3’ (using password: YES)

Das Passwort aus der .env Datei scheint falsch zu sein. Ein
docker exec egroupware-db mysql -u root -pxxxxx
wirft einen Fehler.
Auf den beiden lokalen VMs funktioniert das Kommando mit dem entsprechenden Passwort aus der .env

  • created

    Dec '22
  • last reply

    Dec '22
  • 21

    replies

  • 2.6k

    views

  • 6

    users

  • 1

    like

  • 4

    links

Hi Marco.

Ich kann das mit einer Standard-Installation reproduzieren.

Erster Blick ist immer auf die
/var/lib/egroupware/header.inc.php
Und siehe da: Die ist nicht vollständig geschrieben:

Schon komisch. Das Update heute Nacht hat doch eigentlich nicht damit zu tun. Denke ich…
Wir schauen danach.

Stefan

Sieht fast so aus, als gebe es bei der Neuinstallation mit dem seit heute Nacht auf PHP 8.1 basierenden Container ein Problem :frowning:

Trag doch mal temporär unter /etc/egroupware-docker/docker-compose.override.yml beim Image das Tag 21.1-7.4 ein:

  egroupware:
    image: egroupware/egroupware:21.1-7.4

Und mache einen Neustart mit:

cd /etc/egroupware-docker
docker-compose up -d

Dann sollte die EGroupware Installation durch laufen.

Das egroupware-mail Pakete direkt mit zu installieren habe ich noch nie getestet, vermute mal das das nicht funktioniert.

Ralf

Hallo zusammen,
habe wahrscheinlich das gleiche Problem nach dem Update bei mehreren Servern:
Nach dem Anmelden kommt erstmal ein leerer Bildschirm und irgendwann nach Seiten-Refresh die Felhermeldung:

/usr/share/egroupware/phpgwapi/inc/class.egw_datetime.inc.php (30)
An error happened

Undefined constant "EGW_APP_INC"
vielleicht hilft das ja weiter
viele Grüße
Andreas

Hallo,
die selbe Fehlermeldung seit heute habe ich auch, im Detail:

/usr/share/egroupware/phpgwapi/inc/class.egw_datetime.inc.php (30)
An error happened

Undefined constant “EGW_APP_INC”

#0 /usr/share/egroupware/api/src/autoload.php(103): include_once()
#1 [internal function]: {closure}()
#2 /usr/share/egroupware/api/src/loader.php(75): unserialize()
#3 /var/lib/egroupware/header.inc.php(81): require_once(’…’)
#4 /usr/share/egroupware/index.php(87): include(’…’)
#5 {main}

Viele Grüße
Peter Schütt

Hallo Andreas.

Wo siehst du das “gleiche Problem”? Das stellt sich doch vollkommen anders dar.

Hast du alte deprecated App installiert?
Dann dürfte dein Problem ein anderes sein und ich bitte dich ein eigenes Thema auf zu machen. Sonst läuft das hier alles durcheinander.

Bitte auch die Release-Notes beachten:

Stefan

Hallo Peter.

Sofern du keine Neuinstallation gemacht hast dürfte das ein anderes Problem sein. Bitte mache dazu dein eigenes Thema auf.

Bitte auch die Release-Notes beachten:

Stefan

Hallo Marco.

Das müssen wir und noch genauer anschauen. Für den Moment kann ich für Neuinstallationen nur sagen: Sorry, funktioniert gerade nicht.

Stefan

Hallo, entschuldigung, ich kann ein bisschen Deutch sprechen, aber wenig…
Dazu wurde ich im English reporten:

My (pretty old) Egroupware installation reported me the same this morning:

/usr/share/egroupware/phpgwapi/inc/class.egw_datetime.inc.php (30)
An error happened

Undefined constant "EGW_APP_INC"

i ran debian updates and rebooted, still the same.

I will try to do what Ralf said above Neu-Installation nach Maintainance Release vom 02.12.22 mit Fehler so my office can work again… but in long term, should I try to install php8.1 on my debian 10.13? as e.g. LibreNMS recommends from a separate repository, like https://docs.librenms.org/Installation/Install-LibreNMS/#install-required-packages1 this ?

(for whoever looks for this and understands english only:

go to /etc/egroupware-docker/docker-compose.override.yml file
edit the image: egroupware/egroupware:21.1 setting under the egroupware section to look like
image: egroupware/egroupware:21.1-7.4

then run commands

cd /etc/egroupware-docker
docker-compose up -d

This should fix your installation.

( do I understand this right that this change is temporary, so it’ll revert next time update happens? or should the proper course of action be to install php8.1 e.g. from the sury repo, or migrate to … another OS where it is standard…?)

Hi Lukasz.

Yes.

Please read the release notes:

and fix your old apps as described. Then you can switch “back” to standard PHP 8.1 container.


And please:
Open your own topic for your own problem.
Your Problem has nothing to do with the problem of this topic.

Stefan

Hallo Marco.

Um eine verunglückte Neuinstallation ohne Daten in dieser Situation zu reparieren kann man diesen Workaround anwenden:

cd /etc/egroupware-docker
docker-compose stop egroupware
./mysql.sh
drop database egroupware;
drop user egroupware@'%';
quit
> /var/lib/egroupware/header.inc.php 
sed 's|egroupware:21.1|egroupware:21.1-7.4|g' -i docker-compose.override.yml
docker-compose up -d

Das stellt zurück auf die PHP 7-Version, damit die Installation zu Ende durch läuft.

Wenn das funktioniert hat kann wieder zurück auf PHP 8.1 gestellt werden:

Das grundsätzliche Problem müssen wir noch lösen. Sorry für die Umstände.

Stefan

Hallo Stefan,
ich habe das mal in einer VM mit einem lokal konfigurierten Postfix + Dovecot probiert, so wie Du es beschrieben hast, funktioniert es.

  1. Installieren nach Anleitung (führt zu Fehler wie beschrieben)
  2. Workaround wie vonDir beschrieben (dann ist ein Login möglich)
  3. in der docker-compose.override.yml egroupware:latest eingestellt
  4. docker-compose up -d und ich hab dann noch ein docker restart egroupware gemacht
  5. ein docker exec egroupware dpkg -l | grep php bringt dann die Info, dass php-8.1 genutzt wird
    ii php8.1-apcu 5.1.21+4.0.11-8+ubuntu20.04.1+deb.sury.org+1 amd64 APC User Cache for PHP

Besser: 21.1
So liefern wir das auch aus. Ansonsten wirst du ggf. irgendwann Container bekommen die noch nicht für den produktiven Einsatz gedacht sind oder du bekommst das nächste Major-Release vorab.
Das Major-Release liefern wir im Prinzip als Paket aus, welches in der yml den Eintrag hoch setzt (23.1 oder so.)
Mit latest kann man sich auch schon mal Ärger einhandeln. Ich denke da insbesondere an Rocket.Chat wenn die DB ein Update bekommt. Dann ist oft ein Zurück nicht möglich.

Der restart sollte nicht nötig sein, meine ich. Durch docker-compose up -d werden die Container gebaut und gestartet.

Du kannst auch einfach phpinfo aufrufen:

Stefan

Es gibt ein neues Image mit Tag 21.1.20221202-3 (auch unter 21.1, 21.1-8.1 und latest), das die Installation unter PHP 8.1 wieder ermöglicht.

Sprich Neuinstallationen des egroupware-docker Pakets funktionieren jetzt auch direkt mit dem Standard Image mit PHP 8.1.

Ralf

Zu früh gefreut, der Fix hat leider ein paar unerwünschte Nebenwirkungen. Deswegen habe ich den betroffenen Teil zurück nehmen müssen und das neue 21.1.20221202-3 Image erst mal wieder zurück gezogen.

Ich bin dran …

Ralf