L’infrastructure de longuevue.galilee.eedf.fr fonctionne comme suit :

• • longuevue.galilee.eedf.fr est un serveur chez OVH, sous Ubuntu, avec BigBlueButton installé dessus. C’est un serveur indépendant car il n’utilise pas la même distribution linux que Galilée, et est bien plus capable de faire de la visio en temps réél.

• • Il est dimensionné pour accueillir 150 connexions simultanées au total, 100 dans une même salle.

• • On peut se connecter dessus depuis le compte root de Galilée, avec ssh longuevue

• • Il utilise le LDAP de Galilée, via une connexion SSH, pour les connexions des comptes des utilisateurices.

Les informations pour se connecter sur l’interface de gestion OVH de ce serveur sont avec les autres codes de l’InterComCom.

BigBlueButton propose une interface d’administration pour les comptes qui ont un rôle “admin”. Cette interface est disponible en cliquant sur ton nom d’utilisateurices, puis “Panneau d’administration”. Demande sur la liste de l’intercomcom qu’on te donne ce rôle si tu ne l’as pas !

Attention : il ne faut pas mettre à jour ce serveur vers une version plus récente d’Ubuntu tant que BigBlueButton n’est pas mis à jour pour gérer cela !

Les stats de longuevue.Galilee sur Munin

Les personnalisations de BBB pour Galilée

Plusieurs changements ont été apportés au BBB de base : charte graphique de Galilée, et traduction françaises de certains textes, de la présentation par défaut, et des sons automatiques.

Toutes ces modifications sont appliquées par /etc/bigbluebutton/bbb-conf/apply-config.sh, qui est lancé après chaque mise à jour de BBB.

Les fichiers sources, si nécessaires, de ces modifs sont dans /root/bbb-personnalisations/

La connexion de Greenlight au LDAP de Galilée

Depuis Greenlight v3, il y a un Keycloak (serveur d’autentification) d’installé en plus. Keycloak se connecte au LDAP de Galilée (à l’aide de la config ci-dessous), et Greenlight v3 utilise Keycloak pour fournir sa configuration.

Pour permettre à Keycloak (l’interface d’accueil, d’où on gère ses salles virtuelles) d’utiliser les comptes utilisateurices de Galilée, voici les petites bidouilles qui ont été mises en place :

• • Un tunnel SSH qui permet de relier le port local 389 (LDAP) à celui de Galilée. Côté Galilée, on autorise la clef publique de formation.Galilée a se connecter uniquement pour faire du port forwarding, dans /root/.ssh/authorized_keys :n

    ncommand="echo 'Port forwarding only account.'",no-X11-forwarding,no-agent-forwarding,no-pty [La clef publique]

• • Côté formation.Galilée, on lance et monitore le tunnel ssh via systemd, avec deux fichiers, /etc/default/local-tunnel@ldap :

    PATH_TO_KEY=/root/.ssh/id_rsa.pub
    LOCAL_PORT=*:389
    REMOTE_ADDR=127.0.0.1
    REMOTE_PORT=389
    REMOTE_USER=root
    REMOTE_HOST=galilee.eedf.fr
    SSH_PORT=2222

    et /etc/systemd/system/local-tunnel@.service :

    [Unit]
    Description=Setup a local tunnel to {a47dfab15c4bc55678f1ed932144e583339a18f7b4b36bbf9932cb8798b37788}In
    After=network.target
    [Service]
    EnvironmentFile=/etc/default/local-tunnel@{a47dfab15c4bc55678f1ed932144e583339a18f7b4b36bbf9932cb8798b37788}i
    ExecStart=/usr/bin/ssh -p ${SSH_PORT} -o ServerAliveInterval=60 -o ExitOnForwardFailure=yes -nNT-L ${LOCAL_PORT}:${REMOTE_ADDR}:${REMOTE_PORT} ${REMOTE_USER}@${REMOTE_HOST}
    RestartSec=15
    Restart=always
    KillMode=mixed
    
    [Install]
    WantedBy=multi-user.target

    Le tout est activé par systemctl enable --now local-tunnel@ldap.

• • Sauf que Greenlight fonctionne dans un container docker, et donc n’a pas accès directement à localhost:389 pour accéder au LDAP. On va donc modifier la configuration réseau de Docker pour avoir des adresses IP stables dans les containers. Ça se passe dans /root/greenlight-v3/docker-compose.yml :

    # on ajoute à la fin de chaque définition d'application
    # (app et db), une adresse :
    services:
        app:
            [...]
            networks:
                vpcbr:
                    ipv4_address: 10.6.0.5
         db:
            [...]
            networks:
                vpcbr:
                    ipv4_address: 10.6.0.6
    
    # et à la fin, une définition du réseau :
    networks:
        vpcbr:
            driver: bridge
                ipam:
                     config:
                       - subnet: 10.6.0.0/16

• • Nous pouvons alors configurer l’accès LDAP de Greenlight dans /root/greenlight-v3/.env sur 10.6.0.1:389. Mais ça ne fonctionne toujours pas, car IPTable ne permet pas aux deux réseaux de communiquer.

• • On va donc créer un script qui va trouver quel est le réseau bridge créé par docker (il change de nom à chaque changement), et ajouter la règle IP table qui va bien. Le script est dans /root/greenlight-v3/allow-ldap-connection.sh :

    #!/bin/sh
    
    # get the bridge network name
    netname_list=`ip a |grep 'br.*:.*state UP'| sed 's/.*\(br-[0-9a-z]*\).*/\1/g'`
    
    # set the right ip table rule
    for netname in $netname_list
    do
    iptables -I INPUT 1 -i $netname -j ACCEPT
    done

    et on crée une unit systemd pour lancer ce script au démarrage, /etc/systemd/system/ldap-access.service :

    [Unit]
    Description=Set the right IP table rules to allow docker to access the LDAP
    After=docker.service
    
    [Service]
    ExecStart=/root/greenlight-v3/allow-ldap-connection.sh
    
    [Install]
    WantedBy=multi-user.target

    que l’on active par : systemctl enable --now ldap-access.service.

• • Et là, ça marche !