Migration von 1.8 zu 17.1 (Debian 9): Fehler in Benutzerverwaltung

sebalis 2019-04-02 20:51:52 UTC #1

Hallo,

ich versuche, eine 1.8-Instanz (nur als Kalender genutzt) auf ein frisch installiertes 17.1. zu migrieren. Dabei gehe ich vor wie in „Fehler mit sqlfs / VFS bei frischer Installation auf Debian Stretch“ beschrieben. Ich nutze die dort beschriebene Installation, lösche aber per apt purge alle egw-Pakete und in der Datenbank die Tabelle und den User „egroupware“. Dann führe ich apt install egroupware-epl aus (neue Paketversionen von heute), gebe die Userdaten an und prüfe die Installation. Anschließend füge ich das compat-Paket hinzu (apt install egroupware-epl-compat), erzeuge in der 1.8-Instanz eine Datenbanksicherung, lade diese als Datei herunter und in der 17.1-Instanz hoch.

Ich kann mich dann mit den Zugangsdaten aus der Alt-Instanz einloggen. Ich versuche dies als ein Admin-User und gehe in der Admin-Anwendung in die Liste der Benutzerkonten. Wenn ich die Eigenschaften eines Benutzers via Rechtsklick und „Öffnen“ anzeigen möchte, erscheint kein Popup (in Firefox), sondern es öffnet sich ein neuer Reiter mit diesem Text:

Blockquote
An error happened
CreateObject() file /usr/share/egroupware/api/inc/class…inc.php not found!
Click here to resume your eGroupWare Session.

Die Zeile „Click here […]“ ist ein Link auf die URL /egroupware/index.php, ein Klick darauf führt zu einer Wiederholung des Fehlers. Öffnen desselben Links in einem neuen Reiter oder neuen Fenster führt mich zurück zur Hauptansicht.

Im Error-Log steht für diese Requests (Domainname und Username abgeändert):

[Tue Apr 02 22:46:10.552721 2019] [:error] [pid 20679] [client 192.168.1.133:51910] An error happened (EGroupware\\Api\\Exception\\AssertionFailed): CreateObject() file /usr/share/egroupware/api/inc/class..inc.php not found!, referer: https://egroupware-test.domain/egroupware/index.php?cd=yes
[Tue Apr 02 22:46:10.552762 2019] [:error] [pid 20679] [client 192.168.1.133:51910] #0 /usr/share/egroupware/index.php(151): CreateObject('api.'), referer: https://egroupware-test.domain/egroupware/index.php?cd=yes
[Tue Apr 02 22:46:10.552770 2019] [:error] [pid 20679] [client 192.168.1.133:51910] #1 {main}, referer: https://egroupware-test.domain/egroupware/index.php?cd=yes
[Tue Apr 02 22:46:10.552782 2019] [:error] [pid 20679] [client 192.168.1.133:51910] # Instance=default, User=adminuser, Request=GET https://egroupware-test.domain/egroupware/index.php?account_id=45, User-agent=Mozilla/5.0 (X11; Linux x86_64; rv:66.0) Gecko/20100101 Firefox/66.0, referer: https://egroupware-test.domain/egroupware/index.php?cd=yes

Eine gleiche Meldung mit gleichen Log-Einträgen entsteht, wenn ich per Knopf-Klick einen Benutzer hinzufügen möchte.

Was kann ich tun?

StefanU 2019-04-02 21:21:33 UTC #2

Warum löscht man auf einen frischen Installation die Pakete wieder??

Unsere Installationsanleitung:

Hier findes du auch die zu berücksichtigenden Update-Hinweise.

Kannst du erst noch einmal eine einfache Standard -Installion machen?:
Debian nur mit ssh installieren
Repos eintragen
Pakete installieren
Backup im Setup hochladen, alles durchgehen bis alles grün
Installation noch einmal im Setup prüfen

Protokolliere das am besten für dich mit. Eventuell

Bitte immer die Version nennen. Ansonsten wird in ein paar Monaten nicht mehw wissen von welche du hier sprichst.
Schau bitte mal hier:

Einen gleich/ähnlichen Fall haben wir hier:

Aber ohne Antwort können auch wir nicht helfen…

Gruß
Stefan

sebalis 2019-04-02 22:56:49 UTC #3

Ich hoffe, dass ich auf diesem Weg alle Spuren der vorherigen Installation beseitigen kann. Vor allem möchte ich eventuelle Konfigurationsdateien entfernen und neu erzeugen, und ich möchte den initialen Datenbankinhalt ebenfalls neu erzeugen. In diesem Fall bekomme ich auf diesem Weg ja auch das Upgrade. Die Versionsnummer aller egw-Pakete ist jetzt übrigens 17.1.20190402.

Ich würde den Aufwand einer neuen Systeminstallation gerne vermeiden. Auch deshalb verwende ich ja die beschriebene Methode. Ich hatte gehofft, dass der Zustand ziemlich genau einer Neuinstallation entspricht. Ich habe natürlich auch das System aktualisiert. Das einzige, was von der vorigen egw-Installation geblieben ist, waren die zusammen mit dem egroupware-Paketen installierten Abhängigkeiten, also z.B. apache und mariadb. Meinst du, dass eine Analyse sonst nicht möglich ist?

Ich versuche mal, für meinen Fall die Informationen nachzuliefern, die in dem anderen Fall fehlten:

Die URL im Reiter mit der Fehlermeldung (wie gesagt, der Reiter erscheint anstatt des normalen Subfensters) ist https://egroupware-test.domain/egroupware/index.php?account_id=40 (erstaunlicherweise nicht im Log wiedergegeben)
Nach Einloggen in /egroupware/setup sehe ich die folgenden Meldungen:
Step 1 - simple application management completed Your EGroupware API is current Step 2 - configuration Completed Configuration completed Step 3 - admin account Completed Accounts existing Step 4 - advanced application management Completed The following applications need to be upgraded: egw-pear, syncml, manual Step 5 - DB backup and restore Completed
Nach Klick auf den Knopf „Manage applications“ bei Punkt 4 sehe ich eine Tabelle mit folgenden nicht grünen Zuständen:
- collabora-Dependency failure:(appname: filemanager; versions: 17.1; appname: api; versions: 17.1; ))D (current version = ‹leer›, available version = 17.1)
- egw-pear-Sources deleted/missing - V (current version = 1.8, available version = deleted)
- manual-Sources deleted/missing - V (Versionen wie egw-pear)
- syncml-Sources deleted/missing - V (Versionen wie egw-pear)

StefanU 2019-04-03 07:06:01 UTC #4

Die Standard-Installation ist doch in ein paar Minuten erledigt.
Der Aufwand, eine steinalte Installation mit einem vermutlich unsicheren, veralteten Betriebssystem und womöglich mit einem alten, unsicheren und nicht mehr unterstützten PHP zurechtzufrickeln dürfte deutlich höher sein.

Das ist schon ein Mix aus alt und neu.

Dach doch bitte eine einfache Standard-Installation und schaue erst einmal, ob du das Update der Datenbank sauber durch bekommst.
Du musst bedenken, dass dann bei dem Vorgang die Datenbankkonvertierungen von jeder verpassten Version fehlerfrei durchlaufen müssen. Und ob die 1.8er DB den Erwartungen der Programme entspricht… Wer weiß, was da über die Jahre so gelaufen ist.

Insofern:

Das ist in der Tat schwer aus der Ferne. Es ist ja für niemanden abzuschätzen, was da alles ist oder eben nicht ist auf deinem System. Ganz schlechte Karten…

Wir bieten dafür natürlich aus Support:

Gruß
Stefan

StefanU 2019-04-03 07:23:41 UTC #5

Zum Thema PHP ist unbedingt zu berücksichtigen:

Stefan

sebalis 2019-04-03 07:24:03 UTC #6

Aber das ist ja nicht, was ich versuche. Ich benutze weiterhin die im letzten Monat frisch aufgesetzte VM. Alle beschriebenen Installationsarbeiten und Zustände beziehen sich auf dieses System. Vom Altsystem kommt lediglich die im dortigen Web-Interface erzeugte Backup-Datei.

sebalis 2019-04-03 07:30:18 UTC #7

Ich habe wahrscheinlich den Betreff falsch gesetzt – hätte ich statt „Update“ besser „Migration“ schreiben sollen? Auf dem neuen System lief von Anfang an PHP 7.0.33. Das System, von dem die Backup-Datei stammt, ist natürlich sehr alt (Ubuntiu 14, PHP 5.5.9) – wir möchten es selbstverständlich loswerden, anstatt daran weiter zu operieren.

sebalis 2019-04-03 07:31:36 UTC #8

Ich habe den Betreff jetzt geändert. Sorry für die Verwirrung.

StefanU 2019-04-03 11:51:40 UTC #9

OK, keine alte Installation. Schon mal gut!

Dennoch: Bitte setze eben ein neues Debian/EGw (wie von mir oben beschrieben) auf und importiere dein Backup.
Wir müssen erst einmal herausfinden, ob bei einer Standard-Installation das Problem auch auftritt. Wir haben dann eine definierte Umgebung…

Gruß
Stefan

sebalis 2019-04-03 13:34:39 UTC #10

Ich habe doch in meiner anderen Frage recht genau beschrieben, wie ich installiert habe. Die Installation folgte bekanntlich der textuellen Anleitung auf software.suse.org, die man von https://www.egroupware.org/en/products/installation-on-your-own-server-free-version/ aus erreicht.

Ich beschreibe nochmal, was seitdem geschehen ist: Ich habe alle egroupware-Pakete via purge entfernt, die Datenbank gelöscht, nach weiteren Spuren im Filesystem gesucht und keine gefunden, dann die Pakete erneut installiert (jetzt zusätzlich egroupware-epl-compat), dann direkt das Backup vom Altsystem eingespielt. Mir ist klar, dass eine definierte Umgebung Voraussetzung ist für eine handhabbare Supportsituation. Aber ich bin überrascht, dass mein beschriebenes Vorgehen nicht als definierte Umgebung anzusehen ist.

Ich bin leider gerade sehr mit anderen Dingen belastet und ab morgen für ca. eine Woche nur sehr wenig erreichbar. Ich hatte gehofft, vorher noch einen Hinweis für dieses Problem zu bekommen. Wenn es auf diesem kurzen Weg nicht geht, wäre eine Verschiebung auf ca. übernächste Woche die einzige Alternative.

sebalis 2019-04-29 16:36:35 UTC #11

Ich habe jetzt die Installation noch einmal von vorne durchgeführt, und wie erwartet entsteht genau das gleiche Problem. Installationsprotokoll:

– Debian installiert (debian-9.8.0-amd64-netinst.iso, deutsch, bei Software nur SSH-Server, als einziges Zusatzpaket less)
– dpkg-reconfigure locales (en_US.UTF-8 hinzugefügt, Standardsprache bleibt Deutsch)
– apt update
– apt upgrade
– wget --no-check-certificate -nv https://download.opensuse.org/repositories/server:eGroupWare/Debian_9.0/Release.key -O Release.key
– apt-key add - < Release.key
– apt update
– apt-get install egroupware-epl egroupware-epl-compat
– Aus der vorigen, auch schon frischen Installation wiederhergestellt: /etc/php/7.0/{apache2,cli}/php.ini, Apache-Konfiguration mit Domain und SSL (die originale egroupware.conf eingebettet in einen VirtualHost-Abschnitt, SSL-Modul aktiviert)
– Installation überprüft (/egroupware/setup/check_install.php), alles grün bis auf drei gelbe Warnungen: 1. Checking extension pgsql is loaded or loadable: False / The pgsql extension is needed, if you plan to use a pgSQL database. 2. Warning Checking extension pdo_pgsql is loaded or loadable: False / The pdo_pgsql extension is needed, if you plan to use a pgSQL database. 3. Checking PEAR pear.horde.org/Horde_Icalendar (2.0.0) is installed: False / PEAR::Horde_Icalendar is needed by: Api/Mail. You can install it by running: cd /usr/share/egroupware; php composer.phar install
– Überprüft, dass die Anwendung mit den installierten Usern funktioniert und auch die Eigenschaften eines Users aufgerufen werden können. Sie erscheinen in einem Popup-Fenster.
– Error-Log überprüft, dabei folgende regelmäßig auftauchende Meldung entdeckt: PHP Warning: realpath(): open_basedir restriction in effect. File(/var/www/html) is not within the allowed path(s): (/usr/share/egroupware:/var/lib/egroupware:/tmp:/usr/lib/ssl/certs:/usr/share/ca-certificates) in /usr/share/egroupware/setup/inc/class.setup_detection.inc.php on line 556
– frische Datenbank gesichert
– Datenbanksicherung aus der 1.8-Installation hochgeladen und in der neuen Installation wiederhergestellt
– als Admin in /egroupware/setup eingeloggt und entsprechend der Aufforderung Datenbank-Upgrade angestoßen. Viele Meldungen, keine Fehler entdeckt.
– Wieder Installation überprüft (/egroupware/setup/check_install.php), dabei Fehlermeldung entdeckt, dass für die Anwendungen egw-pear, manual und syncml fehlende Sourcen haben; diese drei deshalb entfernt
– einzige verbleibende Warnung: collabora-Dependency failure:(appname: filemanager; versions: 17.1; appname: api; versions: 17.1; ))D*
– Mit Admin-Account eingeloggt und Eigenschaften eines Benutzers aufgerufen (Rechtsklick, Menüpunkt „Öffnen“). Es öffnet sich kein Popup, sondern ein neuer Reiter in Firefox mit der ganz oben schon angeführten Fehlermeldung und den dort genannten Einträgen im Error-Log.

RalfBecker 2019-04-30 15:39:59 UTC #12

Poste doch mal einen Screenshot der Setup Anwendungsverwaltung.
Filemanager und Api sollten als 17.1 ja installiert sein.
Irgendwas ist bei Dir komisch.

Ralf

sebalis 2019-04-30 15:47:59 UTC #13

Hier ist der Screenshot:

(Schade, dass ich den Tippfehler bei „advanced“ im Namen des Bildes offenbar nicht eliminieren kann.)

RalfBecker 2019-04-30 16:34:02 UTC #14

Gut, das erklärt ja den Abhänigkeitsfehler!

Bin mir nicht sicher, wie gut EGroupware 17.1 ohne Adressbuch und Dateimanager funktioniert, vermutlich nicht 100%. AB wird z.B. benötigt um neue Benutzer anzulegen.

Ralf

sebalis 2019-04-30 17:25:13 UTC #15

Ah, okay. Für solche Schlussfolgerungen fehlt mir leider noch die Erfahrung. Ich habe jetzt die Checkbox unter „Install“ angewählt und den „Save“-Knopf geklickt. Ich bekam etwas, was wie eine Erfolgsmeldung aussah (neues Aussehen dieses Fensters angehängt). Leider hat sich das Problem dadurch in keiner Weise verändert. Ich erinnere auch nochmal daran, dass vor dem Einspielen der Datenbanksicherung aus der 1.8-Instanz diese Funktion, äh, funktionierte.

sebalis 2019-04-30 17:25:57 UTC #16

Ach so, ich sollte das wohl für den Dateimanager auch tun … Moment …

sebalis 2019-04-30 17:31:01 UTC #17

Meldung bei der Installation des Dateimanagers: „App install/remove/upgrade: / Filemanager Tables installed, unless there are errors printed above…“. Mit einer entsprechenden Meldung war auch die vorige App-Installation abgelaufen. Neuer Screenshot unten. Leider keine Änderung bezüglich des Fehlers.

sebalis 2019-04-30 18:14:03 UTC #18

Hier noch eine vielleicht wichtige Meldung aus der Fehlerkonsole von Firefox beim Aufrufen der Liste der Benutzer: Content Security Policy: The page’s settings blocked the loading of a resource at inline (“script-src”). index.php:9:70780

StefanU 2019-04-30 18:38:55 UTC #19

Warum installierst du die Anwendungen denn nicht alle?
Stefan

RalfBecker 2019-05-01 14:34:32 UTC #20

Also einen CSP Fehler kannst Du nicht durch die aktuelle EGroupware bekommen, die verwendet das seit 14.1!

Bist Du wirklich sicher, das Du keine alten Apps oder alten Code aus der 1.8 Zeit noch installiert hast?

Eine Möglichkeit wäre auch eine Nachricht auf der Start- oder Login-Seite, die JavaScript enthält.
(Leere im Zweifel mal die ganze egw_lang Tabelle.)

Trotz hoch scrollen habe ich leider immer noch nicht verstanden, was Dein ursprüngliches Problem ist
Das Collabora ohne Dateimanager nicht tut und Setup eine fehlende Abhängigkeit zeigt ist ja normal.

Ralf