Avant l’installation
- Préparez un serveur Linux, un accès administrateur, un domaine et le DNS.
- Identifiez l’exploitant et le contact d’assistance ; définissez les règles d’inscription et de traitement des données.
- Préparez SMTP ou une passerelle e-mail Sibrel autorisée. La vérification d’inscription exige un e-mail fonctionnel.
- Choisissez un stockage compatible S3 : MinIO local ou bucket externe.
- Choisissez LiveKit local ou séparé pour les appels.
- Ouvrez les ports nécessaires dans les pare-feu du serveur et du fournisseur.
Installation et disponibilité
Utilisez l’assistant de gestion des hébergeurs dans une version d’application ou de panneau compatible. Il demande l’accès SSH ainsi que les réglages e-mail, stockage et média. Autorisez-le à modifier uniquement les machines destinées à Sibrel.
Après l’installation, testez GET /api/host/readiness, l’inscription avec e-mail, l’envoi et le téléchargement de fichiers, un appel entre deux réseaux externes et une connexion de bot. Une réponse HTTP réussie ne suffit pas à valider la qualité des appels.
Proxy et passerelle
Le proxy inverse doit transmettre la mise à niveau WebSocket pour /api/bots/gateway et les sockets clients. Ne journalisez pas le paramètre de jeton dans les journaux d’accès. Renouvelez les certificats automatiquement et surveillez leur expiration.
Choisissez les ports LiveKit et TURN adaptés à votre configuration. Les nœuds S3 et média séparés doivent être joignables depuis les serveurs concernés et les réseaux des clients.
Sauvegardes et mises à jour
- Sauvegardez PostgreSQL, le stockage objet, la configuration et les clés de fédération dans un emplacement protégé.
- Fixez une conservation et un calendrier de sauvegarde ; testez régulièrement la restauration sur une autre machine.
- Avant une mise à jour, vérifiez les migrations et la compatibilité des clients, et faites une sauvegarde.
- Les mises à jour des hébergeurs installés par l’assistant peuvent arrêter l’application. Prévenez les utilisateurs au préalable.
- Une sauvegarde de base de données pendant une mise à jour ne signifie pas que la base sera automatiquement restaurée en cas d’échec.
- Protégez SSH, les secrets de service et les sauvegardes contre tout accès non autorisé.
Déplacer des services et ajouter des nœuds
Les nœuds S3 supplémentaires répartissent les nouveaux envois mais ne répliquent pas les anciens fichiers. Les salons sont attribués à des nœuds média ; retirer un nœud de la configuration ne migre pas les salons existants.
Lorsque vous changez d’adresses et de buckets, préservez l’accès aux anciens objets. La migration des fichiers, les changements DNS et la mise hors service des anciennes machines sont des tâches distinctes. Un schéma d’infrastructure ne prouve pas la réussite d’une migration.
Fédération et règles
Ne connectez que des hébergeurs connus avec des clés vérifiées. Surveillez la compatibilité des versions, les routes réseau et la protection contre les rejeux. Le relais n’est pas une file garantie et n’améliore pas automatiquement les médias.
Les exploitants sont responsables de leurs hébergeurs et des utilisateurs relevant de leur autorité. Lisez les règles de création et d’utilisation des hébergeurs et publiez vos propres informations de traitement des données.
Inscription et accès
L’administrateur de l’hôte peut fermer les inscriptions publiques et créer des comptes manuellement dans le panneau d’administration. Ce réglage concerne cet hôte. Appliquez les migrations, conservez une sauvegarde et vérifiez la connexion des comptes existants avant de terminer la mise à jour du serveur.