Remediați eroarea internă a serverului BigBlueButton Greenlight Dashboard 500

A 500 Internal Server Errorînseamnă că o solicitare pe partea de server a eșuat; nu identifică ce componentă a eșuat. Pentru un tablou de bord BigBlueButton Greenlight, începeți prin a găsi solicitarea eșuată în jurnalele aplicației Greenlight. Ghidul de depanare BigBlueButton spune că o eroare 500 este cel mai probabil o eroare Greenlight. Excepția este utilă: dacă doar unele computere dintr-o rețea locală o văd și jurnalul raportează o „Eroare gazdă nesigură”, poate fi implicată o setare proxy a browserului.

Greenlight v3 este versiunea documentată actuală și folosește un aspect de implementare diferit față de versiunea veche v2. Acest ghid vă ajută să identificați versiunea dvs., să colectați dovezile corecte și să verificați cauzele comune într-o ordine sigură. Presupune o implementare Greenlight bazată pe Docker. Folosiți comenzi ca administrator de server și adaptați numele și calea containerului dacă instalarea dvs. diferă.

Înțelegeți care componentă returnează 500

Greenlight este aplicația web utilizată pentru conectare, gestionarea sălilor și inițierea întâlnirilor BigBlueButton. Un proxy invers, cum ar fi Nginx, primește cereri din browser și le redirecționează către Greenlight. Greenlight comunică apoi cu API-ul BigBlueButton și se bazează pe servicii precum PostgreSQL și Redis. O eroare 500 poate proveni din Greenlight, un proxy sau o dependență; repornirea serviciilor media BigBlueButton nu va remedia o excepție a bazei de date sau a aplicației.

Mai întâi, notați ce acțiune declanșează eroarea: deschiderea tabloului de bord, conectarea, încărcarea unei liste de săli sau începerea unei întâlniri. Înregistrați calea URL, ora aproximativă, dacă fiecare utilizator este afectat și orice modificare recentă, cum ar fi o actualizare, o modificare DNS, o modificare a proxy-ului sau o rotație a acreditărilor. Dacă pagina principală se încarcă doar o acțiune care returnează 500, aceasta restrânge solicitarea de investigare.

Pregătește-te înainte de a schimba ceva

• Confirmați dacă imaginea este bigbluebutton/greenlight:v3o imagine v2 sau o compilare personalizată. Nu aplicați instrucțiuni v2 la v3.
• Păstrați o copie a fișierului Docker Compose și a fișierului de mediu relevante într-o locație sigură înainte de a le edita. Acestea conțin acreditări.
• Înregistrați marcajul temporal al erorii și inspectați doar o scurtă fereastră de jurnal din jurul acesteia. Ștergeți parolele, token-urile de acces, secretele API, adresele de e-mail și link-urile către întâlniri private înainte de a partaja jurnalele.
• Nu rulați docker compose down -v, nu eliminați volumele bazei de date și nu ștergeți spațiul de stocare Greenlight pentru a „reseta” tabloul de bord. Aceste acțiuni pot distruge conturi, setări sau resurse încărcate.

Pasul 1: Verificați containerele care rulează și capturați excepția

Pe gazda Docker, enumerați containerele legate de Greenlight, imaginile și starea acestora:

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

Pentru instalarea standard Greenlight v3, containerul aplicației este denumit în mod obișnuit greenlight-v3. Citiți rezultatul său recent în momentul eșecului:

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

Dacă instalarea folosește Compose, rulați comenzile docker compose psși docker compose logs --since=15m --tail=200din directorul care conține fișierul Compose. Instalarea BigBlueButton poate păstra fișierele v3 sub ~/greenlight-v3; instalările independente pot diferi. Folosiți locația reală și numele containerelor raportate de gazdă. Pentru instalările v2 mai vechi, verificați jurnalul Rails montat, de obicei log/production.logîn directorul de instalare Greenlight, sau verificați /usr/src/app/log/production.logîn container dacă acesta nu este montat.

Căutați prima excepție în momentul solicitării eșuate, nu doar răspunsul final cu numărul 500. Erorile de conectare la baza de date, erorile Redis, eșecurile solicitărilor API, erorile de validare a certificatelor și excepțiile Rails indică alte remedieri. Dacă containerul s-a închis, jurnalele sale pot fi încă disponibile prin docker logs.

Pasul 2: Verificați conexiunea Greenlight la BigBlueButton

Când tabloul de bord eșuează în timpul încărcării sălilor sau al pornirii unei întâlniri, verificați adresa URL BigBlueButton și secretul partajat utilizat de Greenlight. Pentru v3, fișierul de mediu include BIGBLUEBUTTON_ENDPOINTși BIGBLUEBUTTON_SECRET. Punctul final trebuie să fie adresa URL API pentru implementarea dvs., nu o gazdă ghicită sau o adresă URL a întâlnirii disponibile exclusiv în browser. Dacă utilizați un echilibrator de încărcare, cum ar fi Scalelite, utilizați punctul final și acreditările furnizate pentru configurarea respectivă.

Pe serverul BigBlueButton, sudo bbb-conf --secretse afișează adresa URL configurată și secretul. Comparați-le în mod privat cu valorile Greenlight. Nu lipiți secretul într-un tichet, o transcriere shell sau un chat public. Un secret învechit după o reinstalare sau o rotație a acreditărilor poate cauza eșecul apelurilor API chiar dacă containerul tabloului de bord este funcțional.

De asemenea, rulează sudo bbb-conf --checkpe gazda BigBlueButton. Verifică serviciile BigBlueButton și problemele comune de configurare; nu înlocuiește inspectarea jurnalelor Greenlight. Dacă Greenlight se află pe o gazdă independentă separată, această comandă aparține serverului BBB unde bbb-confeste instalat.

Pasul 3: Verificați baza de date, Redis și actualizările recente

Mediul de exemplu Greenlight v3 definește conexiunile la baza de date și la memoria cache cu DATABASE_URLși REDIS_URL. Confirmați că containerele PostgreSQL și Redis rulează și că valorile din mediul aplicației corespund numelor serviciilor Compose, porturilor, numelui bazei de date și acreditărilor. Un container Greenlight cu aspect sănătos poate totuși returna 500 dacă nu poate accesa una dintre aceste dependențe.

Dacă eroarea a început după o actualizare, comparați eticheta imaginii implementate, fișierul Compose și fișierul de mediu cu procedura de lansare pe care ați urmat-o. Evitați extragerea unei imagini arbitrare sau modificarea manuală a schemei bazei de date în timp ce diagnosticați producția. Faceți mai întâi o copie de rezervă a bazei de date, apoi utilizați procesul de actualizare Greenlight documentat pentru instalare. Verificați și spațiul pe disc: un volum complet poate împiedica scrierile PostgreSQL, scrierile în jurnal sau actualizările spațiului de stocare a resurselor.

Pasul 4: Verificați setările proxy, nume de gazdă și subcale

Dacă eroarea apare doar prin numele public de gazdă, verificați calea de la browser prin proxy-ul invers către Greenlight. Confirmați că proxy-ul redirecționează către portul intern corect și păstrează anteturile de gazdă și protocol așteptate. Testați configurația proxy-ului înainte de a reîncărca Nginx cu sudo nginx -t, apoi inspectați jurnalul de erori proxy la marcajul de timp corespunzător.

Greenlight v3 se așteaptă să ruleze în mod implicit la calea rădăcină. Dacă este publicată sub o cale precum /gl, RELATIVE_URL_ROOTregulile sale și ale reverse-proxy trebuie să fie identice. Ghidul oficial de instalare precizează că o modificare relativă a URL-ului rădăcină necesită o actualizare/reconfigurare prin procedura de instalare; setarea unei variabile shell în sine nu remediază o implementare existentă nepotrivită. O nepotrivire cauzează cel mai adesea redirecționări sau resurse defecte, dar o solicitare proxy eșuată se poate expune ca o eroare de aplicație.

BigBlueButton documentează un caz specific de rețea locală: dacă doar unele computere din spatele unui proxy primesc codul 500 și jurnalul Greenlight conține [numele codului] Error::Unsafe Host Error, verificați dacă Windows este configurat să ocolească proxy-ul pentru adresele locale sau de intranet. Aceasta este o problemă a căii de rețea a clientului, nu un motiv pentru a dezactiva validarea gazdei la nivel global.

Pasul 5: Verificați modificările de autentificare și de adresă de e-mail

Dacă apare eroarea 500 în timpul conectării, verificați modificările recente aduse setărilor OpenID Connect, adreselor URL de apel invers sau furnizorului de identitate. Greenlight v3 utilizează valori precum OPENID_CONNECT_ISSUER, OPENID_CONNECT_CLIENT_ID, și OPENID_CONNECT_REDIRECTatunci când este configurată autentificarea externă. Confirmați că adresa URL de redirecționare se potrivește cu adresa URL publică Greenlight, inclusiv orice subcale configurată, și examinați jurnalele Greenlight și cele ale furnizorului de identitate pentru aceeași marcaj temporal.

Documentația Greenlight v3 precizează că adresa de e-mail este necesară pentru funcțiile de bază ale platformei. Dacă tabloul de bord eșuează în timpul unei invitații, înscrierii, resetării parolei sau a altei acțiuni prin e-mail, verificați conectivitatea și acreditările SMTP, setările TLS și jurnalul aplicației. Păstrați secretele SMTP private. O eroare limitată la acțiuni legate de e-mail este un indiciu pentru a investiga configurația e-mailului înainte de a modifica acreditările API BigBlueButton.

Reporniți numai după identificarea cauzei probabile

După ce corectați o problemă confirmată de mediu sau proxy, reporniți serviciul Greenlight afectat utilizând fișierul Compose pentru instalarea respectivă. De exemplu, din directorul de instalare v3:

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

Numele serviciilor de compunere pot diferi de numele containerelor. Dacă comanda de repornire indică faptul că serviciul este necunoscut, inspectați docker compose config --servicesși reporniți serviciul Greenlight listat sau utilizați comanda de actualizare documentată a implementării. Evitați repornirea PostgreSQL sau eliminarea volumelor, cu excepția cazului în care jurnalele arată o problemă de dependență și aveți un plan de recuperare.

Verificați remedierea și știți când să escaladați

Repetați exact acțiunea care a eșuat anterior, apoi verificați răspunsul în browser și în jurnalul Greenlight la noul timestamp. Confirmați că utilizatorii pot încărca tabloul de bord și, dacă eroarea inițială a implicat o întâlnire, începeți o întâlnire de test. Dacă bbb-conf --checkreușește, dar aplicația returnează în continuare 500, aceasta îndreaptă investigația înapoi către Greenlight, dependențele sale sau proxy-ul.

Dacă problema persistă, furnizați versiunea Greenlight sau eticheta imaginii, tipul de implementare, calea URL afectată, ora erorii, excepția redactată relevantă, starea containerului și modificările recente. Nu partajați fișiere de mediu complete, secrete API, parole de bază de date, cookie-uri de sesiune utilizator sau jurnalele needitate.

Folosește ghidul de depanare BigBlueButton pentru interpretarea oficială a erorilor 500 și documentația de instalare și configurare Greenlight v3 pentru modelul actual de implementare v3. Fișierul de mediu exemplu Greenlight v3 al proiectului listează variabilele de mediu acceptate. Greenlight v2 și v3 diferă, așadar folosește documentația care corespunde versiunii implementate.