Wie kann man BBB ohne Moodle mit Greenlight nutzen (und an die LMN anbinden)

Hallo,

hier kann der Austausch zur Nutzung von BBB ohne Moodle stattfinden.

Hallo zusammen,

bitte lest doch diesen Post noch einmal durch, bevor Ihr Fragen zu Greenlight + LDAP habt.
Außerdem lest vorher das Anwenderwiki:
https://wiki.linuxmuster.net/community/anwenderwiki:webapps:bigbluebutton

  1. ich lege wie in der Anleitung beschrieben einen lokalen (greenlight-db) Administrator an
cd greenlight/
docker exec greenlight-v2 bundle exec rake admin:create
  1. ich melde mich mit dem Adminkonto an und ändere ein paar grundlegende dinge, wie teacher/student Rollen
  2. Dann bringe ich LDAP zum Laufen: im Anwenderwiki findet ihr Hinweise, was man für selbst-signierte SSL-ZErtifikate machen muss und was man für die v7 (v6 fehlt noch) hinterlegen muss. Hier im Thread stehts für die v6
  3. Ich habe dann den greenlight-docker container „commited“, damit meine SSL-Änderungen drin bleiben:
docker-compose stop
docker ps -a     # zeigt mir die Container ID an
docker commit <CONTAINER-ID> my/greenlight:v2

dann muss ich docker-compose.yml editieren und aus bigbluebutton/greenlight:v2 durch my/greenlight:v2 ersetzen. Den ganzen Schritt 4 mache ich nur, damit ich bei einem erneuten Aufruf von bbb-install.sh oder bei einem manuellen neustart durch docker-compose -d up nicht wieder durch den sed-Befehl (siehe Wiki) das SSL-checken deaktivieren muss. Evtl. könnt ihr das ja weglassen, wenn euer SSL auch so funktioniert.
5. Ganz unten in der greenlight/.env Datei würde ich auf „open“ Registrierung stellen, oder in der UI als lokaler Admin .
6. Wenn man sich einmal als ein (wichtiger) Lehrer per LDAP angemeldet hat, sollte man sich wieder als lokaler Admin anmelden und den dann in der DAtenbank stehenden Lehrer auch die Rolle Admin verpassen.
7. Danach schalte ich in der greenlight/.env Datei die lokale Anmeldung ab.
8. Achtung! Die „open registration“ lasse ich ganz bewusst drin.

Das ganze hat den Vorteil, dass in dieser Einstellung:

  • Registrierung: open
  • lokale Nutzer = false
  • Anmeldung: per LDAP

Greenlight dann

  • keine Registrierung erlaubt (der Button ist einfach weg, ich hoffe, dass es auch nicht ohne Button geht).
  • trotzdem ein Nutzer Admin ist (und andere LDAP-Nutzer zu Admins machen kann)
  1. Ich stelle noch Videoaufzeichnung grundsätzlich ab

  2. ich stelle die Authentifizierungspflicht momentan noch nicht ein, ich weiß auch nicht, was für die Arbeit mit Schülern sinnvoll ist:
    grafik
    Wenn ich das aktiviere, dann müssen sich Schüler mit einem weitergegebenen Link erst bei greenlight anmelden, tatsächlich verhindere „I-am-brian“ Spielchen damit nicht. Die Schüler können, bevor sie bei einer Konferenz teilnehmen, in ihrem Profil den ANzeigenamen ändern. Insofern kann ich den Zwang zur Authentifizierung auch gleich weglassen.
    Stattdessen und unabhängig davon, sollte ich ein Raumpasswort vergeben, dass es kein BBB-bombing gibt.

  3. wenn ich änderungen an der .env - Datei vorgenommen habe, dann starte ich greenlight immer mit docker-compose up -d neu.

VG, Tobias

2 „Gefällt mir“

HAllo @Christoph,

ich habe das Wiki nochmal editiert und die nginx conf umgeschrieben, weil bei mir das return für die location / zwar gereicht, nicht aber für z.B. /b funktioniert hat.

VG, Tobias

Hallo Tobias,

ein paar Anmerkungen (vornehmlich für den Gebrauch mit einem V6 System):

  1. redaktionell: Vielleicht sollte man statt „Auf einem V-7- (V-6) System“ lieber „Für ein …System“ schreiben. Ich habe mich an diesem Punkt zwar gewundert, aber tatsächlich (natürlich vergeblich) auf dem linuxmuster-Server gesucht.

  2. In der Regel hat man ja für den LDAP-SERVER nur eine IP. Diese habe ich - anders als bei moodle und nextcloud - ohne // eingetragen, z. B. LDAP-SERVER=146.30.11.114

  3. Den Befehl zum Ignorieren des Zertifikates für Ruby habe ich beim Testen der LDAP-Anbindung gefühlt nach jedem Arbeitsschritt bzw. jeder kleinen Änderung abgegeben. Wenn es nicht funktionierte, lag es in der Regel nicht an der .env, sondern an der Zertifikatsgeschichte. Das lässt sich übrigens gut in der /greenlight/log/production.log beobachten, die hilfreich bei der Fehlersuche ist.

  4. Das Problem, dass nach funktionierender LDAP-Anbindung der lokale Admin nicht mehr anmeldefähig ist, habe ich mit dem guten alten Administrator, den man ja sonst fast nur bei der Schulkonsole (V6) braucht, gelöst. Da er zur GID 512 gehört, darf er alles.

Worüber ich noch nachdenke: So einfach Teilnehmer von außen nur mit einem Zahlenschlüssel einladen geht jetzt nicht mehr (oder doch irgendwie?). Ich denke da an Eltern, Experten usw.
Da muss ich wohl LDAP-Zugangsdaten und noch den Zugangsschlüssel verschicken?

Viele Grüße

Wilfried

Hallo zusammen,

vielen Dank an dieser Stelle für die super Vorarbeit!
Ich bin gerade dabei, einen BBB-Server aufzusetzen und werde mich an den Anleitungen versuchen.

Vorab eine Frage hinsichtlich TURN-Server:
Ich habe in irgendeinem Beitrag hier vor kurzem gelesen, dass der LMN TURN-Server verwendet werden kann, für Vereinsmitglieder.
Unsere Schule ist Mitglied, weshalb ich den Support gerne nutzen möchte.
Ich finde leider den Beitrag nicht mehr… Kann mir da jemand weiterhelfen?
Danke!

LG Manuel

Du hast eine PM. Wer den Turn nutzen will, bitte PM an mich.

Hallo Tobias,

auch von mir erstmal vielen lieben Dank für deine großartige Vorarbeit. Leider komme ich mit meiner ldap-Anbindung nicht mehr weiter.

Ich habe die greenligh/.env-Datei nach https://wiki.linuxmuster.net/community/anwenderwiki:webapps:bigbluebutton modifiziert, dann nochmals den Container neu schreiben lassen und nochmals den https-Check nach wiki-Eintrag deaktiviert.

Wenn ich mich dann über ldap Anmelden möchte, dann bekomme ich folgende Fehlermeldung:

Wir haben über Belwue unseren Schulserver und den daran angebundenen ldap-Server in einer Server-IP als Server-Adresse 141.10… öffentlich schalten lassen.
Wir nutzen noch immer die lmn 6.2.

Muss ich hier in der greenlight/.env-Datei den ldap anders konfigurieren als im wiki oder in diesem Threat beschrieben?

Hat jemand die gleichen Probleme und ggf. schon eine Lösung parat?

Hoffe, ich krieg das heute noch gelöst. Ansonsten muss ich doch manuell Konten vergeben, für die Kolleginnen und Kollegen, die unbedingt Video-Learning machen möchten.

Herzliche Grüße
Marcus

Hallo Marcus,

mein Stolperstein ist immer:

auf dem Server, auf dem LDAP läuft muss in /etc/ldap/slapd.conf die IP des BigBlueButton Servers für den Zugriff auf LDAP berechtigt werden.
Hast du das schon gemacht?
VG
Christian

Hallo Christian,

in der slapd.conf-Datei steht unter der #Limit Access:

access to *
       by * read

Hier dürfen doch alle ldap-Server zumindest nachschauen, oder?

Ansonsten steht drin, dass man die Datei nicht verändern soll, da sie eh überschrieben wird.

Auf gut Deutsch: Ich weiß nicht, wo ich unseren BBB-Server eintragen soll, so dass er direkt in der Datei verbleibt, ohne dass er übeschrieben wird.

VG
Marcus

Hast du ein anderes Beispiel, wo du von außen auf den LDAP zugreifst?
Bei der v6.2 funktionierte noch port 389 (also unverschlüsselt) sowie 636 (verschlüsselt, aber das Zertifikat ist meist selbst signiert). Je nachdem was belwue von außen geöffnet hat, musst du weitersuchen.
Wenn du noch nie einen Dienst von außen mit LDAP benutzt hast, dann fehlt dir noch, dass du im IPFire ein Portforwarding einrichtest. Such mal in der Doku danach…

Hallo Tobias,

mit der Anleitung bin ich gut klar gekommen, vielen Dank!
Ich würde ggf. noch den Punkt aufnehmen, dass (für V6) im IPFIRE noch eine Regel angelegt werden muss, damit auf LDAP zugegriffen werden kann.
Der Schritt hatte bei mir noch gefehlt.

Gruß Manuel

EDIT: Gerade gesehen, dass dieser Hinweis schon kam… :slight_smile:
EDIT EDIT: Zur Info: /etc/ldap/slapd.conf muss ich nicht anpassen.

Hallo Marcus

hast Du mal in die
/greenlight/log/production.log
geschaut ob da was hilfreiches steht?

Was mir geholfen hat: Ich hab mir auch die Logs auf dem LMN 6.2 Server angeschaut von ldap.
Geloggt wird dort nach /var/log/syslog
Zuvor Loglevel von slapd von 0 auf 1 stellen.

Gruß

ok, ich suche noch nach der richtigen Regel…
ich finde es nicht mehr: einfach eine port forwarding regeln für das Interface ROT nach 10.16.1.1 für den port 636. Vllt. kann Manuel mal seine Regel hier mit screenshot posten.
vG, tobias

Hallo Tobias,

unsere Firewall routet die ldap-Anfragen richtig. Die Regel gibt es und das Moodle über Belwue funktioniert meist wunderbar über ldap.

Ich habe nun den Tipp von dir befolgt und mal die unverschlüsselte Verbindung zum ldap aufbauen lassen, indem ich umkonfiguriert und Neuschreiben hab lassen.

Lieder führte dies auch nicht zum Erfolg, es trat der gleiche Fehler wieder auf.

Im /greenlight/log/production.log kann ich als letzten Eintrag folgendes sehen:

FATAL: [8f366848-805b-412b-92d0-cbc2a72e7b90]

FATAL: [8f366848-805b-412b-92d0-cbc2a72e7b90] Net::LDAP::Error (Operation timed out - user specified timeout):

FATAL: [8f366848-805b-412b-92d0-cbc2a72e7b90]

FATAL: [8f366848-805b-412b-92d0-cbc2a72e7b90] app/controllers/sessions_controller.rb:144:in `ldap'

INFO: [8f366848-805b-412b-92d0-cbc2a72e7b90] method=POST path=/b/500 format=html controller=ErrorsController action=internal_error status=500 duration=24.33 view=18.25 db=0.14 host=greenlight

INFO: [3f9b65fd-e2fc-404b-839d-a4ba5c3d482e] method=GET path=/b/signin format=html controller=SessionsController action=signin status=200 duration=25.78 view=16.36 db=1.24 host=greenlight

Das zeigt mir, dass die LDAP-Verbindung nicht hergestellt werden kann. Warum auch immer. Ich habe diese ja auf unverschlüsseltem Wege angestoßen.

VG
Marcus

Das hatte ich auch, wenn ich die LDAP-Regeln nicht richtig hatte. Habt ihr die belwue-moodle-ip in der portforward regel oder lasst ihr ALLE rechner von außen auf den port 389 oder 636 zugreifen?

Wir lassen ALLE Rechner von außen auf den Port 389 zugreifen. Die Regel hat der Netzwerker vor mir gemacht, da der Moodle-Zugriff mit Verschlüsselung und mit Eintrag der IP-Adresse von Belwue nicht funktioniert hat.

Ich weiß, Zugriff durch alle Rechner zuzulassen ist nicht ganz sauber, wenn es sonst aber gar nicht geht, dann müssen halt mal auch unsaubere Geschichten her.

Ich werd das bei Gelegenheit versuchen zu ändern, wenn die ganze Homeschooling-Geschichte rum ist und wir auf lmn 7.0 umgestiegen sind. Denn wenn jetzt auch noch der ldap für Moodle nicht funktioniert, dann ist Chaos angesagt.

LG
Marcus

Hallo Marcus, nee klar, keine spirenzchen jetzt machen, alle rechner auf 389. Dann schau mal nach, ob die Namens auflösung auf dem BBb-Rechner funktioniert.
Hast du ne Shell, kannst also ldap-utils isntallieren und ldapsearch ausführen um zu schauen, ob du mit der shell LDAP abfragen hinkriegst.

Nochmal: wenn du es ohne SSL machst, dann musst du

  • LDAP_METHOD=none stellen
  • LDAP_Port = 389
    und dann musst du greenlight per docker-compose up -d neustarten.

VG, Tobias

Nee, halt, stelle LDAP_METHOD="" ein, ich glaube sonst geht es nicht für Port 389

Hallo Tobias,
kannst Du mir sagen, wo Du diese Einstellung vorgenommen hast?
Danke!
Gruß Manuel