Jitsi - 127.0.0.1:8080 in Conference-URL

[dl2rbi]

Beim Versuch eine neue Video-Konferenz zu planen ist mir aufgefallen, dass die Conference-URL hinter dem Hostnamen des JITSI-Servers den SUB-String 127.0.0.1:8080 enthält, der beim Aufruf zum Fehler 404 führt …

Beispiel:
https://jitsi.egroupware.net/127.0.0.1:8080-gw8tbBit1hWPjabHKtmT?jwt=e …

Aufgefallen ist mir dies erst nach Update auf V19.1.20200430

Grüße
Werner

[StefanU]

Hallo Werner,

das muss eine Misskonfiguration auf deiner Installation sein. Da steht normalerweise deine Domain.

Ohne nun etwas über deine Installation zu wissen: Was steht bei dir im Setup?:

Stefan

[dl2rbi]

Hallo Stefan,

danke für Deine schnelle Reaktion …

Ich habe das Setup nochmal kurz überprüft - dort ist der Hostname der entsprechenden Egroupware-Domain passend zur Domain gesetzt. Mit der Version 19.1.200409 hatte ich vor ein paar Wochen kurz getestet - soweit ich mich noch erinnern kann funktionierte es soweit - hatte damals allerdings keinen Partner zum Testen … zumindest kam kein 404-er Fehler seitens Jitsi-Servers.

Grüße
Werner

[StefanU]

Gerade mal bei einer frischen Installation getestet: Die nimmt korrekt den Eintrag aus dem Setup.

Dann müsstest du etwas über deine Installation erzählen.

Stefan

[dl2rbi]

Hallo Stefan,

ich hab mir kurz den Eintrag fder config in der Datenbank der entsprechenden Domain angeschaut.
Wenn seitens Jitsi der Eintrag der config phpgwapi hostname ausgewertet wird, dann sollte eigentlich alles passen. Dieser Wert ist in der Datenbank richtig gesetzt.
127.0.0.1:8080 erinnert mich mom. nur an Reverse-Proxy Konfiguration. In der Datenbank ist davon auf den ersten Blick nichts zu finden. Vielleicht kannst Du mir sagen, welcher Parameter / Wert hier seitens der entsprechenden Routinen übernommen wird.

Grüße
Werner

[StefanU]

127.0.0.1:8080 erinnert mich mom. nur an Reverse-Proxy Konfiguration

Das wird vermutlich schon in dem Bereich liegen. Darum ja auch meine Frage nach Informationen zu deiner Installation. Angefangen bei: Wie hast du EGroupware installiert…

Vielleicht kannst Du mir sagen, welcher Parameter / Wert hier seitens der entsprechenden Routinen übernommen wird.

Da verstehe ich jetzt nicht was du erwartest. Das ist alles abhängig von deiner Installation…

Stefan

[dl2rbi]

Hallo Stefan,

es handelt sich um die Docker-Installation (UBUNTU 18.04 LTS, PLESK), welche vor ca 6 Monaten von der aktuellsten 17.1 erstellt wurde. Deshalb auch die Reverse-Proxy Annahme. Im Setup der entsprechenden EGroupware-Domain ist der jeweilige Hostname eingetragen.

Die Conference-URL wird ja sicher aus verschiedenen SUB-Strings zusammengesetzt. Deshalb war die Frage, welche Variablen dazu verwendet werden. Dann könnte ich diese überprüfen. (z. B. Config-Einträge der Datenbank, wie von Dir schon angedeutet - Hostname etc. )

Grüße
Werner

[dl2rbi]

Hallo zusammen,
ich habe soeben das Update auf Version 19.1.20200605 durchgeführt.
In der Release von Anfang April (200409) funktionierte der Aufruf von JITSI - ab 19.1.20200430 nicht mehr.
An der Konfiguration hatte ich nichts verändert. (ausser OS- und Docker-Updates etc.)
Es wird nun Raumnummer: 127.0.0.1:8080-u4QcYKvHMq48OTZLamZF angezeigt.
127.0.0.1:8080 ist auch Teilstring der Conference-URL.

Konfiguration Testserver:

Grüße
Werner

[RalfBecker]

Hi Werner,

danke für die Info, der folgende Commit sollte das Problem beheben:

fix 127.0.0.1 in room name

Um das bei Dir zu testen führe bitte folgende Kommandos aus:

curl https://github.com/EGroupware/status/commit/fe82dee6dc5acc6cfed94eb3fd671d79b9f04b7a.patch | docker exec -i egroupware patch -d /usr/share/egroupware-sources/status -p1
cd /etc/egroupware-docker
docker-compose restart egroupware

Falls etwas nicht funktioniert kannst Du einfach zu dem original Container zurück:

cd /etc/egroupware-docker
docker-compose stop egroupware
docker-compose rm egroupware
docker-compose up -d
docker-compose restart nginx

Gib’ bitte kurz Bescheid, ob alles funktioniert.

Ralf

[dl2rbi]

Hallo Ralf,
danke für die schnelle Antwort.

Als Image verwende ich aktuell nicht latest:
image: egroupware/egroupware:19.1.20200605

Habe folgendes durchgeführt:
curl https://github.com/EGroupware/status/commit/fe82dee6dc5acc6cfed94eb3fd671d79b9f04b7a.patch | docker exec -i egroupware patch -d /usr/share/egroupware-sources/status -p1
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1408 100 1408 0 0 5374 0 --:–:-- --:–:-- --:–:-- 5374
patching file src/Videoconference/Backends/Jitsi.php
Hunk #1 FAILED at 178.
1 out of 1 hunk FAILED – saving rejects to file src/Videoconference/Backends/Jitsi.php.rej
patching file src/Videoconference/Call.php

docker-compose restart egroupware
Restarting egroupware … done

Beim Anlegen eines Video-Termins erhalte ich:

Habe die Änderungen nach Deiner Anleitung wieder verworfen …

Grüße
Werner

[RalfBecker]

Als Image verwende ich aktuell nicht latest:

image: egroupware/egroupware:19.1.20200605

Dann kann der Patch nicht funktionieren, warum verwendest bzw. versuchst Du nicht das aktuelle Image?

Ralf

[dl2rbi]

Hallo Ralf,
ja, das dachte ich mir auch, dass wir von verschiedenen Ständen patchen …
Ich war bisher der Meinung - das zuletzt frei gegebene Release ist identisch mit “latest”.

So sieht’s bei mir auch aus:

REPOSITORY TAG IMAGE ID CREATED SIZE
egroupware/egroupware 19.1.20200605 2dde74396730 8 days ago 421MB
egroupware/egroupware latest 2dde74396730 8 days ago 421MB
containrrr/watchtower latest 333738857dc9 12 days ago 15.2MB
nginx stable-alpine ab94f84cc474 7 weeks ago 21.3MB

Das Verhalten ist somit bei “latest” identisch …

Grüße
Werner

[RalfBecker]

Hmm, nicht sicher ich verstehe das jetzt richtig, latest und 19.1.20200605 haben den gleichen hash (2dde74396730), sprich sind identisch.

Ich glaube wir haben uns da missverstanden, Du verwendest nicht den Tag “latest” sondern machst manuelle Updates in dem Du den Tag in der docker-compose.yml auf den des letzten Release änderst. Damit bist Du schon auf dem aktuellen Image, aber halt nicht auf dem (rolling) Tag “latest”.

Anyway, der Patch war von master, ich habe Ihn jetzt nach 19.1 zurück portiert:

* Status/Videoconference: fix 127.0.0.1:8080 instead of host in room name when proxying

Sprich tausche einfach mal in dem Kommando aus meinem vorherigen Post den Commit Hash mit dem in der URL oben (plus .patch natürlich).

Ralf

[dl2rbi]

Hallo Ralf,

jetzt sind wir synchron … Patchen hat mit neuem Hash soweit funktioniert.

curl https://github.com/EGroupware/status/commit/ac7182bd5d4d11603309d191109fc61b1f790862.patch | docker exec -i egroupware patch -d /usr/share/egroupware-sources/status -p1
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1480 100 1480 0 0 5920 0 --:–:-- --:–:-- --:–:-- 5920
patching file src/Videoconference/Backends/Jitsi.php
patching file src/Videoconference/Call.php

/etc/egroupware-docker# docker-compose restart egroupware
Restarting egroupware … done

Bekomme jedoch weiterhin beim Übernehmen/Speichern folgenden Fehler, sobald Videokonferenz aktiviert ist:

Grüße
Werner

[dl2rbi]

Hallo Ralf,

habe in beiden Modilen die fehlende schliessende Klammer von str_replace() ergänzt …
nun wird die Conference-URL bzw. Raumnummer sauber generiert.

return ‘https://’.$this->payload[‘sub’].’/’.str_replace(’/’ , ‘’, Api\Header\Http::host()).’.*’;
return str_replace(’/’ , ‘’, Api\Header\Http::host()).’-’.Api\Auth::randomstring(20);

Grüße
Werner

[RalfBecker]

Ok danke

Habe den Typo jetzt behoben:

* Status/Videoconference: fix 127.0.0.1:8080 instead of host in room name when proxying

Für jeden der das Problem bei sich vor dem nächsten Paket beheben will, bitte folgende Kommandos (neuer Hash) verwenden:

curl https://github.com/EGroupware/status/commit/a833baaa419821aec0f7e52b94b3491e47378dd7.patch | docker exec -i egroupware patch -d /usr/share/egroupware-sources/status -p1
cd /etc/egroupware-docker
docker-compose restart egroupware

@dl2rbi bitte markiere den Thread noch als gelöst

Ralf