Исправлена ​​ошибка 500 Internal Server Error в панели управления BigBlueButton Greenlight.

Ошибка A 500 Internal Server Errorозначает сбой запроса на стороне сервера; она не указывает, какой именно компонент дал сбой. Для панели мониторинга BigBlueButton Greenlight начните с поиска сбойного запроса в журналах приложения Greenlight. В руководстве по устранению неполадок BigBlueButton говорится, что ошибка 500, скорее всего, является ошибкой Greenlight. Исключение полезно: если его видят только некоторые компьютеры в локальной сети, а в журнале сообщается об ошибке «Unsafe Host Error», возможно, проблема связана с настройками прокси-сервера браузера.

Greenlight v3 — это текущая документированная версия, использующая иную схему развертывания по сравнению со старой версией v2. Это руководство поможет вам определить вашу версию, собрать необходимые доказательства и проверить распространенные причины в безопасном порядке. Предполагается развертывание Greenlight на основе Docker. Используйте команды от имени администратора сервера и измените имя и путь контейнера, если ваша установка отличается.

Разберитесь, какой компонент возвращает ошибку 500.

Greenlight — это веб-приложение, используемое для входа в систему, управления комнатами и запуска встреч BigBlueButton. Обратный прокси-сервер, такой как Nginx, принимает запросы браузера и перенаправляет их в Greenlight. Затем Greenlight взаимодействует с API BigBlueButton и использует такие сервисы, как PostgreSQL и Redis. Ошибка 500 может возникнуть в Greenlight, прокси-сервере или зависимой системе; перезапуск медиасервисов BigBlueButton не устранит ошибку базы данных или приложения.

Сначала определите, какое действие вызывает ошибку: открытие панели управления, вход в систему, загрузка списка переговорных комнат или начало совещания. Запишите URL-адрес, приблизительное время, затронуты ли ошибки все пользователи, а также любые недавние изменения, такие как обновление, редактирование DNS, изменение прокси-сервера или смена учетных данных. Если главная страница загружается, но одно из действий возвращает ошибку 500, это сужает круг вопросов для расследования.

Прежде чем что-либо менять, подготовьтесь.

• Убедитесь, является ли образ bigbluebutton/greenlight:v3образом v2 или пользовательской сборкой. Не применяйте инструкции v2 к v3.
• Перед редактированием сохраните копию соответствующего файла Docker Compose и файла среды в безопасном месте. Они содержат учетные данные.
• Запишите метку времени ошибки и просмотрите только короткий промежуток времени вокруг нее. Перед тем как делиться логами, удалите пароли, токены доступа, секреты API, адреса электронной почты и ссылки на частные встречи.
• Не запускайте команды docker compose down -v, не удаляйте тома базы данных и не удаляйте хранилище Greenlight для «сброса» панели управления. Эти действия могут привести к удалению учетных записей, настроек или загруженных ресурсов.

Шаг 1: Проверьте запущенные контейнеры и перехватите исключение.

На хосте Docker выведите список контейнеров, связанных с Greenlight, а также их образы и статус:

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

В стандартной установке Greenlight v3 контейнер приложения обычно называется greenlight-v3`.`. Ознакомьтесь с его последними выводами примерно в момент сбоя:

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

Если в вашей установке используется Compose, запустите docker compose psего docker compose logs --since=15m --tail=200из каталога, содержащего файл Compose. В установке BigBlueButton файлы версии 3 могут храниться в каталоге ~/greenlight-v3; в автономных установках ситуация может отличаться. Используйте фактическое местоположение и имена контейнеров, указанные вашим хостом. Для более старых установок версии 2 проверьте смонтированный журнал Rails, обычно log/production.logнаходящийся в каталоге установки Greenlight, или проверьте /usr/src/app/log/production.logсодержимое контейнера, если он не смонтирован.

Ищите первое исключение в момент неудачного запроса, а не только последний ответ с кодом 500. Ошибки подключения к базе данных, ошибки Redis, сбои запросов API, ошибки проверки сертификатов и исключения Rails указывают на разные способы устранения проблемы. Если контейнер завершил работу, его журналы могут быть доступны через docker logs.

Шаг 2: Проверьте подключение Greenlight к BigBlueButton.

Если панель управления не работает при загрузке комнат или начале совещания, проверьте URL-адрес BigBlueButton и общий секретный ключ, используемые Greenlight. Для версии 3 файл среды включает в себя BIGBLUEBUTTON_ENDPOINTи BIGBLUEBUTTON_SECRET. Конечная точка должна быть URL-адресом API для вашего развертывания, а не предполагаемым хостом или URL-адресом совещания, доступным только в браузере. Если вы используете балансировщик нагрузки, такой как Scalelite, используйте конечную точку и учетные данные, предоставленные для этой настройки.

На сервере BigBlueButton sudo bbb-conf --secretотображается настроенный URL-адрес и секретный ключ. Сравните их в приватном режиме со значениями Greenlight. Не вставляйте секретный ключ в заявку, протокол командной строки или публичный чат. Устаревший секретный ключ после переустановки или смены учетных данных может привести к сбоям вызовов API, даже если контейнер панели управления работает исправно.

Также запустите эту команду sudo bbb-conf --checkна хосте BigBlueButton. Она проверяет службы BigBlueButton и распространенные проблемы конфигурации; она не заменяет проверку журналов Greenlight. Если Greenlight находится на отдельном автономном хосте, эту команду следует выполнять на сервере BBB, где bbb-confон установлен.

Шаг 3: Проверьте базу данных, Redis и последние обновления.

В примере среды Greenlight v3 подключения к базе данных и кэшу определяются с помощью параметров `<connection> DATABASE_URL` и `<catch>` REDIS_URL. Убедитесь, что контейнеры PostgreSQL и Redis запущены и что значения в среде приложения соответствуют именам служб Compose, портам, имени базы данных и учетным данным. Даже если контейнер Greenlight выглядит работоспособным, он может вернуть ошибку 500, если не может связаться с одной из этих зависимостей.

Если ошибка возникла после обновления, сравните развернутый тег образа, файл Compose и файл среды с процедурой выпуска, которую вы использовали. Избегайте загрузки произвольного образа или ручного изменения схемы базы данных при диагностике производственной среды. Сначала создайте резервную копию базы данных, а затем используйте описанный в документации процесс обновления Greenlight для вашей установки. Проверьте также свободное место на диске: заполненный том может препятствовать записи в PostgreSQL, записи журналов или обновлению хранилища ресурсов.

Шаг 4: Проверьте настройки прокси, имени хоста и подпути.

Если ошибка возникает только при использовании общедоступного имени хоста, проверьте путь от браузера через обратный прокси к Greenlight. Убедитесь, что прокси перенаправляет запрос на правильный внутренний порт и сохраняет ожидаемые заголовки хоста и протокола. Проверьте конфигурацию прокси перед перезагрузкой Nginx sudo nginx -t, а затем просмотрите журнал ошибок прокси в соответствующее время.

Greenlight v3 по умолчанию ожидает запуска по корневому пути. Если он опубликован по пути, например /gl, , его RELATIVE_URL_ROOTправила и правила обратного прокси должны совпадать. В официальном руководстве по установке говорится, что изменение относительного корневого URL-адреса требует обновления/переконфигурации в процессе установки; установка только переменной оболочки не исправляет несоответствие существующего развертывания. Несоответствие чаще приводит к неработающим перенаправлениям или ресурсам, но неудачный проксированный запрос может проявиться как ошибка приложения.

В документации BigBlueButton описан конкретный случай в локальной сети: если ошибку 500 получают только некоторые компьютеры за прокси-сервером, а в журнале Greenlight содержится Error::Unsafe Host Errorсообщение об ошибке, убедитесь, что в Windows настроен обход прокси-сервера для локальных или интранет-адресов. Это проблема сетевого пути клиента, а не причина для глобального отключения проверки хоста.

Шаг 5: Проверка изменений в аутентификации и адресе электронной почты.

Если ошибка 500 возникает во время входа в систему, проверьте последние изменения настроек OpenID Connect, URL-адресов обратного вызова или поставщика идентификации. Greenlight v3 использует такие значения, как OPENID_CONNECT_ISSUER, OPENID_CONNECT_CLIENT_ID, и OPENID_CONNECT_REDIRECTпри настройке внешней аутентификации. Убедитесь, что URL-адрес перенаправления совпадает с общедоступным URL-адресом Greenlight, включая любой настроенный подпуть, и просмотрите журналы Greenlight и поставщика идентификации на наличие одинаковой метки времени.

В документации Greenlight v3 указано, что для работы основных функций платформы требуется электронная почта. Если панель управления не работает во время отправки приглашения, регистрации, сброса пароля или другого действия с электронной почтой, проверьте подключение и учетные данные SMTP, настройки TLS и журнал приложения. Храните секретные данные SMTP в тайне. Сбой, ограниченный действиями, связанными с электронной почтой, указывает на необходимость проверки конфигурации почты, прежде чем изменять учетные данные API BigBlueButton.

Перезапускайте систему только после выявления вероятной причины.

После устранения подтвержденной проблемы с окружением или прокси-сервером перезапустите соответствующую службу Greenlight, используя файл Compose для этой установки. Например, из каталога установки версии 3:

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

Имена служб в Compose могут отличаться от имен контейнеров. Если команда перезапуска сообщает, что служба неизвестна, проверьте docker compose config --servicesи перезапустите указанную службу Greenlight или используйте описанную в документации команду обновления развертывания. Избегайте перезапуска PostgreSQL или удаления томов, если в журналах нет информации о проблемах с зависимостями и у вас нет плана восстановления.

Проверьте, устранена ли ошибка, и знайте, когда следует передать проблему на рассмотрение вышестоящему руководству.

Повторите то же самое действие, которое ранее завершилось неудачей, затем проверьте ответ в браузере и журнале Greenlight на новой временной метке. Убедитесь, что пользователи могут загрузить панель управления, и, если первоначальная ошибка была связана с совещанием, начните тестовое совещание. Если bbb-conf --checkпроверка пройдена успешно, но приложение по-прежнему возвращает ошибку 500, это указывает на Greenlight, его зависимости или прокси-сервер.

Если проблема не решена, укажите версию Greenlight или тег образа, тип развертывания, затронутый URL-адрес, время сбоя, соответствующее скрытое исключение, статус контейнера и последние изменения. Не предоставляйте полные файлы среды, секреты API, пароли баз данных, файлы cookie пользовательских сессий или неотредактированные журналы.

Для получения официальной интерпретации ошибок 500 используйте руководство по устранению неполадок BigBlueButton, а для текущей модели развертывания v3 — документацию по установке и настройке Greenlight v3 . В файле примера среды Greenlight v3 проекта перечислены поддерживаемые переменные среды. Greenlight v2 и v3 различаются, поэтому используйте документацию, соответствующую вашей развернутой версии.