Eigentlich wäre das was Cooles für den Verein - wir schließen unsere Ressourcen zusammen zu einem für die allermeisten Fälle gerüsteten BBB-Verbund und die Schulen, die keine eigene Hardware beisteuern, unterstützen das mit einer Spende je nach Schülerzahl
Ultra-cool! (hab die Rakete nicht gefunden)
Ich sehe das Problem, dass wir LDAP/moodle der einzelnen Schulen damit vergessen können, oder? scalelite verteilt einen bbb-auth auf mehrere BBB-instanzen und nicht multiple-authent auf multiple BBB-Instanzen.
Aber man könnte jedem Lehrer einer Teilnehmenden Schule einen Zugang „legen“ und die Schüler sind pseudonym dabei.
VG, Tobias
Hmm, also so wie ich das Schema verstehe, benötigt man dem LDAP beim Zugriff aus Moodle heraus nicht - das läuft dann nur über den API-Key. Was tatsächlich nicht ginge, ist die direkte Authentifizierung am Lastserver.
Das wiederum gilt aber doch nur für Schulen, die den „eigenen“ BBB-Server nicht kennen. Vermutlich kann man sich auf DEM doch immer noch per LDAP anmelden (wenn der Last-Server nur die API nutzt). Aber das ist nur mein Gefühl nach Überfliegen des Diagramms.
Vor allem würde es dann auch Sinn machen, wenn eine große Schule einen zweiten Server mietet. Denn an sich würde ja jede Schule mit mehr als 200 Nutzern einen Lastverteiler (evtl. plus Postgre/Redis-Server) benötigen - das wäre unverhältnismäßig - auch wenn die Anforderungen überschaubar zu sein scheinen.
Hätte man einen linuxmuster-Lastverteiler, könnte man jederzeit Server hinzufügen und entfernen (ist je ein rake-Befehl). Große Schulen steuern dann in der Krise 2 Server bei, ganz kleine können das evtl. mitbenutzen. Und das ganze wäre auch nach dieser „Krise“ in deutlich reduziertem Umfang nutzbar.
Und Hetzner macht bestimmt Sonderpreise, wenn man das an die große Glocke hängt
Aber warten wir mal den Abend ab. Bestimmt geht es Montag einfach ganz normal weiter
Hat jemand https://github.com/greenstatic/bigbluebutton-exporter mit BBB verheiratet? Prometheus sammelt ueber den Exporter BBB-Daten und Grafana visualisiert diese, der Screenshot sieht verdammt gut aus.
Wenn ich Docker richtig verstanden habe, muesste doch jemand von den Dockergurus hier einen Container zusammenfrickeln koennen, der Prometheus incl. bigbluebutton-exporter und Grafana beinhaltet, indem man nur noch die eigene Adresse mit einem Key aendern muesste?
Oder hab ich Docker falsch verstanden?
Durch das BigBlueButton-Installationsskript sieht ja BBB bei allen fast gleich aus.
Unsere Schulleitung denkt an eine GLK mit BigBlueButton, das waeren dann mal so 70 Leute im System, hat jemand von Euch schonmal so eine Menge ueber einen Server bespasst?
Man darf einfach keine Zeit für so etwas haben! Ich sage mal… „Vielen Dank“
Nein ernsthaft - das wollte ich natürlich gleich mal ausprobieren. Und wenn man irgendwann durchgestiegen ist, wie das aufeinander aufbaut (UND die Doku genau liest), dann ist es gar nicht schlecht, um zuzuschauen, was auf dem Server los ist!
Ich glaube, viel „zusammendockern“ muss man da gar nicht. Man installiert ein paar Pakete und packt die yml-Dateien, die man für den Docker-Container benötigt, in ein Verzeichnis.
Bei mir hakt es noch etwas am netdata-Kram und absichern muss ich es auch. Das ist aber dokumentiert.
Auf jeden Fall eine schöne Ergänzung!
Morgen beginnen bei uns die ersten Live-Tests (Teile von Klassen, eine Dienstbesprechung mit der Schulleitung und den Fachobleuten). Ich werde mal berichten.
Viele Grüße
Thomas
PS: Man könnte das aber auch auf einen linuxmuster-Lastserver installieren (da sind ja die API-Keys) und nur den Exporter mit in Franks Installationsskript packen - das gäbe ein Feuerwerk
Prometheus und Grafana gibt’s ja schon als fertige Container, ich hab leider nur begrenzt Ahnung von Docker, also wie man das in einen Container zusammenpackt und da noch den Exporter mit reinbringt, der Scheiss muss ja dann noch mit nginx und BBB verheiratet werden.
Super waere dann natuerlich noch, wenn dann per Skript noch der/die notwendigen Keys und der FQDN abgefragt werden wuerden und da irgendwie mit reingefrickelt.
Ich habe es jetzt zum Laufen bekommen. Bei mir gab es noch einen Fehler mit den „Instances“ - das Feld war bei mir leer. Daher fehlten auch die Infos von „netdata“ (CPU, etc.).
Falls sich noch jemand versucht und das gleiche Problem hat: bei mir musste ich bei den Einstellungen des Server-Instance-Dashboards unter Variablen den Wert bei Refresh auf on dashboard load ändern. Danach lief es dann.
Es gibt ein Issue, das darauf hinweist, dass netdata doch eine ziemliche Keule für die paar Infos sei. Auf der anderen Seite (ich kannte es nicht) kann man sich da wirklich jedes noch so kleine Detail anzeigen lassen. Und z.B. die Rückmeldung von CPU-Last und Nutzer bzw. Bandbreite in einem Diagramm ist vermutlich schon sehr aussagekräftig.
Auch die Möglichkeit, mehrere Server anzeigen zu lassen, ist hilfreich. Zudem kann man das, was man wirklich auf dem BBB-Server benötigt, in 5 Minuten einrichten.
Danke jedenfalls für den Tipp! Ich bin gespannt, was das morgen ausspuckt
Viele Grüße und gute Nacht
Thomas
PS: es gäbe ein kleines Problem, falls man das auf dem neuen linuxmuster-BBB-Lastverteiler installiert. Es wird eine Absicherung des nginx mit einem Password empfohlen - und dieses müsste identisch sein (in der prometheus.yml gibt man eins an - für alle Server). Idee: man wählt als Passwort den API-Key des BBB - das hat man auf dem Lastserver ja eh…
Hallo,
ich hätte Interesse an einem gemeinsamen Lastverteiler.
Wir könnten, denke ich, zwei bbb Server (jeweils dedizierte Hardware, 4 Kerne, 8GB Ram) anbieten.
Der Lastverteiler ist nach außen ein BBB-Server. Ich trage ihn bei Moodle ein. Er hat einen eigenen API-Schlüssel und eine Adresse.
Auf diesem Lastserver sind (beliebig viele) BBB-Server als Clients registriert. Beim erstellen eines Konferenzraums schaut der Lastserver, welcher dieser Clients gerade eine gute Verfügbarkeit hat und erstellt den Raum dann da. Das Aufnahmeverzeichnis ist auf dem Lastserver gemountet.
Nach außen bekommt man davon nichts mit. Man weiß nicht, wo der Konferenzraum gehostet ist. Das ist auch der einzige „Knackpunkt“. Wenn ich als Schule Aufnahmen erstelle, werden die ggf. auf mehrere Clients verteilt. Aber letztlich wäre das jetzt auch so, wenn ich als Schule 2-3 Server betreibe und dann einen abschalten will. Man kann aber die Aufnahmen verschieben - ich vermute, irgendwie lässt sich das dann schon zusammenführen (ist irgendwo bei BBB dokumentiert, meine ich).
@andreas72 Wir wären bei einem Lastverteiler ebenfalls dabei. Wir könnten problemlos 2-3 Server zur Verfügung stellen.
Wenn wir 4-5 Leute hätten, der Vorstand das unterstützt und entsprechende Serverressourcen zur Verfügung stellt… dann fände ich das ein sehr spannendes Projekt. Das müsste gut organisiert werden (da ja vertrauliche API-Schlüssel hin und her wandern und man darauf „vertrauen“ müsste, dass sich nicht Schulen einklinken oder den API-Schlüssel weitergeben, ohne Ressourcen mit auszubauen). Aber mit der von Thorsten vorgestellten Software hat man einen hervorragenden Überblick, kann rechtzeitig auf Engpässe reagieren und tolles Bildmaterial für die Öffentlichkeitsarbeit erstellen
Viele Grüße
Thomas
PS: Wir hatten gerade eine Fachobleute-DB mit ca 20 Teilnehmern. Nebenher liefen noch 2 andere Konferenzen. Insgesamt 40 Teilnehmer. Während eine Aufnahme gerendert wurde, stieg die CPU-Last kurzzeitig auf 30%, ansonsten war sie so bei 10%. Netzwerkbandbreite bei ca. 10% des Verfügbaren. Und die ganze Zeit lief es sehr stabil, man konnte gut arbeiten mit Bildschirmfreigabe, Audio, z.T. auch mit Webcam. Das hat Spaß gemacht!
das klingt ja alles ganz nett, aber …
sorry: das muss ich mitdenken: es gibt noch den Datenschutz.
Ich habe von hetzner eine Erklärung zur „Datenverarbeitung im Auftrag“
… das sehe ich bei dem Lastverteiler leider nicht: da hätte bestenfalls
„eine“ Schule eine solche Vereinbarung mit hetztner, aber gegebenenfalls
nciht „meine“.
Ja, das Problem sehe ich auch noch. Darum geht es ja gerade erst einmal - Brainstorming.
Eigentlich kann man nur als Schule einer entsprechenden Vereinbarung zustimmen und die Admin-Zugriffe so minimal wie möglich gestalten. Zugriff auf „fremde“ Aufzeichnungen hätte ja eh nur ein Administrator.
Sinn macht das ja vor allem bei der Nutzung über Moodle (wo ich eh nichts anderes, als den Kursraum und seine Aufzeichnungen sehe). Würde man den Server „lokal“ nutzen (also nicht über die Lastverteilung), wäre es (auch wieder „außer für den Admin“ ebenso.
Wobei ich nicht mal weiß, wie ein lokaler BBB-Server damit umgeht, wenn Aufzeichnungen, die über die Adresse des Lastverteilers entstehen, abgespeichert werden. Das müsste man wohl einfach mal „in Aktion“ sehen.
PS: Auf jeden Fall kann man einer Rolle das Recht entziehen, „Serverräume und deren Aufzeichnungen“ zu verwalten. Wenn also Schulen bereit sind, einen BBB-Server „abzutreten“ und auf lokale root-Zugänge zu verzichten und nur mit einer eingeschränkten BBB-Admin-Rolle zu arbeiten (das könnte Franks Skript ja so einrichten), wäre es dann nicht sauber gelöst?
Zugriff hätte man dann nur vom Lastverteiler aus, der in wenigen Händen ist. Und die Nutzung dieses Lastverteilers wäre natürlich erst nach entsprechender Einverständniserklärung erlaubt sein (egal, ob/was man da nun irgendetwas sehen kann oder nicht).
Wir haben kein Moodle und können uns das auch nicht in der Kürze der zeit aneignen.
Ich habe aber auch nicht verstanden, wie das von moodle aus funktionieren soll, dass Teacher über den Lastverteiler an einem beliebigen (non-lokalen) BBB sich anmeldet und der dann weiß, dass der moderator ist, während die Schüler aus demselben Moodle sich dorthinklicken und der BBB dort wissen soll, dass die nur Zuschauer werden sollen.
Im Prinzip würde meine Schule sicher auch mitmachen, aber wenn uns das ohne Moodle nix bringt?
Ich muss mich korrigieren. Auch Greenlight nutzt ja nur die API, also müsste das eigentlich auch gehen. Greenlight ist ja ein HTML5-Client für BBB.
Vermutlich hätte man dann in der Schule nur noch Greenlight mit den API-Daten des Lastverteilers stehen und dann ginge sogar die LDAP-Anmeldung wie gehabt. Es wird dann eben nur nicht der „lokale“ Server genutzt, sondern die Lastverteilung.
Also doch kein Moodle nötig - habe nur nicht lange genug nachgedacht
Ah, jetzt verstehe ich auch ! Ist ja nur die Anmeldung, die die Authentifizierung und die AUthorisierung also die Rollenzuteilung übernimmt, danach ist man „auf dem BBB“ (egal auf welchem) und die weitere persistente authentifizierung geht wohl über cookies zwischen Client und BBB.
Pro Raum kann dann per Lastverteilung logischerweise unterschiedliche BBB-Server rauskommen, oder? Also konferiere ich mit der 10a lande ich evtl. auf dem eigenen Server, konferiere ich mit der 10b lande ich auf dem in Northeim…
Dann sollten wir uns auf minimal-standards für die teilnehmenden BBB-Server einigen, nicht dass jemand wie ich auf die Idee kommt, meinen hetzner-cloud-2-core BBB-Server mit ins Rennen zu schicken…
VG und danke fürs mitverstehen! Tobias