Probleme mit eGroupware (Re-)Installation

Hallo zusammen,

ich habe mir gestern mein eGroupware Umgebung zerschossen, und bekomme es beim besten Willen nicht mehr zum Laufen…

Nach der Rücksicherung eines DB-Backups bekam ich bei der Anmeldung plötzlich einen Datenbankfehler. Mehre Versuche mit anderen Backups brachten keine Besserung. Neustart Docker Container, UCS, usw. aber keine Veränderung.

Ich habe dann ein Upgrade (vorher 19) von eGroupware durchgeführt, hat auch nichts gebracht.

In letzter Konsequenz habe ich eGroupware dann deinstalliert und nochmal neu installiert. Nun geht gar nichts mehr, wenn ich eGroupware öffnen möchte, kommt nur die Meldung “502 Bad Gateway” von nginx.

Es scheint, als wenn bei deinstallieren nicht sauber alles was zu eGroupware gehört entfernt wird, und nach der Neuinstallation beide Seiten (UCS und eGroupware) denken, “ich bin ja schon installiert”, es laufen einige Sachen nicht.

Auch das manuelle Entfernen von User und DB der MariaDB, das Löschen von Benutzer, Server, UCR Einträgen, secret-Dateien in /etc usw. hat nichts gebracht.

In /var/lib/egroupware/egroupware-docker-install.log erscheint alle 3 Sekunden:

/usr/bin/php7.3 -d memory_limit=-1 /usr/share/egroupware/setup/setup-cli.php --update 'all,admin,>9xa<(xJXfV46rUZ'
EGroupware API Version 20.1.003 gefunden.
EGroupware Konfigurationsdatei (header.inc.php) Version 1.29 existiert und ist aktuell
Ihre Datenbank arbeitet, aber Sie haben keine Anwendungen installiert! (mysqli://egroupware:57fde3fedda75e62830ac018e3e731ad2f18e2f4a9e94498553ffea074fa2218@172.17.42.1/egroupware). Benutzen Sie --install um EGroupware zu installieren.

Installation failed --> exiting!

Retrying EGroupware installation in 3 seconds ...

In der docker-compose von eGroupware habe ich den Hinweis gefunden, dass die Installation nicht gemacht wird, da diese vom Join-Skript angestoßen wird. Das scheint aber nur beim ersten Mal zu laufen, danach nie wieder. Führe ich den entsprechenden Abschnitt des Skripts von Hand aus, bekomme ich ein ähnliches Ergebnis:

/usr/bin/php7.3 -d memory_limit=-1 /usr/share/egroupware/setup/setup-cli.php --update 'all,admin,rOWAN(V6-0R9=(KQ'
EGroupware API Version 20.1.003 gefunden.
EGroupware Konfigurationsdatei (header.inc.php) Version 1.29 existiert und ist aktuell
Ihre Datenbank arbeitet, aber Sie haben keine Anwendungen installiert! (mysqli://egroupware:57fde3fedda75e62830ac018e3e731ad2f18e2f4a9e94498553ffea074fa2218@172.17.42.1/egroupware). Benutzen Sie --install um EGroupware zu installieren.

Die Datenbank ist angelegt, aber komplett leer, keine Tabellen, keine Inhalte. Wenn ich per “univention-app shell” in den Container wechsle, werde ich nach kurzer Zeit rausgeworfen.

Im Container laufen zwei Prozesse mit “entrypoint.sh” Wenn ich die kille, dann werde ich nicht mehr rausgeworfen. Versuche ich dann, im Container den Befehl

/usr/bin/php7.3 -d memory_limit=-1 /usr/share/egroupware/setup/setup-cli.php --install 'all,admin,lAfdhDjj6(pJrpYr'

manuell abzusetzen, so wie in der Fehlermeldung genannt, führt das zu

Permission denied!: Zugriff verweigert: Falsche Benutzername oder Passwort für Konfiguration der Domain 'all()' !!!

Es scheint, als wäre ich auf dem richtigen Weg, aber ich komme jetzt einfach nicht mehr weiter…

Kann es sein, dass das Join-Skript mit einer “Reinstallation” nicht richtig umgehen kann? Oder hat es ​mit dem Upgrade zu tun?

Ich wäre mehr als dankbar, wenn mir jemand helfen könnte, wieder an eine lauffähige eGroupware-Installation zu kommen, ohne den UCS komplett neu aufsetzen zu müssen :grinning:

Viele Grüße
Thorger

Hallo Thorger.

Ich bin ein wenig verwirrt…

Das war/ist doch keine Installation aus den UCS-App-Center, oder?

Stefan
EGroupware Community Manager

Danke für die schnelle Rückmeldung. Doch, den Server habe ich vor ein paar Wochen erst aufgesetzt, und dabei eGroupware aus dem App-Center installiert.

Kann es sein, dass ich das Chaos mit meinem DB-Backup selbst verursacht habe, indem ich z.B. einen User mit einem falschen Passwort o.ä. wiederhergestellt habe, so das EGW dann nicht mehr zugreifen konnte?

Die Protokolle müssten alle noch da sein, falls wir Infos benötigen. Container wurden natürlich jedes Mal gelöscht…

Mir wäre es eigentlich auch soweit egal, solange ich irgendwie eine saubere Neuinstallation hinbekomme, möglichst über die UCS-Mechanismen, für spätere Updates/Upgrades etc. :woozy_face:

Hmmm. Kann ich nichts zu sagen. Denke aber nein.

Was für ein DB-Backup? Ein in EGroupware erstelltes?

Aber doch nicht auf dem von dir kürzlich aufgesetzten UCS, oder? (Wie kommt man da an 19.1?).

Oder hast du versucht eine Migration einer 19.1 Nicht-UCS-EGroupware => UCS-EGroupware?
Das ist mir irgendwie noch nicht klar…


Einen professionellen Lösungsansatz gibt es natürlich immer:

Und wenn du EGroupware auf einem UCS betreibst, gehe ich mal davon aus dass du EPL-Kunde bist. Dann geht das flott und günstig.

Spart schon mal die Kopfschmerztabletten.

Stefan

Hallo Thorger.

Hast du dein Problem lösen können?

Stefan

Hallo Stefan,

danke für die Nachfrage, ich habe in der letzten Woche noch ein bisschen rumprobiert, und irgendwann ging es dann tatsächlich wieder. Ich war bloß noch nicht dazu gekommen, hier eine Rückmeldung zu meinen Erkenntnissen zu geben. Wobei ich auch nicht ganz genau benennen kann, woran es nun gelegen hat…

Du hast natürlich recht, es war von Anfang an 20.1 installiert. Ich war nur irritiert, dass nach zwei Wochen schon ein “Upgrade” gemacht wurde, und irgendwo hatte ich in einem Protokoll etwas von 19.1 gelesen. Das Upgrade war aber nur von .001 auf .003 und hatte mit dem Problem wohl nichts zu tun (denke ich zumindest).

Beschädigt habe ich die Datenbank wohl, indem ich ein unvollständiges (?) Backup, das aus eGroupware heraus erzeugt wurde, wieder eingespielt habe. Vielleicht habe ich auch ein falsches erwischt, oder es ist beim Einspielen etwas schiefgelaufen, kann ich nicht mehr genau nachvollziehen.

Das Problem, dass ich anschließend mit der Neuinstallation hatte, führe ich auf zwei Punkte zurück:

  1. Beim Deinstallieren über das App Center des UCS wird zwar der Container von eGroupware entfernt, aber vieles bleibt noch erhalten. Z.B. die Datenbank, User im LDAP etc. (siehe oben).
  2. Bei einer erneuten Installation wird scheinbar die Konfiguration der Anwendung nicht durchgeführt (ist im Join-Skript ausgeklammert), weil sie entweder noch irgendwo als bereits installiert vermerkt ist, oder weil Fragmente noch vorhanden sind (wobei das Verhalten auch auftrat, nachdem ich Datenbank, User, Konfigdateien etc. manuell gelöscht hatte).

Ich habe die Anwendung mehrfach Neuinstalliert und wieder Deinstalliert (über das App Center), am Ende hat “gefühlt” folgendes die Lösung gebracht:

Entweder: Ich bin während der Installation ganz schnell ins Join-Skript gegangen (wird erst dann runtergeladen) und habe das “if” bei der Initialisierung der Anwendung rausgenommen.

Und / oder: Ich habe im Container die entrypoint.sh abgewürgt und mit --install manuell die Installation laufen lassen. Anschließend konnte ich das Setup aufrufen und ein funktionierendes Backup der Datenbank importieren.

Was aber nicht ging, war die Anmeldung bei eGroupware. Beim Aufruf der Login-Seite kam sinngemäß die Meldung “Permission denied, no LDAP connection”.

Das hat wohl damit zu tun, dass bei der Neuinstallation Passwörter generiert und im Container gespeichert, aber nicht auf der Seite des UCS im LDAP gesetzt werden. Ich konnte zum Glück das LDAP-Passwort im Klartext in einer Cache-Datei innerhalb des EGW-Containers finden. Das habe ich im LDAP des UCS für den EGW-User gesetzt, und danach ging auch die Anmeldung wieder.

Seitdem läuft alles wieder, als wäre nichts gewesen. Die Rechte scheinen zu stimmen, und auch die Daten sind alle wieder da, so wie ich das im ersten Anlauf vorhatte.

Für mich ist das Thema damit (vorerst) abgehakt, aber vielleicht macht es Sinn, das Szenario unter UCS einmal nachzustellen, und zu schauen, ob sich EGW sauber deinstallieren lässt (alle Bestandteile) und danach problemlos wieder installiert werden kann (als wäre es noch nie installiert gewesen)? Die Mühe habe ich mir jetzt noch nicht gemacht.

Wenn es reibungslos funktioniert, dann hat es wohl nur bei mir nicht geklappt, warum auch immer. Und falls nicht, sollte die Deinstallationsroutine des App Centers evtl. angepasst werden, denn aus meiner Sicht ist es durchaus eine übliche Vorgehensweise, die Anwendung sauber entfernen zu wollen (inkl. DB etc.) und vielleicht auch noch einmal sauber neu zu installieren.

Viele Grüßed aus Hamburg
Thorger

Hallo Thorger.

Das ist ja erst einmal gut, dass es bei dir läuft.

Wir liefern ~10 Updates pro Jahr aus. Also über den Daumen alle 4 Wochen. Neben Bugfixes kommen auch zwischen den Major-Releases weitere Funktionen und Einstellungen hinzu:

Ausführlicher dokumentiert:

Somit bekommt auch der UCS regelmäßig EGroupware-Updates. Zeitlich ein paar Tage verzögert.


Versionsschema ist Version.Datum. Also z.B.

20.1.20210324

Was du meinst ist vermutlich die interne Versionierung. Bei Problemen wäre die Version des Releases wichtig/richtig.


Am Rande:
eGroupware => EGroupware


War das Backup denn von diesem System oder wolltest du von einem anderen System einspielen?
Eine Migration von einem anderen System könnte schon Probleme bereiten, insbesondere wegen der Benutzerverwaltung auf dem UCS.
Ansonsten ist das EGw-eigene Backup nicht weiter als ein SQL-Dump mit ein paar Extras. Auf Standalone-EGws mit SQL-Benutzern absolut schmerzfrei.


Zur Deinstallation:
Ich meine schon, dass sich EGroupware rückstandslos deinstalliern lässt. Bin mir aber auch nicht sicher, ob das immer, unter allen Umständen und bei einer kaputten Installation funktioniert.
Die DB-Inhalte bleiben aber vermutlich stehen. Fände ich nun auch nicht ungewöhnlich.

Grundsätzlich ist das aber auch bei einigen anderen Apps auf dem UCS nicht ganz einfach mit dem deinstallieren. Lässt sich im Forum schön beobachten.

Da bin ich nicht ganz bei dir. Sollst mal sehen, wie viel dann jammern dass die Daten weg sind.
Wir preferieren eine Installation zu reparieren.

Zum Testen installieren sich täglich Leute EGw auf einem UCS. Ich kann mich nicht erinnern, dass schon einmal jemand über eine nicht funktionierende Deinstallation klagte.

Vielleicht werde ich das später mal testen. Aktuell hat uns unsere bevorstehendes Release 21.1 fest im Griff:


Grüße nach Hamburg
Stefan


Mastodon