Beiträge von perryflynn

So sieht das dann in Check_MK aus:

pasted-from-clipboard.png

Hier mein Playbook um einen Jitsi-Meet Server hochzuziehen:

https://github.com/perryflynn/jitsi-ansible

Was es tut

• System Basiskonfiguration
• Jitsi Debian Repo konfigurieren
• debconf für Jitsi Pakete
• jitsi-meet und jitsi-meet-turnserver installieren
• Diverse Stolpersteine für coturn abfangen
• Diverse Stolpersteine abfangen, wenn Let Encrypt bereits existiert (reinstallation nach apt purge zB)
• jitsi web config erzeugen
• Rest Interface für Statistiken aktivieren und auf localhost binden
• Diverse anpassungen am Web UI
• Check_MK Plugin für Statistiken erstellen

Status

Work in progress (hab das nur gepostet weil ich gefragt wurde)

Beschreibung und Kommentar

Wenn ich eins in den letzten Tagen gelernt habe, dann dass es bei Jitsi nur eine Konstante gibt: Die Veränderung. Daher sind bootbook und killbook so gebaut, dass man bei einer größeren Veränderung oder bei Problemen die Jitsi Instanz einfach abreißt und eine neue hochzieht. Das funktioniert soweit auch gut und wurde 10 - 20 Mal mit einem jeweils neuem, nackigen Debian 10 und/oder einem wo die Pakete frisch purge-removed wurden getestet.

Das Playbook geht davon aus, dass Jitsi das einzige ist, was auf dem Server betrieben wird.

Keine Garantie für nichts.

Zitat von mainziman

das HTTP-01 challenge od. das DNS-01 challenge Verfahren?

Ich gehe mal von HTTP-01 aus, da Lets Encrypt auch bei externen Domains funktioniert, wo netcup keine Kontroller über die DNS Zones hat.

Zitat von m_ueberall

Wenn das SIP-Gateway deaktiviert ist, benötigt man in Verbindung mit Jitsi keinen NAPTR-Record (auf den man notfalls auch verzichten könnte, wenn es die Konfiguration hergibt, vgl. Quellcode/Quellcodeübersicht).

Cool. Danke.

Zitat von m_ueberall

warum also nicht auch NetCup (zumal hier in den letzten zwei Jahren nicht viel Neues rund um APIs oder DNS-Einstellungen für Anwender geboten wurde)?

Klar, deswegen hab ich meine Domains auch bei nem "richtigen" Domain Anbieter.

Rein technisch KÖNNTE ich also einen Record setzen, aber muss ich das und was müsste dann drin stehen?

Gerade wenn das SIP Gateway eh deaktiviert ist.

Zitat von Track1991

Achtung vor untergeschoben P2P beim Streaming.

Diese ominösen Streaming Seiten braucht man ja zum Glück heutzutage nicht mehr.

m_ueberall  whoami0501

Soweit ich das sehe nutzt Jitsi NAPTR Records nur für den SIP Connector [1].

Also braucht man das für "normales jitsi" doch gar nicht, oder?

[1]: https://github.com/jitsi/jitsi/bl…Utils.java#L794

So wie das aktuell gebaut ist sind IMHO sogar SRV Records für TURN/STUN überflüssig.

Habe noch ein Problem mit dem turnserver gefunden:

https://github.com/jitsi/jitsi-meet/issues/5978

Hat bei mir dafür gesorgt, dass der coturn keinen TLS Port geöffnet hat.

Zitat von ASS

Also kann man bei abgeschaltetem p2p auch den turn Server abschalten, da er eh nicht benutzt wird?

Bin ich mir ziemlich sicher, ja.

Zitat von ASS

Und wie stellt nginx fest, dass es eine p2p Verbindung ist?

Gar nicht. Ob P2P benutzt wird entscheidet der Client. Deswegen ist diese Einstellung ja auch im Java Script config. NGINX erkennt einfach nur was für Pakete rein kommen und leitet entsprechend um.

Zitat von ASS

Nein. turn wird m.e. ausschließlich bei NICHT p2p verwendet.

Nein. https://en.wikipedia.org/wiki/Traversal…lays_around_NAT - siehe erster Absatz.

Zitat von ASS

Was bei einem Server mit öffentlicher ip NIE der Fall ist.

Darum gehts ja auch gar nicht. TURN wird bei P2P Betrieb benutzt wenn aus beiden Richtungen keine Direktverbindung möglich ist.

STUN = P2P Verbindungsaushandlung

TURN = P2P Relay wenn keine Direktverbindung möglich ist

Zitat von ASS

Nein. Stun wird _benötigt_, wenn p2p durch 2 mal nat gehen muss.

Wie ich schon beschrieb. STUN und TURN für P2P. Für alles andere wird die Videobridge benutzt. Unsere beiden Aussagen ergänzen sich, und widersprechen sich somit nicht. Also nicht "nein", sondern "ja".

So, fertig fürs Wochenende. Habe jetzt nen Ansible Playbook um einen Jitsi Server inklusive STUN, TURN, Statistics API, Lets Encrypt und einem Impressums Link im Footer zu bootstrappen. VM klicken, SSH Key hinterlegen, Ansible ausführen, fertig.

Nen Custom Check für Check_MK läuft auch (zwei von sechs Metrics):

pasted-from-clipboard.png

Morgen Abend ist die erste größere Jitsi Session nach dem Umbau. So mit ~10 Personen.

Bin gespannt wies jetzt mit eigenem STUN/TURN läuft.

TURN und STUN werden bei P2P (also Zweier-Konferenzen) verwendet. TURN dient als Relay Server, um eine Verbindung zu realisieren, wenn beide Parteien hinter einem NAT sitzen und somit nicht direkt miteinander kommunizieren können.

In bestimmten Fällen, wenn eine P2P Verbindung realisierbar ist, kommunizieren die Parteien direkt miteinander, und es ist weder die Videobridge noch der TURN Server notwendig.

Alle Konferenzen die mehr als zwei Parteien haben, oder wo die P2P Verbindung aus Gründen fehlschlägt, laufen durch die Videobridge-Komponente von Jitsi.

TURN und STUN werden somit benutzt, um den Server zu entlasten.

Lies Dir mal die Englischen Wikipedia Artikel durch, falls Du es genauer wissen willst.

Es besteht die geringe Chance, dass ich verstanden habe wie STUN/TURN in Jitsi funktionieren. Ziemlich abgefucktes Zeug. (Falls ich mich irren sollte, gerne blamen)

Jitsi liefert das Paket jitsi-meet-turnserver mit, welches einen coturn komplett aus den bereits in debconf hinterlegten Einstellungen konfiguriert und startet. Es gibt zwar ne Warnung bei der Installation, dass die öffentliche IP nicht erkennt wurde, aber das kann man recht einfach korrigieren.

Hier ein Ansible Schnipsel was man tun muss:

vars:
  publicip: "please add your public ip here"

tasks:
  - name: Install Jitsi Package
    apt:
      name:
        - jitsi-meet
        - jitsi-meet-turnserver

  # this fixes the following error:
  # Warning! Could not resolve your external ip address!
  - name: Ensure the public ip in coturn config
    lineinfile:
      path: /etc/turnserver.conf
      regexp: '^external-ip='
      line: "external-ip={{publicip}}"
      register: turncfg

  - name: Restart coturn if cfg was changed
    service:
      name: coturn
      state: restarted
      when: turncfg.changed

Ist coturn installiert, horcht dieser auf Port 4445. Das ist aber egal, da die Dark Magic im NGINX stattfindet. In /etc/nginx/modules-enabled/60-jitsi-meet.conf befindet sich ein Upstream Proxy Setup, welches je nach Request den Port 443 auf jitsi-meet ODER den coturn Server leitet.

Daher sind die Einstellungen in Prosody mit meinedomain.example.com:443 für TURN und STUN auch korrekt.

Das einzige was nun noch zu tun ist: Den STUN in jitsi-meets config.js eintragen.

Dann sollte es laufen.

stunServers: [
    { urls: 'stun:meinedomain.example.com:443' }
],

Man kann den ganzen WebRTC Kram übrigens ganz gut in der Developer Console von Chrome und unterchrome://webrtc-internals/ verfolgen.

Zitat von timkoop

Wieso sollte man als legitimer Hoster so etwas machen?

Naja, die CPU die beim VPS durchgreicht wird, ist ja nur eine Sammlung von CPU Features. Ein Konfigurationstemplate. Mehr nicht. Ich kann das bei meinen Proxmox Servern auch Einstellen wie ich möchte. Nur bei "wichtigen" VMs, die dedizierte Cores bekommen taucht die echte CPU auf.

Deswegen find ichs persönlich auch immer sehr lustig, wenn bei VPS über die CPU gefachsimpelt wird.

Zitat von mfnalex

Sieht gut aus

Nice! Mit Gigabit kann ich auch nicht dienen. Habe das geforkt und um die upload/negotiate Funktionalität erweitert um ein VPN wo 10-20 Casuals drinne verbunden sind debuggen zu können.

Mag jemand folgendes mal testen?

https://github.com/perryflynn/speedtest

demo.gif

Zitat von moggern

Vielleicht könnte man auch eine DB anlegen und die Auslastung über einen längeren Zeitpunkt tracken?

Feel free to Pull Request.

Zitat von whoami0501

Welchen CO2 Sensor nutzt du?

Hab die Sensoren und Links wo man sie bekommt ergänzt.

Zitat von nitram

Was ist denn das?

Siehe https://esphome.io. Es ist ein C-Code-Baukasten, wo man mit YAML beschreiben kann, welche Sensoren an welchem ESP Board hängen und das esphome CLI generiert da mit schwarzer Magie einen Firmware Blob und flasht diesen auf den ESP. Viele Sensoren werden einfach out-of-the-box unterstützt. Ziemlich geil.

Auf der Website gibts ne Liste.

Hab gestern endlich meine In-House Wetterstation auf Basis eines ESP32 und esphome.io in Betrieb genommen. Kommunikation läuft über WLAN und dem Mosquitto MQTT Broker zu Home Assistant, der damit in erster Linie bunte Graphen und anderes malt aber auch die eine oder andere Automation macht.

pasted-from-clipboard.png

pasted-from-clipboard.png

• Temperatur (dht22)
• Luftdruck (dmp280)
• Luftfeuchte (dht22)
• eCO2 (ccs811, benötigt die Sensordaten des dht22 zur Kalibrierung)
• Helligkeit (tsl2561 oder tls2591)

Musste dabei fast nichts programmieren, da esphome.io die Sensoren out of the Box unterstützt.

Ich hab die Frage ja schon Mal in einem anderen Threads gestellt. Was spricht dagegen das sich jeder jitsi Server Betreiber einen eigenen stun hinstellt? Ernst gemeinte Frage, hab keine Ahnung von stun, stehe aber auch vor der Frage welchen ich nutze. Aktuell den jitsi Default.