Napraw błąd wewnętrzny serwera 500 w panelu BigBlueButton Greenlight

A 500 Internal Server Erroroznacza, że ​​żądanie po stronie serwera zakończyło się niepowodzeniem; nie identyfikuje ono komponentu, który uległ awarii. W przypadku pulpitu nawigacyjnego BigBlueButton Greenlight, zacznij od znalezienia nieudanego żądania w dziennikach aplikacji Greenlight. Przewodnik rozwiązywania problemów BigBlueButton podaje, że błąd 500 najprawdopodobniej oznacza błąd Greenlight. Wyjątek jest przydatny: jeśli tylko niektóre komputery w sieci lokalnej go widzą, a dziennik zgłasza „Niebezpieczny błąd hosta”, problem może leżeć w ustawieniu proxy przeglądarki.

Greenlight v3 to aktualna udokumentowana wersja, która wykorzystuje inny układ wdrożenia niż starsza wersja v2. Ten przewodnik pomoże Ci zidentyfikować wersję, zebrać odpowiednie dowody i sprawdzić typowe przyczyny w bezpiecznej kolejności. Zakłada wdrożenie Greenlight oparte na Dockerze. Użyj poleceń jako administrator serwera i dostosuj nazwę i ścieżkę kontenera, jeśli instalacja różni się od poprzedniej.

Zrozum, który komponent zwraca 500

Greenlight to aplikacja internetowa służąca do logowania, zarządzania pokojami i rozpoczynania spotkań w BigBlueButton. Odwrotny serwer proxy, taki jak Nginx, odbiera żądania przeglądarki i przekazuje je do Greenlight. Następnie Greenlight komunikuje się z API BigBlueButton i korzysta z usług takich jak PostgreSQL i Redis. Błąd 500 może pochodzić z Greenlight, serwera proxy lub zależności; ponowne uruchomienie usług multimedialnych BigBlueButton nie naprawi wyjątku bazy danych ani aplikacji.

Najpierw zanotuj, jaka akcja powoduje błąd: otwarcie pulpitu nawigacyjnego, zalogowanie się, załadowanie listy pokoi lub rozpoczęcie spotkania. Zapisz ścieżkę URL, przybliżony czas, informację, czy dotyczy to wszystkich użytkowników, oraz wszelkie ostatnie zmiany, takie jak aktualizacja, edycja DNS, zmiana serwera proxy lub rotacja danych uwierzytelniających. Jeśli strona główna się załaduje, ale jedna akcja zwróci 500, zawęża to zakres żądania do zbadania.

Przygotuj się przed zmianą czegokolwiek

• Sprawdź, czy obraz to bigbluebutton/greenlight:v3, obraz v2, czy kompilacja niestandardowa. Nie stosuj instrukcji v2 do v3.
• Przed edycją przechowuj kopię odpowiedniego pliku Docker Compose i pliku środowiska w bezpiecznym miejscu. Zawierają one dane uwierzytelniające.
• Zapisz znacznik czasu błędu i sprawdź tylko krótkie okno dziennika wokół niego. Usuń hasła, tokeny dostępu, tajne klucze API, adresy e-mail i linki do prywatnych spotkań przed udostępnieniem dzienników.
• Nie uruchamiaj docker compose down -v, nie usuwaj woluminów bazy danych ani nie usuwaj pamięci masowej Greenlight w celu „zresetowania” pulpitu nawigacyjnego. Takie działania mogą spowodować utratę kont, ustawień lub przesłanych zasobów.

Krok 1: Sprawdź działające kontenery i przechwyć wyjątek

Na hoście Docker wyświetl listę kontenerów powiązanych z Greenlight, ich obrazy i status:

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

W przypadku standardowej instalacji Greenlight v3 kontener aplikacji nosi zazwyczaj nazwę greenlight-v3. Przeczytaj jego ostatnie dane wyjściowe z okresu awarii:

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

Jeśli Twoja instalacja korzysta z Compose, uruchom polecenie docker compose psi docker compose logs --since=15m --tail=200z katalogu zawierającego plik Compose. Instalacja BigBlueButton może przechowywać pliki v3 w katalogu ~/greenlight-v3; instalacje autonomiczne mogą się różnić. Użyj rzeczywistych nazw lokalizacji i kontenerów zgłoszonych przez hosta. W przypadku starszych instalacji v2 sprawdź zamontowany dziennik Rails, zazwyczaj log/production.logw katalogu instalacyjnym Greenlight, lub sprawdź /usr/src/app/log/production.logw kontenerze, czy nie jest zamontowany.

Szukaj pierwszego wyjątku w momencie nieudanego żądania, a nie tylko ostatniej odpowiedzi 500. Błędy połączenia z bazą danych, błędy Redis, błędy żądań API, błędy walidacji certyfikatów i wyjątki Rails wskazują na różne rozwiązania. Jeśli kontener został zamknięty, jego logi mogą być nadal dostępne poprzez docker logs.

Krok 2: Sprawdź połączenie Greenlight z BigBlueButton

W przypadku awarii pulpitu nawigacyjnego podczas ładowania pokoi lub rozpoczynania spotkania, należy zweryfikować adres URL BigBlueButton i współdzielony klucz tajny używany przez Greenlight. W wersji 3 plik środowiska zawiera BIGBLUEBUTTON_ENDPOINTi BIGBLUEBUTTON_SECRET. Punktem końcowym musi być adres URL interfejsu API dla wdrożenia, a nie domyślna nazwa hosta lub adres URL spotkania dostępny tylko w przeglądarce. Jeśli korzystasz z modułu równoważenia obciążenia, takiego jak Scalelite, użyj punktu końcowego i poświadczeń dostarczonych dla tej konfiguracji.

Na serwerze BigBlueButton sudo bbb-conf --secretwyświetla skonfigurowany adres URL i tajny klucz. Porównaj je prywatnie z wartościami Greenlight. Nie wklejaj tajnego klucza do zgłoszenia, transkryptu powłoki ani czatu publicznego. Nieaktualny tajny klucz po ponownej instalacji lub rotacji danych uwierzytelniających może spowodować niepowodzenie wywołań API, nawet gdy kontener pulpitu nawigacyjnego jest sprawny.

Uruchom również sudo bbb-conf --checkna hoście BigBlueButton. Sprawdza usługi BigBlueButton i typowe problemy z konfiguracją; nie zastępuje jednak sprawdzania logów Greenlight. Jeśli Greenlight znajduje się na osobnym, samodzielnym hoście, to polecenie należy wykonać na serwerze BBB, na którym bbb-confjest zainstalowany.

Krok 3: Sprawdź bazę danych, Redis i ostatnie aktualizacje

Przykładowe środowisko Greenlight v3 definiuje połączenia z bazą danych i pamięcią podręczną za pomocą DATABASE_URLoraz REDIS_URL. Sprawdź, czy kontenery PostgreSQL i Redis są uruchomione oraz czy wartości w środowisku aplikacji są zgodne z nazwami usług Compose, portami, nazwą bazy danych i danymi uwierzytelniającymi. Prawidłowo wyglądający kontener Greenlight może nadal zwracać 500, jeśli nie może dotrzeć do jednej z tych zależności.

Jeśli błąd pojawił się po aktualizacji, porównaj wdrożony znacznik obrazu, plik Compose i plik środowiska z zastosowaną procedurą wydania. Unikaj pobierania dowolnego obrazu lub ręcznej zmiany schematu bazy danych podczas diagnozowania środowiska produkcyjnego. Najpierw utwórz kopię zapasową bazy danych, a następnie skorzystaj z udokumentowanego procesu aktualizacji Greenlight dla swojej instalacji. Sprawdź również ilość miejsca na dysku: pełny wolumin może uniemożliwić zapis do PostgreSQL, zapis do logów lub aktualizację zasobów.

Krok 4: Sprawdź ustawienia serwera proxy, nazwy hosta i ścieżki podrzędnej

Jeśli błąd pojawia się tylko poprzez publiczną nazwę hosta, sprawdź ścieżkę z przeglądarki przez odwrotne proxy do Greenlight. Upewnij się, że proxy przekierowuje do prawidłowego portu wewnętrznego i zachowuje oczekiwane nagłówki hosta i protokołu. Przetestuj konfigurację proxy przed ponownym załadowaniem Nginx za pomocą sudo nginx -t, a następnie sprawdź dziennik błędów proxy w pasującym znaczniku czasu.

Greenlight v3 domyślnie uruchamia się w ścieżce głównej. Jeśli jest publikowany w ścieżce takiej jak /gl, jego RELATIVE_URL_ROOTreguły i reguły odwrotnego proxy muszą być zgodne. Oficjalny podręcznik instalacji mówi, że zmiana względnego adresu URL głównego wymaga aktualizacji/rekonfiguracji za pomocą procedury instalacji; samo ustawienie zmiennej powłoki nie naprawia niezgodnego, istniejącego wdrożenia. Niezgodność częściej powoduje uszkodzone przekierowania lub zasoby, ale nieudane żądanie proxy może ujawnić się jako błąd aplikacji.

BigBlueButton dokumentuje konkretny przypadek sieci LAN: jeśli tylko niektóre komputery za serwerem proxy otrzymują 500, a dziennik Greenlight zawiera Error::Unsafe Host Error, sprawdź, czy system Windows jest skonfigurowany tak, aby pomijał serwer proxy dla adresów lokalnych lub intranetowych. Jest to problem ze ścieżką sieciową klienta, a nie powód do globalnego wyłączenia walidacji hosta.

Krok 5: Przejrzyj uwierzytelnianie i zmiany w adresie e-mail

Jeśli błąd 500 wystąpi podczas logowania, sprawdź ostatnie zmiany w ustawieniach OpenID Connect, adresach URL wywołania zwrotnego lub dostawcy tożsamości. Greenlight v3 używa wartości takich jak OPENID_CONNECT_ISSUER, OPENID_CONNECT_CLIENT_IDi , OPENID_CONNECT_REDIRECTgdy skonfigurowane jest uwierzytelnianie zewnętrzne. Sprawdź, czy adres URL przekierowania jest zgodny z publicznym adresem URL Greenlight, w tym ze wszystkimi skonfigurowanymi ścieżkami podrzędnymi, i sprawdź dzienniki Greenlight i dostawcy tożsamości pod kątem tego samego znacznika czasu.

Dokumentacja Greenlight v3 informuje, że do korzystania z podstawowych funkcji platformy wymagany jest adres e-mail. Jeśli panel nie działa podczas wysyłania zaproszenia, rejestracji, resetowania hasła lub innej czynności e-mail, sprawdź łączność i dane uwierzytelniające SMTP, ustawienia TLS oraz dziennik aplikacji. Zachowaj poufność poufnych danych SMTP. Awaria ograniczona do działań związanych z pocztą elektroniczną jest sygnałem do sprawdzenia konfiguracji poczty przed zmianą danych uwierzytelniających API BigBlueButton.

Uruchom ponownie dopiero po zidentyfikowaniu prawdopodobnej przyczyny

Po rozwiązaniu potwierdzonego problemu ze środowiskiem lub serwerem proxy, uruchom ponownie usługę Greenlight, używając pliku Compose dla tej instalacji. Na przykład z katalogu instalacyjnego v3:

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

Nazwy usług Compose mogą różnić się od nazw kontenerów. Jeśli polecenie restartu wskazuje, że usługa jest nieznana, sprawdź docker compose config --servicesi uruchom ponownie wymienioną usługę Greenlight lub użyj udokumentowanego polecenia aktualizacji wdrożenia. Unikaj restartowania PostgreSQL lub usuwania woluminów, chyba że logi wskazują na problem z zależnościami i masz plan odzyskiwania.

Sprawdź poprawkę i wiedz, kiedy należy ją eskalować

Powtórz dokładnie tę samą czynność, która poprzednio się nie powiodła, a następnie sprawdź odpowiedź w przeglądarce i dzienniku Greenlight z nowym znacznikiem czasu. Upewnij się, że użytkownicy mogą załadować pulpit nawigacyjny i, jeśli pierwotna awaria dotyczyła spotkania, rozpocznij spotkanie testowe. Jeśli bbb-conf --checkbłąd się powiedzie, ale aplikacja nadal zwraca 500, oznacza to, że dochodzenie ponownie dotyczy Greenlight, jego zależności lub serwera proxy.

Jeśli problem pozostaje nierozwiązany, podaj wersję Greenlight lub tag obrazu, typ wdrożenia, ścieżkę URL, której dotyczy problem, czas wystąpienia awarii, odpowiedni usunięty wyjątek, status kontenera i ostatnie zmiany. Nie udostępniaj pełnych plików środowiska, sekretów API, haseł do baz danych, plików cookie sesji użytkownika ani nieusuniętych dzienników.

Skorzystaj z przewodnika rozwiązywania problemów BigBlueButton , aby uzyskać oficjalną interpretację błędów 500 oraz dokumentacji instalacji i konfiguracji Greenlight v3 dla bieżącego modelu wdrożenia v3. Przykładowy plik środowiska Greenlight v3 projektu zawiera listę obsługiwanych zmiennych środowiskowych. Greenlight v2 i v3 różnią się, dlatego należy korzystać z dokumentacji odpowiadającej wdrożonej wersji.