Cette documentation ne concerne que la version 3.5.1 et supérieure de Pod. |
Dans le cadre du plan de relance, une solution de classe virtuelle du ministère de l'Enseignement Supérieur et de la Recherche (ESR), s'appuyant sur logiciel libre et open source BigBlueButton (BBB), a été déployée à l'échelle nationale.
Plus d'informations peuvent être retrouvées sur les sites suivants :
Pour les établissements n'ayant jamais eu d’infrastructure locale BigBlueButton, l'utilisation de cette solution de classe virtuelle (BBB ESR) est simple à mettre en œuvre.
Cependant, pour les établissements ayant auparavant une infrastructure locale BBB, l'utilisation du BBB de l'ESR présente des impacts aux usagers.
Cette documentation peut alors être utile pour ces établissements.
Changer d'infrastructure est extrêmement simple, que cela soit pour n'importe quelle plateforme :
En modifiant ces paramètres, la plateforme pointe alors sur la nouvelle architecture BBB.
Pour les usagers, les impacts concernent les enregistrements, qui ne seront alors plus visibles.
En effet, les sessions/réunions sont toujours accessibles aux usagers, car elles sont sauvegardées dans la plateforme concernée, mais pas les enregistrements.
Il faut savoir que ces enregistrements sont sauvegardés directement sur l'infrastructure BBB (soit sur le serveur BBB soit sur le serveur Scalelite).
Dans les plateformes, les liens vers ces enregistrements sont alors affichés au moment de la consultation de la session / réunion.
Au final, lors d'un changement d'infrastructure, les anciens enregistrements ne s'affichent plus aux usagers; et lorsque l'ancienne architecture BBB sera arrêtée, les anciens enregistrements ne seront même plus disponibles, si rien n'a été réalisé avant.
Voici un rappel des contraintes à prendre en compte et qui explique la solution proposée :
L'idée est de se baser sur :
Cette solution repose totalement sur Pod et n'impacte en rien BigBlueButton. Aucune modification n'est à réaliser côté BigBlueButton. |
Ce script de migration est configurable et offre plusieurs possibilités, à savoir:
Ce script va convertir les présentations, de l'ancienne architecture BBB, en fichiers vidéo (comme précédemment, via le plugin bbb-recorder) et positionner ces fichiers dans le répertoire pour la Revendication des enregistrements.
Bien sûr, s'il y a déjà des présentations en vidéo, le fichier vidéo sera directement copié.
Une fois que toutes les vidéos ont été encodées, l'architecture BBB locale peut être arrêtée. Les usagers devront aller chercher leurs vidéos dans l'onglet Revendication des enregistrements dans Pod.
N'hésitez pas à consulter la documentation sur le système de revendication https://www.esup-portail.org/wiki/x/DgB8Lw Entre autres, il y a une possibilité de prévisualiser ces enregistrements. |
L'idée est de laisser le temps aux usagers de choisir par eux-mêmes les enregistrements qu'ils souhaitent conserver (il n'est pas possible et utile de tout convertir).
Pour cela, il faudra laisser l'ancien serveur BBB/Scalelite ouvert au moins pendant quelques mois (juste pour accéder aux enregistrements).
Côté script, si besoin, il faudra un accès à la base de données de Moodle pour savoir qui a réalisé quoi.
Ainsi, pour chaque enregistrement BBB, le script va créer une ligne dans Mes vidéos externes, de type BigBlueButton, pour les modérateurs (qui seront créés si besoin dans la base de Pod).
Ils pourront alors par eux-mêmes importer ces enregistrements dans Pod.
Au cas où, si des enregistrements ne sont pas identifiables, ils seront associés à un administrateur (à paramétrer dans le script).
De plus, si l'accès à la base de Moodle le permet, un message d'information sera positionné directement dans Moodle, au niveau des sessions BBB concernées.
Le script est prévu pour être paramétrable, avec possibilité de gérer un certain nombre d'enregistrements et de pouvoir le tester avant (utilisation d'un mode dry).
Pour convertir les playback présentation de BBB, je me suis basé sur le projet Github bbb-recorder (https://github.com/jibon57/bbb-recorder) : un plugin, indépendant de BigBlueButton, qui permet de convertir - via un script - une présentation Web BigBlueButton en fichier vidéo.
Si besoin, ce plugin permet également une diffusion en direct (flux RTMP) d'un cours BigBlueButton.
Ce plugin bbb-recorder avait déjà été utilisé pour l'ancien système, dans Pod v2 (cf. https://www.esup-portail.org/wiki/x/AgCBNg) et a été utilisé à de nombreuses reprises avec succès. |
Le fait d'exécuter le script bbb-recorder réalise les étapes suivantes :
Il est nécessaire d'installer bbb-recorder sur les serveurs d'encodage.
La documentation de référence est accessible ici : https://github.com/jibon57/bbb-recorder
Pour ma part, sur les serveurs Debian 11, voici ce qui a été réalisé.
Ce plugin n'a pas besoin d'être installé sur un serveur BigBlueButton.
Installation de Chrome et des pré-requis
pod@test:~/$ sudo -i root@test:~/$ apt install xvfb root@test:~/$ curl -sS -o - https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add root@test:~/$ echo "deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main" > /etc/apt/sources.list.d/google-chrome.list root@test:~/$ apt-get -y update root@test:~/$ apt-get -y install google-chrome-stable |
Étant un serveur d'encodage, je considère que ffmpeg est déjà installé. Si besoin, il est nécessaire d'installer ffmpeg.
Voici l'installation pour un utilisateur pod.
pod@test:~/$ cd ~ pod@test:~/$ git clone https://github.com/jibon57/bbb-recorder pod@test:~/$ cd bbb-recorder pod@test:~/bbb-recorder/$ npm install --ignore-scripts pod@test:~/bbb-recorder/$ cp .env.example .env |
Gestion du répertoire contenant les vidéos : dans mon cas /data/www/pod/bbb-recorder et du répertoire de logs /data/www/pod/bbb-recorder/logs.
pod@test:~/bbb-recorder/$ mkdir /data/www/pod/bbb-recorder pod@test:~/bbb-recorder/$ mkdir /data/www/pod/bbb-recorder/logs |
Si bbb-recorder n'a pas été installé avec le bon utilisateur (pod), les fichiers vidéos générés ne seront sûrement pas accessibles par l'utilisateur Pod et ne pourront alors être encodés par les serveurs d'encodage. Dans les faits, cela se traduit par un 1° encodage réussi : la présentation Web de BBB sera convertie en fichier vidéo, mais ce fichier vidéo ne sera pas accessible à Pod et ne pourra être converti en vidéo Pod. |
{ "rtmpUrl": "rtmp://xxxxxxxx:xxxxxxxxxx@xxxxx.univ.fr:1935/live/stream", "ffmpegServer": "ws://localhost", "ffmpegServerPort": 4000, "auth": "xxxx", "copyToPath": "/data/www/pod/bbb-recorder" } |
const BBBUrl = "https://xxxx.univ.fr/bigbluebutton/", BBBSalt = "xxxxxxxxxxxxxxxxxxxx", joinName = "recorder"; |
Il faut bien penser que bbb-recorder utilise un répertoire temporaire pour générer une vidéo, avant que celle-ci ne soit copiée dans le répertoire configurée (cf. copyToPath). Ce répertoire temporaire correspond à ../Downloads. Ainsi, dans le cas d'une installation dans le home directory de l'utilisateur pod, le répertoire temporaire créé et utilisé par bbb-recorder est /home/pod/Downloads. Il est nécessaire qu'un espace de stockage suffisant soit alors prévu. |
Une fois bbb-recorder installé sur les différents serveurs d'encodage, il reste à configurer le plugin bbb directement dans Pod, via l'édition de fichier custom/settings_local.py (sur les encodeurs et sur le frontal) :
# Use import-video module USE_IMPORT_VIDEO = True # Use plugin bbb-recorder for import-video module # Useful to convert prensentation playback to video file USE_IMPORT_VIDEO_BBB_RECORDER = True # Directory of bbb-recorder plugin (see documentation https://github.com/jibon57/bbb-recorder) # bbb-recorder must be installed in this directory, on all encoding servers # bbb-recorder create a directory Downloads, at the same level, that needs disk space IMPORT_VIDEO_BBB_RECORDER_PLUGIN = '/home/pod/bbb-recorder/' # Directory that will contain the video files generated by bbb-recorder IMPORT_VIDEO_BBB_RECORDER_PATH = '/data/www/pod/bbb-recorder/' |
Les éléments de paramétrage sont les suivants :
USE_IMPORT_VIDEO_BBB_RECORDER : utilisation (True/False) du plugin bbb-recorder pour le module import-vidéo; utile pour convertir une présentation BigBlueButton en fichier vidéo.
Si vous utilisez la 1° option du script, à savoir le système de revendication des enregistrements, il vous est possible de ne pas donner la fonctionnalité de conversion des présentations BBB en fichier vidéo aux usagers. Ainsi, il vous est possible de mettre USE_IMPORT_VIDEO_BBB_RECORDER = False dans ce cas de figure. Les autres paramètres sont nécessaires, à minima, lors de l'exécution du script. |
Concernant le répertoire contenant les fichiers vidéos générés par bbb-recorder (IMPORT_VIDEO_BBB_RECORDER_PATH), il est à créer manuellement - en même temps que son sous-répertoire des logs - avec les lignes de commande suivantes; n'hésitez pas à les modifier à votre convenance selon votre architecture système et vos droits :
pod@test:~/$ mkdir /data/www/pod/bbb-recorder/logs -p pod@test:~/$ chown pod:nginx /data/www/pod/bbb-recorder/logs |
Il est vrai qu'une création automatique de ces répertoires auraient pu être possible, mais aux vues des problèmes que cela aurait pu engendrer, en lien avec l'architecture et les droits, il m'a paru préférable que l'administrateur de Pod créé ces 2 répertoires à la main. Il sait ce qu'il fait et pourra ainsi choisir son emplacement, ses droits ou autres. |
Ce script est accessible dans Pod, dans le répertoire pod/video/management/commands/migrate_bbb_recordings.
Ce script ne peut être exécuté comme cela, il est indispensable de réaliser un paramétrage, indépendant de la configuration de Pod, supplémentaire directement dans ce fichier. |
Comme évoqué ci-dessus, ce script offre 2 possibilités, à savoir :
Ce script va convertir les présentations, de l'ancienne architecture BBB, en fichiers vidéo (via le plugin bbb-recorder) et positionner ces fichiers dans le répertoire d'un enregistreur pour la Revendication des enregistrements (cf. https://www.esup-portail.org/wiki/x/DgB8Lw)
Bien sûr, s'il y a déjà des présentations en vidéo, le fichier vidéo sera directement copié.
Une fois que toutes les vidéos ont été encodées, l'architecture BBB locale peut être arrêtée. Les usagers devront aller chercher leurs vidéos dans l'onglet Revendication des enregistrements dans Pod.
Ceci est possible en utilisant le paramètre --use-manual-claim et la configuration directement dans ce fichier.
Veuillez noter qu'en fonction de l'architecture de votre Pod, l'encodage sera effectué soit via des tâches Celery, soit directement, l'un après l'autre. N'hésitez pas à tester sur quelques enregistrements et de lancer ce script en arrière-plan (en utilisant &). |
L'idée est de laisser le temps aux usagers de choisir par eux-mêmes les enregistrements qu'ils souhaitent conserver (il n'est pas possible et utile de tout convertir).
Pour cela, il faudra laisser l'ancien serveur BBB/Scalelite ouvert au moins pendant quelques mois (juste pour accéder aux enregistrements).
Côté script, si besoin, il faudra un accès à la base de données de Moodle pour savoir qui a réalisé quoi.
Ainsi, pour chaque enregistrement BBB, le script va créer une ligne dans Mes vidéos externes, de type BigBlueButton, pour les modérateurs (qui seront créés si besoin dans la base de Pod).
Ils pourront alors par eux-mêmes importer ces enregistrements dans Pod. Au cas où, si des enregistrements ne sont pas identifiables (par exemple en provenance d'autres sources que Pod ou Moodle), ils seront associés à un administrateur (à paramétrer dans le script).
De plus, si l'accès à la base de Moodle le permet, un message d'information sera positionné directement dans Moodle, au niveau des sessions BBB concernées.
Ceci est possible en utilisant le paramètre --use-import-video, le paramètre --use-database-moodle (optionnel) et la configuration directement dans ce fichier.
Ce script vous permet également de :
Ce script a été testé avec Moodle 4. |
Paramètre | Description | Valeur par défaut / Format |
---|---|---|
SCRIPT_BBB_SERVER_URL | Ancienne URL du serveur BigBlueButton/Scalelite | 'https://bbb.univ.fr/' |
SCRIPT_BBB_SECRET_KEY | Clé BigBlueButton ou Scalelite LOADBALANCER_SECRET | 'xxxxxxxxxx' |
SCRIPT_PLAYBACK_URL_23 | Est-ce que la version de BBB est supérieure à 2.3, vis-à-vis des URLs de playback ? Utile pour la lecture de présentations au format 2.0 (pour BBB <= 2.2) ou 2.3 (pour BBB >= 2.3) | True |
SCRIPT_RECORDER_ID | Enregistreur utilisé pour obtenir les enregistrements BBB (utile avec --use-manual-claim) | 1 |
SCRIPT_ADMIN_ID | Administrateur auquel les enregistrements seront ajoutés si les modérateurs n'ont pas été identifiés (utile avec --use-import-video) | 1 |
DB_PARAMS | Paramètres de connexion à la base de données Moodle (utile avec --use-import-video et --use-database-moodle) A partir de Pod 3.6.0, il s'agit d'un dictionnaire dont la clé est le champ bbb-origin-server-name de chaque enregistrement BBB.Si vous n'avez qu'un seul serveur Moodle, remplissez simplement le "default". | Pod 3.5.2 : 'host': 'bddmoodle.univ.fr', 'database': 'moodle', 'user': 'moodle', 'password': '', 'port': '', 'connect_timeout': '10' } |
SCRIPT_INFORM | Message d'information qui sera défini dans la base de données Moodle, table mdl_bigbluebuttonbn, champ intro (utile avec --use-import-video et --use-database-moodle) | Message prévisionnel pour l'université de Montpellier |
IGNORED_SERVERS | Une liste de serveurs à ignorer (soi ce ne sont pas des serveurs Moodle, soit ce sont des serveurs de dev ou de test...) | ["not-a-moodle.univ.fr"] |
USE_CACHE | Utile si vous relancez plusieurs fois le script d'affilée. En mettant USE_CACHE=True, il n'interrogera plus BBB mais la dernière réponse de ce dernier stockée dans un fichier XML | False |
Argument | Description | Valeur par défaut / Format |
---|---|---|
--use-manual-claim | Utiliser la revendication manuelle | False |
--use-import-video | Utiliser le module d'importation vidéo pour obtenir des enregistrements | False |
--use-database-moodle | Utiliser la base de données Moodle pour rechercher des modérateurs. N'est utile que lorsque --use-import-video a été mis à True. | False |
--min-value-record-process | Valeur minimale des enregistrements à traiter | 1 |
--max-value-record-process | Valeur maximale des enregistrements à traiter | 10000 |
--dry | Simule ce qui sera réalisé | False |
--use-export-csv | Exporte la liste des enregistrements au format CSV. Ajouter --use-database-moodle pour noter dans une colonne les modérateurs. | False |
Comme dans toute migration, penser à réaliser les sauvegardes adéquates avant d'exécuter ce script sans simulation. Typiquement, à minima la base de données de Pod, voire la base de Moodle (si vous y accédez en écriture) dans le cas de --use_import-video et --use-database-moodle. |
Voici quelques exemples et cas d'utilisation de ce script, à ne lancer qu'après avoir réalisé le paramétrage interne. N'hésitez pas à faire des essais sur quelques lignes et d'utiliser le mode dry pour comprendre ce qui sera réalisé.
Ne pas hésiter à ignorer le warnings en mettant -W ignore. |
Avant de réaliser ces commandes, penser à exécuter ces requêtes (à adapter selon votre environnement) : cd /usr/local/django_projects/podv3 |
python -W ignore manage.py migrate_bbb_recordings --use-manual-claim --dry |
python -W ignore manage.py migrate_bbb_recordings --min-value-record-process=1 --max-value-record-process=2 --use-manual-claim --dry & |
Si vous utilisez les tâches asynchrones (CELERY_TO_ENCODE = True), sans le dry, cette commande va lancer 2 tâches d'encodage. Si vous n'utilisez pas les tâches asynchrones (CELERY_TO_ENCODE = False), sans le dry, cette commande va réaliser directement l'encodage (sauf si le playback est au format vidéo bien entendu) de la 1° présentation, puis une fois celle-ci terminée, l'encodage de la 2° présentation. |
python -W ignore manage.py migrate_bbb_recordings --use-import-video --use-database-moodle --dry |
Sans le dry, cette commande va créer des lignes d'enregistrements externes dans la base de Pod, pour le module d'import des vidéos. Il n'y a alors aucun encodage qui est réalisé à ce moment. Les usagers pourront retrouver ces enregistrements dans ce module d'import des vidéos et les téléverser sur Pod en tant que vidéo : c'est à ce moment que l'encodage sera réalisé. |
python -W ignore manage.py migrate_bbb_recordings --min-value-record-process=1 --max-value-record-process=10 --use-import-video --dry |
python3 manage.py migrate_bbb_recordings --use_export_csv --use-database-moodle --max-value-record-process=10 --dry |
Le script affiche un ensemble d'informations pour chaque ligne traitée; il ne faut pas hésiter à le lancer en mode dry.
Il est possible de relancer le script plusieurs fois, cela ne va pas créé de doublons. Par contre, cela peut ré-encoder des enregistrements qui avaient déjà été encodés lors de la 1° passe. |
L'interface d'administration permettant de suivre les enregistrements traités concerne les enregistreurs et les enregistrements.
Un enregistreur :
Liste des enregistrements :
L'interface d'administration permettant de suivre les enregistrements traités concerne les enregistrements externes dans Importer une vidéo externe.
Selon votre environnement, les logs de Pod peuvent se retrouver dans le fichier /var/log/syslog |
Sur les serveurs d'encodage, les logs celery se trouvent dans /var/log/celery/worker1.log (selon votre configuration, si vous utilisez plusieurs workers, vous pouvez avoir plusieurs fichiers).
Si vous utilisez RabbiMQ-Server, sur ce serveur, vous pouvez avoir des informations dans /var/log/rabbitmq/rabbit@xxxxx.log.
Les logs des traitements de bbb-recorder sont accessibles dans le répertoire configuré via IMPORT_VIDEO_BBB_RECORDER_PATH/logs.
Si vous avez opté pour la 2° possibilité, et l'utilisation du module d'import des vidéos : le jour de l'arrêt complet de votre ancienne infrastructure, les anciens liens ne fonctionneront plus.
Si vous souhaitez supprimer les enregistrements externes qui concernaient votre ancienne infrastructure, il vous est possible de le faire directement via une requête SQL à exécuter dans la base de données de Pod, à savoir :
# Remplacer SCRIPT_BBB_SERVER_URL par la bonne valeur, selon votre environnement DELETE FROM import_video_externalrecording WHERE source_url like 'SCRIPT_BBB_SERVER_URL%' |
Je préfère ne pas mettre cette requête dans le script; à vous de voir quand vous souhaitez réaliser cette suppression. Bien entendu, pensez à réaliser une sauvegarde avant. |