Документация Tribly → Администрирование сервера

Администрирование сервера

Раздел «Администрирование» открывается тому, у кого есть хотя бы одно административное право. Каждый инструмент внутри требует своего права: список пользователей открывает право «Управление пользователями», роли — право «Управление ролями» (см. «Роли и права»).

Разделы админ-панели

Раздел	Что позволяет	Каким правом открывается
Статистика и ресурсы	Смотреть общую статистику системы и текущую нагрузку на сервер	Право смотреть ресурсы сервера
Пользователи	Заводить людей, блокировать и разблокировать, удалять, сбрасывать пароль, снимать чужую двухфакторную защиту, управлять доверенными устройствами входа	Право управлять пользователями
Роли	Создавать и настраивать роли, назначать их людям	Право управлять ролями
Каналы	Архивировать, восстанавливать и удалять любые каналы, массово очищать сообщения	Только владелец
Гости	Создавать и удалять гостевые учётные записи, обновлять их ссылки для входа	Право управлять гостями
Стикеры	Загружать и удалять стикерпаки	Право управлять стикерами
ИИ-бот	Настраивать и проверять ИИ-бота в чатах	Право настраивать ИИ
ИИ-ассистент	Модель, озвучка и распознавание речи личного ассистента	Право настраивать ассистента
Хранилище S3	Подключить своё объектное хранилище	Право оптимизировать сервер
Настройки	Общие настройки системы (см. ниже)	Право управлять пользователями; часть настроек — только владелец
Обновление сервера	Смотреть установленную и доступную версии, обновлять сервер кнопкой	Только владелец

Обновление сервера

Раздел показывает установленную версию и последнюю выпущенную — о новых выпусках сервер узнаёт сам.

Кнопка «Обновить сейчас» запускает обновление целиком: сервер скачивает новые образы и комплект приложений для пользователей, сверяет контрольные суммы и переходит на новую версию, когда всё скачано. Переписка, файлы и настройки остаются на месте; мессенджер недоступен минуту-две, пока поднимается новая версия. Незавершённая загрузка оставляет сервер на прежней версии и работающим.

Там же виден ход работы и журнал обновления с причиной, если что-то не удалось. Обновляет сервер владелец системы.

Сервер хранит комплект приложений текущей и одной предыдущей версии; более ранние удаляются сами.

Приложения на компьютерах и телефонах обновляются из официального выпуска разработчика. Второй кнопкой на том же экране приложение скачивается с вашего сервера — этим путём обновляются там, где внешние адреса закрыты.

Та же работа выполняется командой ./update.sh в папке установки — например, при обновлении с машины сервера или до конкретной версии: ./update.sh 1.3.0.

Блокировка и удаление пользователей

Блокировка обратима. Учётная запись остаётся в системе, вход закрывается до разблокировки.
Удаление закрывает доступ навсегда, а учётная запись остаётся ради целостности истории: прежние сообщения человека показываются как сообщения «Удалённого пользователя».
И блокировка, и удаление немедленно завершают все сессии человека — он сразу выходит из системы на всех устройствах.

Служебные боты мессенджера работают постоянно.

Общие настройки

Настройки меняются прямо в админ-панели и применяются сразу, без перезапуска.

Самостоятельная регистрация:

открытая регистрация автоматически закрывается сразу после того, как зарегистрировался владелец системы;
при необходимости администратор снова открывает её здесь же — например, чтобы завести сразу много людей, — а потом закрывает;
при закрытой регистрации вход открыт только заведённым учётным записям, а кнопка «Регистрация» появляется на экране входа вместе с её открытием.

Только владелец меняет три настройки — они видны ему одному, и сервер принимает правку только от него:

Адрес сервера — по нему строятся ссылки: приглашения, публичные ссылки, push-уведомления.
Язык по умолчанию — на нём видят интерфейс те, кто своего языка ещё не выбрал, и на нём же показываются экраны входа и регистрации. Личный выбор человека остаётся за ним. На этом же языке приходят ошибки от сервера.
Вход через GitLab — кнопка «Войти через GitLab» на экране входа. Требует ключей GitLab, заданных при развёртывании.

Наблюдение за сервером: логи, метрики, трассировки

Свои логи сервер всегда пишет к себе (docker compose logs). Дополнительно их можно отправлять во внешнюю систему наблюдения — вместе с метриками и трассировками запросов. Об этом спрашивает установщик при развёртывании: подойдёт Watchgoose или любой другой приёмник по протоколу OTLP (Grafana, Jaeger, коллектор OpenTelemetry).

Пока адрес приёмника пуст, телеметрия никуда не отправляется.

Что настраивается при установке (и потом правится в .env с перезапуском сервера):

Значение	Что задаёт
Адрес приёмника	`host:port` OTel-коллектора. Приёмник на этой же машине указывают как `host.docker.internal:<порт>` — из контейнера его loopback недостижим
Токен приёма	Ключ роли ingest. Без него приёмник отвечает 401, и не доходит ничего
Метка контура	prod / stage / dev — чтобы записи разных серверов не смешивались
Доля трассируемых запросов	0..1. На живом трафике — сотые доли: единица это гигабайты в сутки
TLS	Приёмник за https или в своём контуре без TLS

Отправлять надо в коллектор приёмника: он раскладывает сигналы по местам (логи, трассы, метрики). При записи мимо него часть данных теряется молча.

Уходят технические записи: тексты логов, длительности запросов и счётчики. Приёмник держите свой или у того, кому доверяете.

Защита от подбора пароля

Против подбора пароля система считает неудачные попытки входа и после серии ошибок берёт паузу. Считаются только ошибки, поэтому обычная работа сотрудников идёт как всегда. Тонкую настройку этой защиты выполняет системный администратор при развёртывании.

Порты, открытые снаружи

Сервер доступен людям через эти порты. Всё остальное — базы, хранилище, поиск — слушает только сам компьютер.

Порт	Протокол	Зачем	Обязателен
80	TCP	Перенаправление на HTTPS и проверка при выпуске сертификата	Да
443	TCP	Собственно работа: приложение, веб-версия, файлы	Да
443	UDP	Протокол HTTP/3	Нет
8189	UDP	Эфир вебинара	Да
3478	UDP и TCP	Реле звонков	Да
49160–50160	UDP	Потоки, идущие через реле	Да

Порты звонков обязаны быть доступны напрямую, минуя веб-прокси. В брандмауэре самой машины их открывает установщик; в панели хостера (облачный брандмауэр) их открывает владелец. Номера меняются настройками SFU_UDP_PORT, TURN_PORT, TURN_MIN_PORT и TURN_MAX_PORT — открывать тогда нужно новые.

Реле звонков

Звонок один на один и групповой идёт напрямую между собеседниками, сервер лишь сводит их. Из сотовой сети, корпоративной сети и через часть VPN прямой путь закрыт — такие разговоры идут через реле. Без реле собеседники видят друг друга в списке участников и слышат тишину.

Реле поднимается вместе с сервером. Ключи к нему временные: каждому приложению сервер выписывает свой ключ на срок TURN_CRED_TTL_HOURS (по умолчанию 24 часа) из секрета TURN_SECRET, который установщик создаёт сам.

Проверка. Сервер опрашивает реле при старте и раз в 10 минут; отказ попадает в журнал сервера с причиной. Состояние видно в «Настройках сервера» на карточке «Звонки: реле»: отвечает, не отвечает, не настроено или внешнее; там же порты и кнопка «Проверить». Приложение при сорвавшемся соединении называет причину: «нет реле», «реле не отвечает», «общий внешний адрес».

Вместимость. Порт из диапазона занимает каждое соединение каждого участника: вдвоём — два порта, в группе на десятерых — до девяноста. Тысячи портов хватает примерно на десяток таких групп одновременно. Диапазон расширяется настройками TURN_MIN_PORT и TURN_MAX_PORT; тот же диапазон открывается в брандмауэре и в панели хостера.

Реле на другой машине. Когда сервер стоит за прокси (например, за границей, а люди ходят к нему через российский прокси), реле ставится там, куда приложения достучатся напрямую: трафик реле идёт мимо прокси. На ту машину копируются relay-setup.sh и docker-compose.relay.yml из комплекта и запускается sudo ./relay-setup.sh --external-ip <IP> — секрет он создаёт и печатает. Затем в .env сервера задаются TURN_HOST (домен или IP той машины), TURN_SECRET (тот же секрет) и TURN_EXTERNAL=1, после чего выполняется sudo ./update.sh. При TURN_EXTERNAL=1 работает только внешнее реле, и карточка «Звонки: реле» показывает «внешнее».

Сервер на домашнем компьютере

Требования те же, что и к арендованному серверу.

Публичный (белый) IP-адрес. За общим адресом провайдера (когда один адрес на многих абонентов) сервер снаружи недоступен — белый IP заказывается у провайдера, обычно за небольшую доплату.
Проброс портов из таблицы выше на домашний компьютер в настройках роутера.
Доменное имя, направленное на этот адрес — на него выпускается сертификат.
Если адрес меняется — динамический DNS: домен сам следует за новым адресом.

TLS-сертификат: выпуск, продление и отказы

Обычно вмешиваться не нужно: при первом запуске сервер сам получает сертификат Let's Encrypt и потом сам продлевает. Для этого нужны домен, направленный на ваш адрес, и открытый порт 80 — по нему проходит проверка владения доменом. Сертификат выпускается именно на доменное имя.

Почему сертификат может не выпуститься:

Провайдер закрыл порт 80 (частая практика на домашних тарифах) — проверка по HTTP не пройдёт. Варианты: попросить провайдера открыть порт, перенести сервер на арендованный, либо пустить трафик через туннель со стороннего адреса.
Адрес серый, не белый — проверка не дойдёт вовсе. Нужен белый IP.
Домен ещё не разошёлся по DNS — подождите и перезапустите: сервер повторит попытку сам.
Локальная установка без домена — сервер поднимает собственный сертификат. Работать будет, но браузер покажет предупреждение: такой режим годится для проверки, а людям сервер выдают с доменом и настоящим сертификатом.

Прогноз остатка средств

В «Статистике сервера» первой строкой показана дата, до которой хватит средств: система делит доступный остаток на текущий расход и берёт ближайшую из двух границ — деньги или срок лицензии. Рядом написано, какая из них наступит первой, и сколько уходит в месяц. Пока данных о балансе нет — например, на тестовом ключе, — строка сообщает об этом.

Смежные страницы: «Роли и права (RBAC)», «Лицензирование и биллинг», «Хранение данных: сроки и резервные копии».