Behebung des BigBlueButton Greenlight Dashboard-Fehlers 500 Interner Serverfehler

Ein „A“ 500 Internal Server Errorbedeutet, dass eine serverseitige Anfrage fehlgeschlagen ist; es wird jedoch nicht angegeben, welche Komponente den Fehler verursacht hat. Suchen Sie in den Anwendungsprotokollen von Greenlight (BigBlueButton Greenlight Dashboard) zunächst nach der fehlerhaften Anfrage. Laut BigBlueButtons Fehlerbehebungsleitfaden ist ein 500-Fehler höchstwahrscheinlich ein Greenlight-Fehler. Die Ausnahme ist hilfreich: Wenn sie nur auf einigen Computern im lokalen Netzwerk auftritt und im Protokoll ein „Unsafe Host Error“ gemeldet wird, könnte eine Browser-Proxy-Einstellung die Ursache sein.

Greenlight v3 ist die aktuell dokumentierte Version und verwendet ein anderes Bereitstellungslayout als die ältere Version v2. Diese Anleitung hilft Ihnen, Ihre Version zu identifizieren, die relevanten Informationen zu sammeln und häufige Ursachen systematisch zu überprüfen. Sie setzt eine Docker-basierte Greenlight-Bereitstellung voraus. Verwenden Sie die Befehle als Serveradministrator und passen Sie Containername und -pfad an, falls Ihre Installation abweicht.

Ermitteln Sie, welche Komponente den Fehlercode 500 zurückgibt.

Greenlight ist die Webanwendung, die zum Anmelden, Verwalten von Räumen und Starten von BigBlueButton-Meetings verwendet wird. Ein Reverse-Proxy wie Nginx empfängt Browseranfragen und leitet sie an Greenlight weiter. Greenlight kommuniziert dann mit der BigBlueButton-API und nutzt Dienste wie PostgreSQL und Redis. Ein 500-Fehler kann von Greenlight, einem Proxy oder einer Abhängigkeit verursacht werden; ein Neustart der BigBlueButton-Mediendienste behebt keine Datenbank- oder Anwendungsfehler.

Notieren Sie zunächst, welche Aktion den Fehler auslöst: Öffnen des Dashboards, Anmelden, Laden einer Raumliste oder Starten eines Meetings. Erfassen Sie den URL-Pfad, die ungefähre Zeit, ob alle Benutzer betroffen sind und alle kürzlich vorgenommenen Änderungen wie Upgrades, DNS-Änderungen, Proxy-Wechsel oder Aktualisierung der Anmeldeinformationen. Lädt die Startseite, aber eine Aktion liefert den Fehlercode 500, lässt sich die zu untersuchende Fehlerursache eingrenzen.

Bereiten Sie alles vor, bevor Sie etwas ändern.

• Prüfen Sie, ob es sich um bigbluebutton/greenlight:v3ein v2-Image oder eine benutzerdefinierte Erstellung handelt. Wenden Sie v2-Anweisungen nicht auf v3 an.
• Bewahren Sie vor der Bearbeitung eine Kopie der entsprechenden Docker Compose-Datei und der Umgebungsvariablen-Datei an einem sicheren Ort auf. Diese enthalten Zugangsdaten.
• Notieren Sie den Zeitstempel des Fehlers und überprüfen Sie nur einen kurzen Abschnitt des Protokolls um diesen Zeitpunkt herum. Schwärzen Sie Passwörter, Zugriffstoken, API-Geheimnisse, E-Mail-Adressen und Links zu privaten Besprechungen, bevor Sie die Protokolle weitergeben.
• Führen Sie keine Aktionen aus docker compose down -v, entfernen Sie keine Datenbankvolumes und löschen Sie keinen Greenlight-Speicher, um das Dashboard „zurückzusetzen“. Diese Aktionen können Konten, Einstellungen oder hochgeladene Daten zerstören.

Schritt 1: Überprüfen Sie die laufenden Container und erfassen Sie die Ausnahme

Auf dem Docker-Host die Greenlight-bezogenen Container, ihre Images und ihren Status auflisten:

sudo docker ps -a --filter name=greenlight \
  --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'

Bei einer Standardinstallation von Greenlight v3 trägt der Anwendungscontainer üblicherweise den Namen „<Anwendungscontainer-Name>“ greenlight-v3. Lesen Sie dessen Ausgabe kurz vor dem Fehler:

sudo docker logs --since=15m --tail=200 greenlight-v3

Wenn Ihre Installation Compose verwendet, führen Sie docker compose psden docker compose logs --since=15m --tail=200Befehl im Verzeichnis mit der Compose-Datei aus. Die BigBlueButton-Installation speichert v3-Dateien möglicherweise unter `/var/www/bin` ~/greenlight-v3; bei eigenständigen Installationen kann dies abweichen. Verwenden Sie den tatsächlichen Speicherort und die Containernamen, die von Ihrem Host gemeldet werden. Bei älteren v2-Installationen überprüfen Sie das eingebundene Rails-Log, üblicherweise log/production.logim Greenlight-Installationsverzeichnis, oder prüfen Sie /usr/src/app/log/production.logden Container, falls dieser nicht eingebunden ist.

Suchen Sie nach der ersten Ausnahme zum Zeitpunkt der fehlgeschlagenen Anfrage, nicht nur nach der abschließenden 500-Fehlermeldung. Datenbankverbindungsfehler, Redis-Fehler, API-Anfragefehler, Zertifikatsvalidierungsfehler und Rails-Ausnahmen weisen auf unterschiedliche Lösungsansätze hin. Falls der Container beendet wurde, sind seine Protokolle möglicherweise weiterhin über [hier fehlende Information] verfügbar docker logs.

Schritt 2: Überprüfen Sie die Verbindung von Greenlight zu BigBlueButton

Wenn das Dashboard beim Laden von Räumen oder beim Starten eines Meetings nicht funktioniert, überprüfen Sie die von Greenlight verwendete BigBlueButton-URL und das zugehörige Shared Secret. In Version 3 enthält die Umgebungsdatei die BIGBLUEBUTTON_ENDPOINTentsprechenden BIGBLUEBUTTON_SECRETParameter. Der Endpunkt muss die API-URL Ihrer Bereitstellung sein, nicht ein erratener Host oder eine reine Browser-Meeting-URL. Wenn Sie einen Load Balancer wie Scalelite verwenden, nutzen Sie den für diese Konfiguration bereitgestellten Endpunkt und die zugehörigen Anmeldeinformationen.

Auf dem BigBlueButton-Server sudo bbb-conf --secretwerden die konfigurierte URL und das Geheimnis angezeigt. Vergleichen Sie diese vertraulich mit den Werten von Greenlight. Fügen Sie das Geheimnis nicht in ein Ticket, ein Shell-Protokoll oder einen öffentlichen Chat ein. Ein veraltetes Geheimnis nach einer Neuinstallation oder einem Austausch der Anmeldeinformationen kann dazu führen, dass API-Aufrufe fehlschlagen, selbst wenn der Dashboard-Container fehlerfrei funktioniert.

Führen Sie diesen Befehl auch sudo bbb-conf --checkauf dem BigBlueButton-Host aus. Er überprüft die BigBlueButton-Dienste und häufige Konfigurationsprobleme; er ersetzt jedoch nicht die Überprüfung der Greenlight-Protokolle. Befindet sich Greenlight auf einem separaten, eigenständigen Host, muss dieser Befehl auf dem BBB-Server ausgeführt werden, auf dem Greenlight bbb-confinstalliert ist.

Schritt 3: Datenbank, Redis und kürzlich erfolgte Aktualisierungen überprüfen

Die Beispielumgebung von Greenlight v3 definiert Datenbank- und Cache-Verbindungen mit `postgresql` DATABASE_URLund `redis` REDIS_URL. Stellen Sie sicher, dass die PostgreSQL- und Redis-Container ausgeführt werden und die Werte in der Anwendungsumgebung mit den Compose-Dienstnamen, Ports, dem Datenbanknamen und den Anmeldeinformationen übereinstimmen. Ein scheinbar fehlerfreier Greenlight-Container kann dennoch den Fehlercode 500 zurückgeben, wenn eine dieser Abhängigkeiten nicht erreichbar ist.

Wenn der Fehler nach einem Upgrade aufgetreten ist, vergleichen Sie das bereitgestellte Image-Tag, die Compose-Datei und die Umgebungsvariablen mit dem von Ihnen befolgten Release-Verfahren. Vermeiden Sie es, während der Diagnose in der Produktionsumgebung ein beliebiges Image zu verwenden oder das Datenbankschema manuell zu ändern. Sichern Sie zuerst die Datenbank und verwenden Sie dann den dokumentierten Greenlight-Upgrade-Prozess für Ihre Installation. Überprüfen Sie auch den Festplattenspeicher: Ein volles Volume kann PostgreSQL-Schreibvorgänge, Protokollschreibvorgänge oder Aktualisierungen des Asset-Speichers verhindern.

Schritt 4: Proxy-, Hostname- und Unterpfadeinstellungen überprüfen

Tritt der Fehler nur beim öffentlichen Hostnamen auf, überprüfen Sie den Pfad vom Browser über den Reverse-Proxy zu Greenlight. Stellen Sie sicher, dass der Proxy an den korrekten internen Port weiterleitet und die erwarteten Host- und Protokoll-Header beibehält. Testen Sie die Proxy-Konfiguration, bevor Sie Nginx neu laden sudo nginx -t, und überprüfen Sie anschließend das Proxy-Fehlerprotokoll zum entsprechenden Zeitpunkt.

Greenlight v3 erwartet standardmäßig, im Stammverzeichnis ausgeführt zu werden. Wird es unter einem anderen Pfad wie z. B. `/ /glvar/www /greenlight/` veröffentlicht RELATIVE_URL_ROOT, müssen die Regeln für die Reverse-Proxy-Verwaltung und die URL übereinstimmen. Laut offizieller Installationsanleitung erfordert eine Änderung des relativen Stammverzeichnisses eine Aktualisierung/Neukonfiguration während der Installation. Das Setzen einer Shell-Variable allein behebt keine bestehende, nicht übereinstimmende Bereitstellung. Eine solche Diskrepanz führt häufiger zu fehlerhaften Weiterleitungen oder Ressourcen, aber eine fehlgeschlagene Proxy-Anfrage kann sich auch als Anwendungsfehler äußern.

BigBlueButton dokumentiert einen spezifischen LAN-Fall: Erhalten nur einige Computer hinter einem Proxy den Fehler 500 und enthält das Greenlight-Protokoll entsprechende Einträge Error::Unsafe Host Error, überprüfen Sie, ob Windows so konfiguriert ist, dass der Proxy für lokale oder Intranet-Adressen umgangen wird. Dies ist ein Problem mit dem Client-Netzwerkpfad und kein Grund, die Host-Validierung global zu deaktivieren.

Schritt 5: Authentifizierungs- und E-Mail-Änderungen überprüfen

Tritt der Fehler 500 beim Anmelden auf, überprüfen Sie die kürzlich vorgenommenen Änderungen an den OpenID Connect-Einstellungen, den Callback-URLs oder dem Identitätsanbieter. Greenlight v3 verwendet Werte wie „“ OPENID_CONNECT_ISSUER, OPENID_CONNECT_CLIENT_ID„“ und OPENID_CONNECT_REDIRECT„“, wenn die externe Authentifizierung konfiguriert ist. Stellen Sie sicher, dass die Redirect-URL mit der öffentlichen Greenlight-URL übereinstimmt, einschließlich aller konfigurierten Unterpfade, und überprüfen Sie die Protokolle von Greenlight und des Identitätsanbieters auf denselben Zeitstempel.

Laut der Dokumentation von Greenlight v3 ist eine E-Mail-Adresse für grundlegende Plattformfunktionen erforderlich. Falls das Dashboard bei einer Einladung, Registrierung, einem Zurücksetzen des Passworts oder einer anderen E-Mail-Aktion nicht funktioniert, überprüfen Sie die SMTP-Verbindung und -Zugangsdaten, die TLS-Einstellungen und das Anwendungsprotokoll. Geben Sie SMTP-Zugangsdaten niemals weiter. Ein Fehler, der ausschließlich bei E-Mail-bezogenen Aktionen auftritt, deutet darauf hin, dass die E-Mail-Konfiguration überprüft werden sollte, bevor die Zugangsdaten der BigBlueButton-API geändert werden.

Starten Sie den Computer erst neu, nachdem Sie die wahrscheinliche Ursache identifiziert haben.

Sobald Sie ein bestätigtes Umgebungs- oder Proxy-Problem behoben haben, starten Sie den betroffenen Greenlight-Dienst mithilfe der Compose-Datei für diese Installation neu. Zum Beispiel aus dem v3-Installationsverzeichnis:

cd ~/greenlight-v3
sudo docker compose ps
sudo docker compose restart greenlight-v3

Compose-Dienstnamen können von Containernamen abweichen. Wenn der Neustartbefehl meldet, dass der Dienst unbekannt ist, überprüfen docker compose config --servicesund starten Sie den aufgelisteten Greenlight-Dienst neu oder verwenden Sie den dokumentierten Aktualisierungsbefehl der Bereitstellung. Vermeiden Sie einen Neustart von PostgreSQL oder das Entfernen von Volumes, es sei denn, die Protokolle weisen auf ein Abhängigkeitsproblem hin und Sie verfügen über einen Wiederherstellungsplan.

Überprüfen Sie die Fehlerbehebung und wissen Sie, wann Sie eskalieren müssen.

Wiederholen Sie die zuvor fehlgeschlagene Aktion und überprüfen Sie anschließend die Antwort im Browser und im Greenlight-Protokoll zum neuen Zeitstempel. Stellen Sie sicher, dass die Benutzer das Dashboard laden können, und starten Sie, falls der ursprüngliche Fehler ein Meeting betraf, ein Test-Meeting. Wenn der bbb-conf --checkTest erfolgreich ist, die Anwendung aber weiterhin den Fehlercode 500 zurückgibt, deutet dies auf Greenlight, seine Abhängigkeiten oder den Proxy als mögliche Fehlerursache hin.

Falls das Problem weiterhin besteht, geben Sie bitte die Greenlight-Version bzw. das Image-Tag, den Bereitstellungstyp, den betroffenen URL-Pfad, den Zeitpunkt des Fehlers, die relevante geschwärzte Ausnahme, den Containerstatus und die letzten Änderungen an. Geben Sie keine vollständigen Umgebungsdateien, API-Geheimnisse, Datenbankpasswörter, Benutzersitzungs-Cookies oder ungeschwärzte Protokolle weiter.

Die offizielle Interpretation von 500-Fehlern finden Sie im BigBlueButton-Leitfaden zur Fehlerbehebung. Die Installations- und Konfigurationsdokumentation für Greenlight v3 beschreibt das aktuelle Bereitstellungsmodell. Die Beispielumgebungsdatei für Greenlight v3 des Projekts listet die unterstützten Umgebungsvariablen auf. Greenlight v2 und v3 unterscheiden sich, verwenden Sie daher die Dokumentation, die zu Ihrer eingesetzten Version passt.