5 / 17
Jul 2021

Ich habe RocketChat (Docker) installiert, nachdem ich egroupware-docker, egroupware-mail installiert und ein passendes SSL Zertifikat für den Server generiert habe.

Anschließend habe ich versucht über die URL https://[server-dns-name]/rocketchat darauf zu zu greifen, was dann wie folgt aussieht (getestet mit Brave-Browser, Firefox und Chrome):

Diese Ansicht treibt dann die Prozessorlast lokal in die Höhe und die Seite wird nie angezeigt.
Kennt das wer? Was kann man da machen?

Danke & schöne Grüße
Manfred

  • created

    Jul '21
  • last reply

    Jul '21
  • 16

    replies

  • 3.0k

    views

  • 3

    users

  • 9

    links

Hallo Manfred.

Im Forum ist noch jemand mit der Meldung:

Das hatten wir vor längerer Zeit mal gesehen.

Bitte schaie mal auf dem System mit
docker ps -a
ob alle Container durchlaufen oder ob vielleicht z.B. die Mongo-DB für RC immer wieder neu startet.

Stefan

Es war tatsächlich noch ein zweites mongo docker image vorhanden:

54bda9be368d mongo:4.0 “docker-entrypoint.s…” 45 hours ago Exited (0) 45 hours ago egroupware-rocketchat_mongo-init-replica_1

Das habe ich mit “docker rm 54bda9be368d” entfernt und das System mal neu gestartet, macht aber leider keinen Unterschied.

Das andere mongo Image läuft gleich lange wie der Rest und lauscht laut "docker ps -a " auf Port 27017/tcp.

Ich habe jetzt nochmal alles von Rocketchat entfernt, alle docker images und volumes und auch Config Files in /etc/egroupware-rocketchat/
Und anschließend die Installation von Rocketchat frisch gestartet, das Docker Image wurde geladen, hier der Mitschnitt der Installation:

rocketchat.log.txt8 (66,9 KB)

Laut dem Installer gab es auch keine Probleme, docker zeigt mir jetzt wieder diesen einen mongo DB Container an der mit Exited nach der Installation beendet wird. Keine Ahnung ob das normal ist oder etwas zu bedeuten hat.

Das verwerfen und neu generieren der Mongo-DB führt leider auch zu nichts.

Ein weiteres Detail: Wenn ich per Port forwarding direkt auf 127.0.0.1:3000/rocketchat/ zugreife, dann lande ich exakt im gleichen Bildschirm bei dem’s nur blinkt.

Schöne Grüße
Manfred

Hi Manfred.

Der ist zur Initialisierung. Damit ist RC im Setup an einigen Stellen von uns vorkonfiguriert. Darum auch das “init”.
Kannst du (erst einmal) ignorieren, denke ich.


Nun, genau das ist ja RC. Wir integrieren das in EGw als IFrame mit einem Auth/SSO per OpenID. Alles automatisch bei der Installation konfiguriert. Siehe auch:


Du kannst dann natürlich auch direkt per /rocketchat auf RC zugreifen und einen Desktop- oder Mobil-Client benutzen.


Warum das nun blinkt weiß ich aber erst einmal auch nicht.

Fragen die mir einfallen:
Was meinen die Logfiles vom Reverse-Proxy, EGroupware-nginx, RC?
Ich installiere mir ganz gerne dockly dafür…:

Gibt die Webbrowser-Konsole etwas her?

Stefan

Guten Morgen Stefan,

danke für dein Antwort - die Logfiles geben leider nicht wirklich was her.
Die Browser Konsole liefert folgendes:

910bfdf……s_resource=true:853 Throttling navigation to prevent the browser from hanging. See https://crbug.com/882238. Command line switch --disable-ipc-flooding-protection can be used to bypass the protection

Ich denke es hängt irgendwie damit zusammen.

Wegen der URL im letzten Post - mir war schon klar dass das der Direktaufruf vom Rocketchat war/ist, ich wollte nur klar stellen dass der Fehler dort genau gleich auftaucht und ich denke dass das umgebende Egroupware als Quelle ausgeschlossen werden kann. :slight_smile:

Ich habe es gerade noch einmal mit einer frischen VM probiert und dort Ubuntu 20.04 neu installiert und dann egroupware-docker und egroupware-rocketchat. Sobald ich RC starte bekomme ich das Problem zu sehen, egal ob ich mit oder ohne SSL Zertifikat arbeite. In dem Fall habe ich alles via IP-Adresse angesprochen und eingerichtet, also komplett ohne DNS Auflösung weil’s nur lokal läuft.

Schöne Grüße
Manfred

Moin Manfred.

Bitte schau mal in:
/etc/egroupware-rocketchat
Dort liegen die Konf-Dateien für RC in EGw.

Eigene eigenen Änderungen machst du in der
docker-compose.override.yml

Kommentiere dort bitte mal
image: rocketchat/rocket.chat:latest
ein und folge

Das installiert die letzte Version von Rocket.Chat selber.
Bei mir komme ich dann ohne Flackern in das Setup.

Das aber nur zum testen. Bitte nie ohne Vollbackup und später auch möglichst wieder unsere Container verwenden. Die bringen so oft Updates, welche immer für eine Überraschung gut sind.

Stefan

Hallo Stefan,

mit der latest Version klappt es auf Anhieb so wie es sollte!
Somit ist klar wo der Fehler liegt, ein Downgrade von der latest wird vermutlich nicht klappen?

Wie geht es ab hier weiter?

Schöne Grüße
Manfred

Wo liegt denn der Fehler? Ich kann noch nicht erkennen, wo das technische Problem liegt.

So etwas hängt immer von der DB ab. Wenn sich Strukturen maßgeblich geändert haben, wird das meist eben nicht funktionieren.
Dazu habe ich in den Artikel etwas geschrieben:


Und das passiert oft bei RC. Die Entwicklung ist dermaßen rasant…

Wir müssen nun herausfinden, was die Ursache für dieses Verhalten ist. Das gestaltet sich mit RC nicht so einfach.


Du könntest für jetzt schauen, welche Version du nun bekommen hast und diese fest bei dir einstellen. Und dann schauen, ob die (innerhalb EGroupware) insbesondere mit der Authentifizierung korrekt funktioniert.
Bleib dann auf der Version. Später werden wir diese überholen und du kannst wieder auf unsere getestete.
Das aber immer mit Backup!

Stefan

Hallo Stefan,

die Version die ich jetzt mit latest gezogen habe ist 3.16.2.

Der Fehler liegt wohl in der 3.14.2’er Version vom Rocketchat, das war mit “Wo er liegt” gemeint! :slight_smile:

Als Sysop kann ich mich jetzt problemlos im RocketChat anmelden, ein Normaler User fliegt aus dem Egroupware System komplett raus. Es folgt folgende Fehlermeldung:

{“error”:“unsupported_grant_type”,“error_description”:“The authorization grant type is not supported by the authorization server.”,“hint”:“Check that all required parameters have been provided”,“message”:“The authorization grant type is not supported by the authorization server.”}

Im Nginx-Error-Log findet sich nichts, auch der Docker Log vom RocketChat bleibt still.
Wo protokolliert der RocketChat hin, gibt es da noch ein anderes Logfile?

Schöne Grüße
Manfred

Ausliefern tun wir aber

Du hast den Benutzer sysop als ersten Benutzer in RC eingetragen und bist das Setup durch gegangen?

Bitte Screenshots.

Darum auch


Stefan

Schau mal:

Er hat es mit der 3.15.3 hin bekommen. Magst du die mal versuchen?
Ansonsten müssen wir halt schauen wie wir die Auth wieder hin bekommen.

Stefan

Wenn die Authentifzierung nicht geht, kann es auch daran liegen, dass die Mail-Adresse mehrfach verwenden wird. RC gibt in dem Fall nur einen Fehler im Docker Log, aber nicht Richtung Benutzer!

Sprich es kann helfen das Docker Log des RC Containers anzuschane:

docker logs -f egroupware-rocketchat

Ralf

3.14.5 meine ich, hab mich vertippt…
ich versuche es mal mit der 3.15.3!

Dann bist du vermutlich auf unserer Registry:
https://quay.io/repository/egroupware/rocket.chat?tag=latest&tab=tags3
?

Das greift dann auf DockerHub zu:

Da hättest du vermutlich eine höhere Version bekommen…


Aber schau dir auf jeden Fall auch wie von Ralf aufgezeigt das RC-Log an.

Stefan

Schönen Abend, ich kann es bestätigen dass die Version 3.15.3 läuft.
Anmeldung mit dem Admin klappt und auch die User können zugreifen!

Der Eintrag:

image: rocketchat/rocket.chat:3.15.3

In der Datei /etc/egroupware-rocketchat/docker-compose.override.yml und anschließendes:

docker-composer pull
docker-composer up -d

Haben’s wieder in Ordnung gebracht!

Vielen Dank
Manfred

Hallo Manfred.

Prima, dass es bei dir nun erst einmal so läuft.

Wenn die Version bei dir vollständig funktioniert, dann bleibe am besten möglichst lange bei der.
Die Entwicklung ist rasant, aber für allgemeinen Gruppenchat in einer Organisation sollte alles da sein.
Die Entwicklung kannst du hier gut verfolgen:

Wir werden die 3.15.3 nun auch noch bei uns austesten und schauen ob sich etwas anders verhält.

Stefan