Schulträger und andere Bildungseinrichtungen stehen seit dem Frühjahr vor der Herausforderung, ihre Lehre ohne oder mit eingeschränktem Präsenzunterricht bzw. Präsenzveranstaltungen fortzuführen. Dieser Artikel stellt Ihnen das Web-Konferenz-System BigBlueButton vor, das eine mögliche Lösung für diese Herausforderung sein kann. Im ersten Teil des Artikels möchte ich Ihnen einen Überblick über die wichtigsten Funktionen von BigBlueButton geben und kurz darauf eingehen, worauf Sie beim Sizing der Server achten müssen und wie Sie mit Problemen durch NAT und Firewall der Nutzer*innen umgehen. Im zweiten Teil erkläre ich Ihnen, wie Sie Schritt für Schritt BigBlueButton so in Ihre UCS-Umgebung integrieren, dass die Nutzer*innen es mit Ihren gewohnten Anmeldedaten nutzen können.
Was ist BigBlueButton?
BigBlueButton, oder auch kurz BBB, ist ein Open-Source-Projekt, welches seinen Fokus speziell auf die Bedürfnisse von Online-Lehre legt und die Teilnahme an Video-Konferenzen sehr niederschwellig ermöglichen möchte. Notwendig ist hier auf Teilnehmer*innenseite in der Regel nur ein Endgerät mit aktuellem Browser.
Das Projekt wurde im Jahr 2007 an der Carleton University gegründet und wird seither stetig weiterentwickelt. Während der Entwicklung wurde dabei vorrangig Wert auf die Stabilität der Software gelegt. Das letzte große Release gab es im März 2020, bei dem der clientseitige Teil der Anwendung komplett erneuert wurde, sodass jetzt dank HTML5 für die Teilnahme an Konferenzen nur Endgeräte mit einem aktuellen Browser Voraussetzung sind. Während der Coronazeit ist die Nachfrage nach BigBlueButton stark gestiegen und so wurden für BigBlueButton alle paar Tage kleinere Updates veröffentlicht, die BigBlueButton verbessern und erweitern.
Ortsunabhängiges Digitales Lernen: das ist UCS@school!
In unserer Video-Einführung erfahren Sie, wie Sie unsere Open-Source-Lösung auf allen Ebenen des Schulbetriebs effizient und datenschutzkonform einsetzen.
Ganz einfach eine Video-Konferenz mit BigBlueButton organisieren
Nach dem Anlegen eines Konferenzraums in BigBlueButton, muss der/die Moderator*in der Konferenz die URL dieses Konferenzraums allen Teilnehmern, z. B. per Mail, bekannt machen, damit diese dem Raum über ihren Browser beitreten können. Wenn erwünscht, kann der Zutritt zum Konferenzraum auch mit einer PIN vor unerwünschten Teilnehmer*innen geschützt werden. Während des Beitritts zu einer Konferenz führt BigBlueButton automatisch einen Echotest durch, der schon vor der eigentlichen Teilnahme ermöglicht, das eigene Audio-Setup zu testen. Wer häufiger an Video-Konferenzen teilnimmt, wird diese Funktion zu schätzen wissen, da so Wartezeiten vermieden werden, bis jede*r Teilnehmer*in ihr oder sein Mikrofon aktiviert hat. Neben der Audioübertragung kann natürlich auch die Videoübertragung einer am Rechner angeschlossenen Webcam aktiviert werden, sodass sich alle Teilnehmer*innen sehen können.
BigBlueButton bietet aber auch die Möglichkeit, dass Teilnehmer*innen ohne Audio-/Video-Hardware der Konferenz über das normale Telefon beitreten und die visuellen Inhalte über den Browser verfolgen, sodass fehlende Audio-Hardware nicht zur Hürde wird. Voraussetzung hierfür ist die Konfiguration eines VoIP-Providers, der eingehende Anrufe automatisch an den BBB-Server weiterleitet.
Weitere Features von BBB: Präsentationen, Whiteboards, Recording, Chat…
Neben diesen aus Video-Konferenz-Systemen bekannten Features kommen noch weitere hinzu, die auf den Lehrbetrieb abzielen:
- die Präsentation von Folien (PDF, OpenOffice-Dokumente, PNG, …)
- ein Whiteboard, welches bei Bedarf auch für alle Teilnehmer*innen schreibend freigegeben werden kann
- Screensharing für das Teilen einer ausgewählten Anwendung oder des gesamten Desktops mit allen anderen Teilnehmer*innen
- Breakout-Räume, mit denen für Teilgruppen zeitlich begrenzte Unterkonferenzen gestartet werden können
- synchronisierte Videoplayer – für das gemeinsame Ansehen z. B. von Youtube-Videos (der Videoplayer des/der Moderator*in steuert dabei auch die Videoplayer der Teilnehmer*innen)
- Durchführung von Umfragen unter den Teilnehmer*innen
- geteilte Notizen über ein integriertes Etherpad
- gemeinsamer Chatraum für alle Teilnehmer*innen und private Chaträume pro Teilnehmer*innenpaar
- Mitschnitt von Konferenzen inkl. Slides, Whiteboard und Mausbewegungen
Bei Bedarf lassen sich fast alle genannten Features sowie viele weitere von dem Administrator des BigBlueButton-Systems genauer konfigurieren.
Wer BigBlueButton einmal testen möchte, kann eine eigene Demokonferenz durchführen, deren Dauer durch die coronabedingte Nachfrage aktuell auf 60min begrenzt ist.
Benötigte Ressourcen für bis zu hundert Teilnehmer*innen
Je nach Hardwareausstattung kann ein einzelnes BigBlueButton-System bis zu 100 Teilnehmer*innen versorgen, die über eine einzelne oder mehrere Konferenzen verteilt sein können. Die maximale Größe einer einzelnen Konferenz ist dabei von vielen Faktoren abhängig, wie z. B. Anzahl der Teilnehmer*innen, Anzahl der aktiven Webcams, Qualität der Videoströme, Hardwareausstattung von Server und Teilnehmer*innen oder auch der Netzanbindung des Servers, sodass hier keine allgemeingültigen Aussagen gemacht werden können. Das Projekt hat einige Eckpunkte zusammengetragen:
- Minimum server requirements
- Bandwidth Requirements
Ich empfehle Ihnen daher das Aufsetzen einer Testumgebung für einen praxisnahen Test.
Wenn’s mal ein paar mehr sind… der BigBlueButton-Cluster
Für größere Umgebungen, wie z. B. bei Universitäten oder Schulträgern, reicht ein einzelnes BigBlueButton-System nicht aus. Mithilfe des Open Source Load Balancers Scalelite, der speziell für BigBlueButton entwickelt wurde, können mehrere BigBlueButton-Systeme zu einem Cluster zusammengefasst werden, in dem die einzelnen Konferenzen verteilt werden. Für den automatisierten Rollout solch großer Umgebungen gibt es sowohl beim Projekt als auch auf anderen Webseiten bereits fertige Ansible Playbooks, die einem die Arbeit für die Installation des Clusters abnehmen.
Jitsi Meet und das UCS Identity Management
Die gestiegene Nachfrage nach Videokonferenzlösungen hat auch uns im App Center Team in den letzten Wochen beschäftigt. Daher haben wir uns intensiv mit diversen Open-Source-Lösungen für Video Conferencing beschäftigt und in kurzer Zeit Jitsi Meet als App im App Center veröffentlicht …. mehr
Installation von BigBlueButton und Provisioning mit UCS-Benutzern
Im Folgenden möchte ich jedoch zunächst einen sehr einfachen und generischen Weg beschreiben, wie Sie Ihren ersten eigenen BigBlueButton-Server mit öffentlicher IP-Adresse und Let’s-Encrypt-Zertifikat installieren. Dieser soll dann an das Identitymanagement einer UCS-Domäne angebunden werden.
Bisher wurde immer vom BigBlueButton-Server gesprochen, jedoch muss man hier etwas präzisieren. Das hier vorgestellte Videokonferenzsystem besteht aus zwei Teilen:
Zum einen „BigBlueButton“, welches den eigentliche Videokonferenzserver (inkl. Audio-Bridge und Video-SFU) bereitstellt, und zum anderen „Greenlight“, einem Frontend zur Verwaltung von Konferenzen und Benutzern. BigBlueButton wird über ein einfaches und effektives HTTP-API (Application Programming Interface) von außen gesteuert. Auch das in unserem Setup verwendete Frontend Greenlight greift auf dieses API zurück, um z. B. neue Konferenzen anzulegen oder neue Teilnehmer*innen in eine laufende Konferenz aufzunehmen. Neben Greenlight nutzen das API auch viele andere Anwendungen wie z. B. Moodle, Joomla oder Drupal, die darüber BigBlueButton in ihre Anwendung integriert haben.
Nach der Installation des Konferenzservers werden wir Greenlight so konfigurieren, dass es für die Provisionierung von Benutzern auf die entsprechenden Objekte der UCS-Domäne zurückgreift und eine manuelle Pflege von Benutzern in Greenlight nicht notwendig wird.
Videokonferenzen trotz symmetrischem NAT: Installation eines TURN-Servers
Bevor wir jetzt mit der Installation beginnen, müssen wir uns noch eine weitere Komponente ansehen, denn trotz eines Konferenzservers mit öffentlicher IP-Adresse kann es vorkommen, dass Benutzer Verbindungsprobleme mit dem BigBlueButton-Server erleben.
Denn beim Internetprovider oder auf dem Router der Benutzer*innen kommt häufig eine Firewall oder unterschiedliche Ausprägungen von NAT zum Einsatz. Diese Mechanismen können die Audio- und Videoströme von Konferenzsystemen wie BigBlueButton stören. Um diesen Benutzer*innen die Teilnahme an BigBlueButton-Konferenzen zu ermöglichen, kann ein sogenannter TURN-Server aufgesetzt werden (TURN steht für „Traversal Using Relays around NAT“). Der TURN-Server fungiert dabei als Relay und nimmt die Datenströme für Audio und Video vom BigBlueButton-Server an und leitet sie an den/die Teilnehmer*innen weiter (und anders herum). Dabei werden vom TURN-Server unterschiedliche Tricks angewendet, um NAT und Firewall doch zu passieren.
Für den hier von uns gewählten Installationsweg von BigBlueButton muss der TURN-Server auf einem eigenständigen System bzw. virtuellen Maschine mit eigener öffentlicher IP-Adresse und öffentlichen DNS-Eintrag installiert werden. Allerdings werden für den Betrieb des TURN-Servers keine besonderen Ansprüche an CPU- oder Speicher-Ressourcen gestellt. Hier reicht bereits in vielen Fällen ein 1-Kern-System mit 2 GB Arbeitsspeicher aus. Die Netzanbindung des TURN-Servers sollte jedoch der des BigBlueButton-Systems entsprechen, da im Extremfall der gesamte Datenverkehr zwischen BigBlueButton-System und den Teilnehmersystemen über den TURN-Server durchgeleitet wird.
Das Aufsetzen eines eigenen TURN-Servers hat das BigBlueButton-Projekt bereits detailliert in seiner Dokumentation beschrieben.
Falls bereits ein TURN-Server zur Verfügung steht, kann dieser natürlich verwendet werden. Es wird später bei der Installation von BigBlueButton der FQDN des TURN-Servers (hier in unserem Beispiel turndemo.univention.de
) sowie das Passwort für den Zugriff auf den TURN-Server benötigt.
Voraussetzungen für die Installation
Wie zwar schon erwähnt, ist die Anzahl der möglichen Teilnehmer*innen stark von den Ressourcen des Systems abhängig. Daher empfiehlt das BigBlueButton-Projekt die folgenden Minimalvoraussetzungen zum Aufsetzen eines eigenen Servers:
- 8 GB RAM
- 4 CPU-Kerne
- 500 GB freier Platz im Dateisystem für Aufzeichnungen von Konferenzen
- Netzanbindung mit 250 MBit/s Bandbreite (symmetrisch)
Sollte das System durch eine Firewall geschützt sein, müssen die folgenden Ports des BigBlueButton-Systems von außen erreichbar sein:
- TCP-Ports 22, 80 und 443
- UDP-Ports 16384 bis 32768
Weiterhin muss das BigBlueButton-System auf den Port 7636 des später zu verwendenden UCS-LDAP-Server zugreifen können.
Damit das BigBlueButton-System für alle Teilnehmer*innen leicht zugreifbar ist und im Laufe dieser Beispielinstallation automatisch ein Let’s-Encrypt-Zertifikat für das System bezogen werden kann, muss vor der Installation ein DNS-A-Record für die öffentliche IP-Adresse des Serversystems eingerichtet werden. In dieser Installationsanleitung wird exemplarisch der FQDN bbbdemo.univention.de
verwendet.
Als Betriebssystem setzt BigBlueButton in Version 2.2 ein Ubuntu 16.04 voraus.
Automatische Installation von BigBlueButton
Für eine schnelle Basis-Installation von BigBlueButton bietet das Projekt ein Installationsskript an, welches auf einem sauberen Ubuntu-16.04-System (64bit) alle notwendigen Komponenten installiert und konfiguriert. Es empfielt sich hier eine Ubuntu-Minimal-Installation zu wählen, da das System keine Anwendungen wie apache, plesk, usw. installiert haben sollte.
Auch hier hat das Projekt wieder eine sehr ausführliche Installationsanleitung erstellt, die zusammen mit dem Installationsskript auf Github gepflegt wird.
Durch das Skript lässt sich BigBlueButton mit einem einzelnen Befehl auf dem Ubuntu-System installieren. Zuvor muss man sich als Benutzer root auf dem System anmelden bzw. -über den Befehl sudo su -
zum Benutzer root werden.
Vor der eigentlichen Installation sollten Sie noch einige Prüfungsschritte auf dem System durchführen, die im Abschnitt „Pre-installation checks“ zusammengestellt wurden.
War die Prüfung erfolgreich, kann über den folgenden Befehl die Installation gestartet werden:
root@bbbdemo:~# wget -qO- https://ubuntu.bigbluebutton.org/bbb-install.sh | \
bash -s -- -w -g \
-v xenial-22 \
-s bbbdemo.univention.de \
-e bbbadmin@example.com \
-c turndemo.univention.de:MYTURNSECRET
Der Befehl lädt das Installationsskript direkt vom Server des Projektes herunter und startet es sofort mit allen notwendigen Parametern. Darunter ist:
-v xenial-22
: die zu installierende BigBlueButton-Version-s bbbdemo.univention.de
: der öffentliche FQDN des Systems, für den ein Let’s-Encrypt-Zertifikat bezogen wird-e bbbadmin@example.com
: die Kontakt-Mailadresse, die für die Anforderung eines Let’s-Encrypt-Zertifikats benötigt wird-c turndemo.univention.de:MYTURNSECRET
: der FQDN des zu verwendenden TURN-Servers sowie das dafür notwendige Passwort
Nach Abschluss der Installation über das Skript, das ca. 15 Minuten benötigt, ist der BigBlueButton-Server theoretisch sofort einsetzbar. Das in der Standardinstallation enthaltene Frontend Greenlight ist einsatzbereit und im obigen Beispiel unter https://bbbdemo.univention.de/
erreichbar. Wurde die Konfiguration noch nicht angepasst, kann sich aktuell jeder beliebige Benutzer an der Instanz registrieren, anmelden und eigene Konferenzräume einrichten.
Greenlight: Konfiguration der LDAP-Authentifizierung gegen UCS
Um die Anmeldemöglichkeiten an dem BigBlueButton-System einzuschränken, wird das installierte Greenlight an eine vorhandene UCS-Domäne angebunden. Dafür wird die Registrierung für die lokale Benutzerdatenbank von Greenlight deaktiviert und stattdessen der LDAP-Account-Provider konfiguriert und aktiviert. Greenlight greift dafür auf den LDAP-Port 7636 eines UCS-Domänencontrollers zu. Sollte eine Firewall aktiv sein, ist diese vorher entsprechend anzupassen, sodass der Zugriff möglich ist.
Für den Zugriff auf die UCS-LDAP-Server benötigt Greenlight zunächst ein einfaches Authentisierungskonto in der UCS-Domäne. Dies lässt sich auf dem UCS-Domaincontroller Master mit 3 Kommandozeilenbefehlen bewerkstelligen. Zunächst wird die LDAP-Basis über den ucr-Befehl ausgelesen. Außerdem lassen wir uns über den Befehl pwgen
ein langes, zufälliges Passwort erstellen. Der dritte Befehl legt das Authentisierungskonto schließlich an. Dabei müssen LDAP-Basis und Passwort entsprechend angepasst werden.
root@master:~# ucr get ldap/base
dc=bbb,dc=univention,dc=de
root@master:~# pwgen 32 1
aeg4eeveigh1EShoh2Taedau8uDoocei
root@master:~# udm users/ldap create \
--position “cn=users,dc=bbb,dc=univention,dc=de“ \
--set username=“bbbauth“ \
--set password=“aeg4eeveigh1EShoh2Taedau8uDoocei“
root@master:~#
Wurde das einfache Authentisierungskonto angelegt, kann jetzt auf dem BigBlueButton-System der LDAP-Account-Provider aktiviert werden. Dazu muss man zunächst wieder als Benutzer root auf dem BigBlueButton-System angemeldet sein. Anschließend muss die Datei /root/greenlight/.env
angepasst werden.
In der Konfigurationsdatei sind die Optionen für die Authentifizierung über LDAP in der Standardkonfiguration noch nicht gesetzt. Für sie müssen folgende Werte eingetragen werden, wobei auch hier einige Werte angepasst werden müssen:
LDAP_SERVER=master.bbb.univention.de
LDAP_PORT=7636
LDAP_METHOD=ssl
LDAP_UID=uid
LDAP_BASE=dc=bbb,dc=univention,dc=de
LDAP_BIND_DN=uid=bbbauth,cn=users,dc=bbb,dc=univention,dc=de
LDAP_AUTH=simple
LDAP_PASSWORD=aeg4eeveigh1EShoh2Taedau8uDoocei
LDAP_ROLE_FIELD=
LDAP_FILTER=(univentionObjectType=users/user)
LDAP_ATTRIBUTE_MAPPING=uid=uid;name=displayName;email=mailPrimaryAddress;nickname=uid
Dabei ist zu beachten, dass der FQDN, der in LDAP_SERVER
eingetragen wird, mit dem FQDN, der im SSL-Zertifikat des LDAP-Servers hinterlegt ist, übereinstimmt. Anderenfalls wird die LDAP-Verbindung von Greenlight mit einem Error 500 abgewiesen.
Wenn die LDAP-Authentifizierung funktioniert, können die Greenlight-eigenen Accounts deaktiviert werden. Dafür muss die folgende Option gesetzt werden:
ALLOW_GREENLIGHT_ACCOUNTS=false
Um die Änderungen zu aktivieren, müssen diese in den Dockercontainer übernommen werden, in dem Greenlight ausgeführt wird. Dies wird über die folgenden Befehle erreicht:
root@bbbdemo:~# docker-compose -f /root/greenlight/docker-compose.yml down
root@bbbdemo:~# docker-compose -f /root/greenlight/docker-compose.yml up -d
Nach dem Ausführen der beiden Befehle benötigt Greenlight einige Sekunden, bis es vollständig gestartet ist (üblicherweise 15-20 Sekunden).
Damit sind Installation und Anpassung abgeschlossen.
In diesem Beispiel-Szenario kann man sich jetzt mit Benutzernamen und zugehörigen Passwörtern aus der UCS-Domäne an BigBlueButton bzw. Greenlight anmelden. Über die Option LDAP_FILTER
kann die Gruppe der erlaubten Benutzer später noch weiter eingeschränkt werden. Ebenso gibt es in der sehr ausführlichen Dokumentation des Projektes noch viele weitere Optionen, um die BigBlueButton-Instanz weiter an die eigenen Bedürfnisse anzupassen oder zu erweitern.
Kommentare
Lars
Vielen Dank für die Anleitung.
Diese war bereits exakt so umgesetzt. Ich habe auf einen Part zum User/Admin Mapping gehofft.
Leider ist es mir noch nicht gelungen die Administratoren auch zu BBB Administratoren zu machen.
Gibt es da eine Chance auf Part 3 ?
Mit freundlichem Gruß
Alice Horstmann
Hallo Lars,
ich gebe deine Anfrage an meinen Kollegen Sönke weiter. Mal schauen, ob er beizeiten etwas dazu schreiben kann. Gerade hinterlässt die Urlaubszeit bei uns ganz schöne Lücken im Kollegium.
Alice
Sönke Schwardt-Krummrich
Hallo Lars,
das Setzen von Rollen in Greenlight über LDAP-Attribute funktionierte in meinem letzten Test nur eingeschränkt gut. Greenlight bezieht dabei die Rollen aus einem LDAP-Attribut und fügt während des Userlogins diese beim Greenlight-User hinzu. Es wurden jedoch keine Rollen entfernt. D.h. wenn im LDAP für User „schwardt“ das LDAP-Rollen-Attribut von „admin“ auf „user“ geändert wird, fügt Greenlight nur die Rolle „user“ beim User „schwardt“ hinzu, entfernt aber nicht die Rolle „admin“.
Wenn man damit leben kann, kann man es wie folgt aufsetzen:
In der Greenlight-Konfigurationsdatei „/root/greenlight/.env“ (siehe auch im Blogbeitrag) muss in für die Option „LDAP_ROLE_FIELD“ ein LDAP-Attributname gesetzt werden. Dies kann z.B. eines unserer für Kunden reservierten LDAP-Attribute sein: univentionFreeAttribute1 bis univentionFreeAttribute20. Zum Beispiel:
LDAP_ROLE_FIELD=univentionFreeAttribute3
In dem LDAP-Attribut muss jetzt bei jedem Benutzer der Rollenname enthalten sein, z.B. „admin“.
Um die Pflege zu vereinfachen, kann z.B. noch ein „Erweitertes Attribut“ für das LDAP-Attribut univentionFreeAttribute3 definiert werden, damit die Rolle auch in der UMC anpassbar ist. Das Anlegen eines erweiterten Attributs (Extended Attribute) haben wir in unserem Handbuch beschrieben:
http://docs.software-univention.de/handbuch-4.4.html#central:extendedattrs
Ich hoffe, das hilft erstmal bei der Einrichtung weiter.
Viele Grüße,
Sönke