インストールの前に
- Linux サーバー、管理者アクセス、ドメイン、DNS を用意します。
- 運営者とサポート窓口を明確にし、登録とデータ処理のルールを定めます。
- SMTP または許可された Sibrel のメールゲートウェイを用意します。登録確認には有効なメールが必要です。
- S3 互換ストレージ（ローカルの MinIO または外部バケット）を選びます。
- 通話にはローカルまたは別ホストの LiveKit を選びます。
- サーバーとプロバイダーのファイアウォールで必要なポートを開放します。
インストールと準備確認
互換性のあるアプリまたはパネルのバージョンでホスト管理ウィザードを使用します。SSH アクセス、メール、ストレージ、メディアの設定を求められます。Sibrel 用のマシンだけを変更するよう許可してください。
インストール後は GET /api/host/readiness、メールでの登録、ファイルのアップロードとダウンロード、2 つの外部ネットワーク間の通話、ボットの接続を確認してください。HTTP の応答が成功しただけでは通話品質は確認できません。
プロキシとゲートウェイ
リバースプロキシは /api/bots/gateway とクライアントのソケットの WebSocket Upgrade を転送する必要があります。アクセスログにトークンのクエリパラメーターを記録しないでください。証明書は自動更新し、有効期限を監視してください。
LiveKit と TURN のポートは構成に合わせて選びます。別ホストの S3 とメディアノードには、関連するサーバーとクライアントのネットワークから到達できる必要があります。
バックアップと更新
- PostgreSQL、オブジェクトストレージ、設定、フェデレーション鍵を保護された場所にバックアップします。
- 保持期間とスケジュールを定め、別のマシンで復元を定期的に検証します。
- 更新の前にマイグレーションとクライアントの互換性を確認し、バックアップを取得します。
- ウィザードで導入したホストの更新はアプリを停止することがあります。事前に利用者へ知らせてください。
- 更新中のデータベースバックアップがあっても、すべての失敗で自動的に切り戻されるわけではありません。
- SSH、サービスシークレット、バックアップへの不正アクセスを防いでください。
サービスの移行とノードの追加
追加の S3 ノードは新しいアップロードを分散しますが、古いファイルは複製しません。ルームはメディアノードに割り当てられ、設定からノードを外しても既存のルームは移行されません。
アドレスやバケットを変更するときは、古いオブジェクトへのアクセスを維持してください。ファイル移行、DNS 変更、旧マシンの廃止は別々の作業です。構成図は移行が成功した証拠にはなりません。
フェデレーションとルール
鍵を確認済みの既知のホストだけを接続してください。バージョンの互換性、ネットワーク経路、リプレイ対策を監視します。中継は保証されたキューではなく、メディアを自動的に改善するものでもありません。
運営者は自分のホストと、その権限内の利用者に責任を負います。ホストの作成と利用に関するルールを読み、独自のデータ処理情報を公開してください。
登録とアクセス管理
ホスト管理者は管理画面で公開登録を停止し、アカウントを手動作成できます。この設定は対象ホストに適用されます。サーバー更新前にデータベースの移行とバックアップを行い、既存ユーザーのログインを確認してください。