Update von 17.1 auf 19.1.20190917 - Probleme/Erfahrung

[Andreas_Stein]

Hallo zusammen,
nachdem ich es nun Wochen rausgeschoben habe, habe ich vor 2 Wochen angefangen, meine 17.1CE Installation - mit dem nervigen Hinweis, das 1 “Neues EGroupware Release 19… verfügbar” ist - auf 19.1 upzudaten. Meine “alte” Installation ist eine VM mit Ubuntu 18.04-32bit. Es hat etwas gedauert, bis ich herausbekommen habe, das “apt install egroupware-docker” nur mit einem 64bit System funktioniert. Also - komplett neues System aufgesetzt (Ubuntu18.04-64bit / Apache / MariaDB / PHP7.3 / Postfix/Cyrus-IMAP / let’s encrypt), eGW17.1 installiert, groups und phpbrain nachinstalliert, Datenbank eingespielt (ging fehlerfrei!), Mailstore (Cyrus-IMAP) kopiert - alles bestens. Heute habe ich mich dann getraut, und “apt install egroupware-docker” probiert - danach ging nichts mehr. Ja, ich habe vorher “domain.tld/egw” statt “domain.tld/egroupware” benutzt. Also zurück zum Sicherungspunkt, und umgestellt auf “…/egroupware”. Neuer Versuch - marginal besser: Anmeldemaske erscheint wieder. Da ich Authentifizierung über Mail benutze, ging natürlich “localhost” nicht mehr. Per /egroupware/setup korrigiert. Neuer Versuch: Geben Sie den Code für die 2-Faktor-Authentifizierung ein ???. In einem Forumbeitrag habe ich dann gelesen, das es evtl. mit https zu tun hat. Also das automatische Umschreiben im Apache abgeschaltet, und per http://domain.tld/egroupware konnte man sich dann ohne “2-Faktor-Auth…” anmelden, um diese in den Einstellungen zu deaktivieren. Automatisches Umschreiben wieder aktiviert - Anmeldung möglich. Das nächste Problem: Das Mailkonto (…localhost) muß gelöscht und neu angelegt werden, geht aber nur bedingt, da der Sieve-Port 4190 nun nicht mehr erreichbar ist. Auch der Fehler beim Anmelden “Error contacting API/Server: /api/info” gibt nicht viel her. Die Gruppenverwaltung wurde zwar übernommen, allerdings kann ich nur Gruppen anlegen. Beim Löschen gibt es einen Fehler ! Bildschirmfoto vom 2019-09-22 23-50-38|450x239 Leider kann ich die Wissensdatenbank nicht aufrufen, weil jegliche scrollbuttons, mit denen man im linken Seitenfenster hoch und runter scrollen könnte, fehlen!!!. Evtl. gibt es eine Möglichkeit, diese einzuschalten, aber gefunden habe ich nichts. Für Tips zu

fehlender Sieve-Port,
fehlende Scrollbuttons,
Ändern des Aufrufs von egw statt egroupware
Fehler in der Gruppenverwaltung

würde ich mich wirklich freuen - dann könnte ich nächstes Wochende wieder einen Versuch unternehmen.

viele Grüße

Andreas

[Andreas_Stein]

das mit dem fehlenden Sieveport habe ich gefunden (cyrus.conf / listen= localhost:sieve ändern in listen=sieve)

[RalfBecker]

Hi Andreas,

Geben Sie den Code für die 2-Faktor-Authentifizierung ein ???. In einem Forumbeitrag habe ich dann gelesen, das es evtl. mit https zu tun hat. Also das automatische Umschreiben im Apache abgeschaltet, und per http://domain.tld/egroupware konnte man sich dann ohne “2-Faktor-Auth…” anmelden, um diese in den Einstellungen zu deaktivieren.

Kannst Du das bitte etwas erläutern. Die 2-Faktor-Authentifizierung hat nix mit https zu tun und per Default ist sie nur aktiv, wenn ein Benutzer sie für sich eingerichtet hat.

fehlende Scrollbuttons,

Das geht im Moment nur mit dem Mousewheel. Wir sind am Schauen, ob wir dafür wieder (per Einstellung) eine Möglichkeit für Benutzer ohne Wheelmouse schaffen können.

Ändern des Aufrufs von egw statt egroupware

Das geht im Prinzip, ich würde Dir aber davon abraten. Die Änderungen die Du dafür in der Apache Konfig machen musst, sind genau die die beim nächsten Update wieder für großen Ärger sorgen. Ich würde in der Apache Konfig einen zusätzlichen permanenten Redirect von /egw auf /egroupware eintragen. Damit sollten die Browser und CalDAV/CardDAV Clients automatisch klar kommen.

Fehler in der Gruppenverwaltung

Leider wird mir der Screenshot nicht angezeigt

Ralf

[Andreas_Stein]

Hallo Ralf,

danke für die Tips.

Kannst Du das bitte etwas erläutern. Die 2-Faktor-Authentifizierung hat nix mit https zu tun und per Default ist sie nur aktiv, wenn ein Benutzer sie für sich eingerichtet hat.

Ich habe meine alte 17.1 nun gemäß deinen Tips vor dem Update folgendermaßen “ertüchtigt”:
000-default.conf: Redirect permanent /egw/ /egroupware/
domain.tld/egw/setup, gegewärtige Konfiguration überarbeiten:
Hostname des Computers auf dem der Server läuft: name.dyndns.org
Welche Art der Authentifizierung wollen Sie benutzen: Mail
POP/IMAP Mail Server Hostname oder IP Adresse[:port]: 192.168.xxx.xxx
in egw_ea_accounts die Spalten acc_imap_host, acc_sieve_host, und acc_smtp_host alle Zeilen von localhost auf 192.168.xxx.xxx geändert.
Wichtig: es muß die IP-Adresse eingesetzt werden, und nicht der Name des Servers. Das funktioniert nur bis zum Update, da der “gedockerte NGINX” die hosts-Datei scheinbar nicht mehr zur Namensauflösung benutzt - In der Folge kommt es zu ewigen Hängern.
jetzt sudo apt-get install egroupware-docker ausführen.
Wenn ich nun den Browser neu starte, und https://name.dyndns.org/egw eingebe, wird mir in der Eingabemaske die 2-Faktor-Authentifizierung angezeigt, und wenn ich versuche, mich mit meinem (admin)-Konto anzumelden, verlangt er nach dem Code.
Gehe ich nun hin, und kommentiere in der 000-default.conf
RewriteCond %{HTTPS} !=on
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
aus, starte meinen apache neu, gebe im Browser nun http://name.dyndns.org/egw ein, wird mir ebenfalls wieder in der Eingabemaske die 2-Faktor-Authentifizierung angezeigt, aber nun wird kein code abgefragt, und ich kann mich einloggen. Der Ablauf ist 1:1 reprduzierbar.
Als erstes begrüßt mich nun die im 1. Post erwähnte Fehlermeldung “Error contacting API server: /api/info”. Diese Meldung kommt nur beim Anmelden. Wenn ich Rocket-Chat deinstalliere (Anwendungen verwalten), kommt diese Meldung nicht mehr.

Grundsätzlich fehlt in dem Update-Script noch ein: systemctl enable docker, da nach dem Neustart der VM beim Aufruf sonst nur “service not availible” im Browser zu sehen ist.

Der Fehler in Gruppenverwaltung besteht weiterhin (popup-Fenster):
Auf Name.dyndns.org wird folgendes anzeigt:

Ein Fehler ist aufgetreten

Argument 4 passed to adm_delete_account::__construct()
must be of the type array, null given, called in /usr/share/
egroupware/admin/inc/class.admin_account.inc.php on line 336

Außerdem kann ich beim Anlegen/Bearbeiten einer Gruppe keine Beschreibung eingeben.

viele Grüße
Andreas

[RalfBecker]

Wichtig: es muß die IP-Adresse eingesetzt werden, und nicht der Name des Servers. Das funktioniert nur bis zum Update, da der “gedockerte NGINX” die hosts-Datei scheinbar nicht mehr zur Namensauflösung benutzt - In der Folge kommt es zu ewigen Hängern.

Du meinst die /etc/hosts auf dem Host selbst. Was Du machen kannst ist Hosts Einträge in den Container geben:

EGroupware/build.opensuse.org/blob/master/server:eGroupWare/egroupware-docker-19.1/egroupware-docker/docker-compose.yml#L61

Wenn ich nun den Browser neu starte, und https://name.dyndns.org/egw eingebe, wird mir in der Eingabemaske die 2-Faktor-Authentifizierung angezeigt, und wenn ich versuche, mich mit meinem (admin)-Konto anzumelden, verlangt er nach dem Code.

Wie ich schon geschrieben habe ist die 2-Faktor-Authentifizierung per Default ausgeschaltet, außer man hat sie für sich (unter 19.1) eingerichtet. Ich habe gerade nochmal eine neue 19.1 installiert und kann mich sowohl unter http wie unter https daran anmelden. Evtl. hast Du mit der Datenbank schon mal einen 19.1 Update-Versuch gemacht und dabei die 2-Faktor-Authentifizierung für Dich eingeschaltet.

Die 2-Faktor-Authentifizierung hat aus guten Grund den Default das sie sich jeder selbst einschalten kann. Das sollte nicht ohne Grund abgeschaltet werden. Ich muss dieser Empfehlung von Dir deutlich widersprechen.

RewriteCond %{HTTPS} !=on
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]

Hmm, das ist nicht von EGroupware, es ist eine automatisch Umleitung von http auf https, z.B. von Let’s Encrypt.

Als erstes begrüßt mich nun die im 1. Post erwähnte Fehlermeldung “Error contacting API server: /api/info”.

Die Meldung besagt nur, das mit dem Rocket.Chat Server nicht kommuniziert werden konnte. Die Gründe dafür sind vielfältig:

• der Rocket.Chat Container wurde garnicht installiert
• die URL unter der der Container erreichbar ist wurde noch nicht in der EGroupware (Admin >> Anwendungen >> Rocket.Chat) konfiguriert
• Rocket.Chat ist unter der konfigurierten URL nicht erreichbar
• der Benutzer hat sich noch nicht per OAuth2/OpenID Connect an Rocket.Chat angemeldet und deswegen stellen wir für den API Zugriff nicht automatisch ein Access-Token aus

Die Gute Nachricht ist die Fehlermeldung besagt nur genau das EGroupware nicht mit der Rocket.Chat API sprechen konnte und hat sonst keine Auswirkung außerhalb der Teile die Rocket.Chat betreffen.

Grundsätzlich fehlt in dem Update-Script noch ein: systemctl enable docker, da nach dem Neustart der VM beim Aufruf sonst nur “service not availible” im Browser zu sehen ist.

Welche Distribution und welches Docker Paket hast Du installiert?
Für Debian/Ubuntu und deren docker.io Paket wird mit der Installation automatisch ein start und enable ausgeführt.
Für RHEL/CentOS/SUSE passiert das nicht und wird statt dessen von der EGroupware Installation gemacht:
https://github.com/EGroupware/build.opensuse.org/blob/master/server:eGroupWare/egroupware-docker-19.1/egroupware-docker.spec#L137

Der Fehler in Gruppenverwaltung besteht weiterhin (popup-Fenster):

Auf Name.dyndns.org wird folgendes anzeigt:

Ein Fehler ist aufgetreten

Argument 4 passed to adm_delete_account::__construct()

must be of the type array, null given, called in /usr/share/

egroupware/admin/inc/class.admin_account.inc.php on line 336

Von welchem Fehler sprichst Du bzw. was genau machst Du um den Fehler zu reproduzieren?

Außerdem kann ich beim Anlegen/Bearbeiten einer Gruppe keine Beschreibung eingeben.

Das ist eine Einschränkung der nicht EPL Gruppenverwaltung, gab’ es zu der Zeit noch nicht, sprich wurde später in der EPL eingebaut.

Ralf

[Andreas_Stein]

Hallo Ralf,

danke für die Rückmeldung. Die 2-Faktor-Authentifizeirung bleibt bei mir mittlerweile auch inaktiv, wenn ich als 1. …/setup aufrufe, und von da aus “zurück zur Benutzeranmeldung” gehe - warum auch immer.

Welche Distribution und welches Docker Paket hast Du installiert?

Ist wohl meiner Naivität geschuldet: kein Paket .Es sah für mich so aus, das docker automatisch mit egroupware installiert wird.

Von welchem Fehler sprichst Du bzw. was genau machst Du um den Fehler zu reproduzieren?

Ich versuche, eine Gruppe zu löschen. Funktioniert unter 17.1 einwandfrei.

Diese Meldung kommt nur beim Anmelden. Wenn ich Rocket-Chat deinstalliere (Anwendungen verwalten), kommt diese Meldung nicht mehr.

Das war zu früh gefreut - wenn ich die VM neu starte, ist Rocket.Chat wieder installiert, und die Fehlermeldung ist natürlich auch wieder da - was mache ich da falsch?

viele Grüße
Andreas

[StefanU]

Hallo Andreas,

Das war zu früh gefreut - wenn ich die VM neu starte, ist Rocket.Chat wieder installiert, und die Fehlermeldung ist natürlich auch wieder da - was mache ich da falsch?

Du könntest den Benutzern (ggf. über die Gruppen) die Ausführungsrechte für Rocket.Chat entziehen.So lange du das nicht nutzt… Dann wird nicht versucht Rocket.Chat anzusprechen und die Meldung bleibt aus.
Was aber erst einmal nichts mit der Installation/Konfiguration von Rocket.Chat zu tun hat.

Ich versuche, eine Gruppe zu löschen. Funktioniert unter 17.1 einwandfrei.

Ich habe das bei mir getestet: funktioniert wie es soll.
Bitte mache dafür ein neues Thema auf und dokumentiere dein Vorgehen mit screenshots. Wenn wir nicht sehen wie du vorgehst können wir das schlecht bzw. gar nicht nachvollziehen.

Ist wohl meiner Naivität geschuldet: kein Paket .Es sah für mich so aus, das docker automatisch mit egroupware installiert wird.

Das tut es ja auch, wenn du das Paket egroupware-docker installierst bzw. damit ein Update machst. Schau mal hier:

🇩🇪 Docker (in EGroupware 19.1)?

Gruß
Stefan

[RalfBecker]

Das war zu früh gefreut - wenn ich die VM neu starte, ist Rocket.Chat wieder installiert, und die Fehlermeldung ist natürlich auch wieder da - was mache ich da falsch?

Rocket.Chat App wird automatisch installiert, sprich beim Update von 17.1, aber auch bei jedes mal der Container neu startet.

Ich habe gerade etwas commited, damit ein unkonfiguriertes Rocket.Chat keine Fehlermeldungen mehr von sich gibt.

Ralf

[Andreas_Stein]

Hallo Stefan,

Du könntest den Benutzern (ggf. über die Gruppen) die Ausführungsrechte für Rocket.Chat entziehen.So lange du das nicht nutzt… Dann wird nicht versucht Rocket.Chat anzusprechen und die Meldung bleibt aus.

Was aber erst einmal nichts mit der Installation/Konfiguration von Rocket.Chat zu tun hat.

das mit den Rechten entziehen hat jetzt geklappt. Ich hatte das zwar schon in einem anderen Beitrag gelesen und probiert, aber iwie waren die Rechte nach dem Neustart wieder da. Ausprobieren würde ich das Modul natürlich trotzdem gerne mal - gibt es evtl. ein kleines howto, in welcher Reihenfolge man sich wo/wie anmeldet, um das Modul zu aktivieren?, bzw. was man noch installieren muß?

Das tut es ja auch, wenn du das Paket egroupware-docker installierst bzw. damit ein Update machst. Schau mal hier:

Da habe ich geschaut. Ich habe diesmal auch (Ubuntu 18.04) erst apt-get install docker, und dann apt-get install egroupware-docker ausgeführt, allerdings laufen die Container nach dem Neustart der VM nicht, und müßen mit “systemctl start docker” manuell gestartet werden.

viele Grüße

Andreas

[StefanU]

Hallo Andreas.

natürlich trotzdem gerne mal - gibt es evtl. ein kleines howto, in welcher Reihenfolge man sich wo/wie anmeldet, um das Modul zu aktivieren?, bzw. was man noch installieren muß?

Wenn du Rocket.Chat bei dir lokal selbst betreiben möchtest, dann kommst du um eine (Installation und) Konfiguration nicht umhin. Schau mal hier:

EGroupware/egroupware

Und ich habe noch in die Release-Notes (an denen ich noch arbeite…) eingefügt:

Changelog pre-release 19.1.20190717 GitHub

• better guiding through Rocket.Chat installation process
  We have added detailed documentation and step-by-step instructions:

Einschalten und benutzen ist halt leider nicht. Du musst da auch einige Entscheidungen für dich treffen und einstellen.

Gruß
Stefan

Da habe ich geschaut. Ich habe diesmal auch (Ubuntu 18.04) erst apt-get install docker, und dann apt-get install egroupware-docker ausgeführt,

Das war so nicht gedacht. Nur apt install egroupware-docker und im Idealfall ist alles perfekt installiert. Ich habe das die Tage mit Debian 10 durchgespielt und es funktioniert wie es soll. Das werde ich auch noch einmal als Erfahrungsbericht hier im Forum aufbereiten.
Ich persönlich bin von Ubuntu nun auf Debian als Host umgestiegen. Ubuntu hatte ich bislang wegen Nginx/SSL/HTTP/2/… Ist aber nun nicht mehr nötig. Da spare ich mit den ganzen Klimbim den Canonical in Ubuntu einbaut und installiere mir ein schlankes Debian. Geschmackssache…

Gruß
Stefan