, , ,

WebRTC Audio/Video Server auf Uberspace

Nach dem ich auf der Facebook Seite vom OwnCloud-Fork NextCloud berichtet haben, bin ich in den News zu NextCloud auf einen interessant Erweiterung namens Spreed.Me gestoßen. Diese App erweitert, im Zusammenspiel mit dem Spreed WebRTC Server, die Cloud um ein Audio und Video Konferenz Funktion.

Um ein paar Features des WebRTC Servers / der  App zu nennen:

  • Audio- / Video- / Text Kommunikation im Browser
  • Teilen von Dokumenten und speichern der Dokumente direkt in der Cloud (NextCloud/OwnCloud)
  • Teilen des Bildschirminhaltes (ggf. bestimmte Voraussetzungen erforderlich)

Damit diese Erweiterung lauffähig ist, benötigt man noch den WebRTC Server. Auf der GitHub Seite findet man nähere Informationen zur Erweiterung. Wie es scheint soll diese Erfolgsversprechende App vollen Support von NextCloud erhalten wie man auf der NextCloud Seite lesen kann. So ist auch davon auszugehen, dass diese Installation längere Zeit unter NextCloud Verwendung finden kann.

Vorteile die NextCloud jetzt schon mit sich bringt ist die Enterprise Funktionalität, einen Ordner für den Upload frei zu geben, ohne dass der Kunde in den Ordner sehen kann. Bis dato gibt es noch keine Unterschiede zur OwnCloud. Da es keine Nachteile mit sich bringt wurde kurzerhand eine NextCloud auf Uberspace aufgesetzt und läuft dort seit kurzem mit memcached reibungslos. Einziges Manko ist die Webupload Begrenzung auf ca. 300MB. Bei größeren Dateien bricht der Upload ab. Mit dem Desktop Client kann diese Grenze aber umgangen werden, da Dateien in mehreren Teilen auf den Server geladen werden.

In diesem Tutorial wird mit NextCloud gearbeitet, es sollte aber auch problemlos mit einer OwnCloud Installation funktionieren.

 

 

Spreed WebRTC

 

Als erstes wird der WebRTC Server installiert sowie weitere Extension geladen. Zuerst laden wir die letzte verfügbare WebRTC Version herunter und entpacken diese. In dieser Anleitung wird mit dem Release 0.27 gearbeitet (Pre-release).

$ cd ~/etc/
$ wget https://github.com/strukturag/spreed-webrtc/archive/release-0.27.zip
$ unzip -q release-0.27.zip
$ mv spreed-webrtc-release-0.27/ spreed-webrtc

Damit wurde das heruntergeladene Archiv in den Ordner spreed-webrtc-release-0.27 entpackt. Dieses wurde noch in spreed-webrtc umbenannt, ist aber nicht notwendig. Als nächstes werden zwei Scripte ausgeführt. Das erste generiert die notwendigen Configurationsscripte, das zweite ist ein neu erzeugtes Script.

$ ./autogen.sh

 

Die Ausgabe des Scripts könnte so ähnlich lauten.

autoreconf: Entering directory `.‘
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal –force -I m4
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /usr/bin/autoconf –force
autoreconf: configure.ac: not using Autoheader
autoreconf: running: automake –add-missing –copy –force-missing
configure.ac:47: installing `./install-sh‘
configure.ac:47: installing `./missing‘
Makefile.am: installing `./INSTALL‘
autoreconf: Leaving directory `.‘

 

$ ./configure

 

Dieses Skript prüft ob alle Abhängigkeiten die für den Server gegeben sind. Wir können sehen was noch fehlt und können es nachinstallieren.

checking for a BSD-compatible install… /usr/bin/install -c
checking whether build environment is sane… yes
checking for a thread-safe mkdir -p… /bin/mkdir -p
checking for gawk… gawk
checking whether make sets $(MAKE)… yes
checking whether to disable maintainer-specific portions of Makefiles… yes
checking for a thread-safe mkdir -p… /bin/mkdir -p
checking for a BSD-compatible install… /usr/bin/install -c
checking for grep that handles long lines and -e… /bin/grep
checking for a sed that does not truncate output… /bin/sed
checking for gawk… (cached) gawk
checking for find… /bin/find
checking for gpm… no
checking for jshint… no
checking for python2… /usr/bin/python2
checking for version of python2… 2.6.6
checking for go… /home/justit/.linuxbrew/bin/go
checking for version of Go… 1.6.2
checking third-party Go source code path… /home/justit/tmp/spreed-webrtc/vendor
checking for nodejs… no
checking for node… /usr/local/bin/node
checking for version of node.js… 0.10.43
checking for compass… /home/justit/.gem/ruby/2.3.0/bin/compass
checking for version of compass… 1.0.3
checking for sass… /home/justit/.gem/ruby/2.3.0/bin/sass
checking for version of sass… 3.4.22
checking for scss-lint… /home/justit/.gem/ruby/2.3.0/bin/scss-lint
checking for version of scss-lint… 0.38.0
checking for compass support in sass… ok
checking for autoprefixer… no
configure: WARNING: Please install autoprefixer before trying to build styles.
checking for pybabel… /home/justit/bin/pybabel
checking for version of pybabel… 2.3.4
checking for npm… /usr/local/bin/npm
checking for version of npm… 1.4.29
checking for po2json support in node.js… not available
configure: WARNING: Please install the node.js module po2json to build i18n.
configure: creating ./config.status
config.status: creating Makefile
config.status: creating src/styles/Makefile
config.status: creating src/i18n/Makefile

In diesem Fall ist nur noch weniges zu installieren. Allerdings ist diese Ausgabe erst gemacht worden nachdem eine aktuellere Go (golang) Version 1.6.2 installiert wurde. Auf den Uberspace Servern findet sich eine ältere Version.Last euch nicht von den Voraussetzungen täuschen die auf der GitHub Seite zum WebRTC Server stehen. Es wird eine Go Version auf den CentOS Server benötigt die mindestes Version 1.6.2 ist.

Die erste Anlaufstelle eine neue Go Version zu installieren ist sicher der Paktemanager toast, leider brachte das keinen Erfolg. Daher wurde an dieser Stelle auf den Paketmanager Linuxbrew zurück gegriffen. Die Installation ist im Uberspace Wiki gut beschrieben, daher hier nur die Befehle um Go zu installieren.

$ brew search go
$ brew info go
$ brew install go

Mit dem ersten Befehl suchen wir nach einem Paket für Go. Der zweite Befehl gibt die Version von Go im Linuxbrew-Paket aus. Mit dem dritten Befehl wird das Go-Paket installiert.

Nach dem jetzt eine neue Go-Version installiert wurde, go version zeigt uns das, können die restlichen Abhängigkeiten installiert werden.

 

$ npm install autoprefixer
$ npm install po2json
$ pip2.7 install babel --user

 

Bei einigen Uberspace Usern kann es u.a. noch notwendig sein, folgende Pakete zu installieren (Compass, Sass).

 

$ gem install compass --user
$ gem install sass --user
$ gem install scss-lint --user

 

Nachdem alle Fehlermeldungen beseitigt sind können wir den Server erstellen.

 

$ make

 

Theoretisch kann der Server ab hier mit ./spreed-webrtc-server gestartet werden. Es fehlt aber noch die Konfigurationsdatei, eine Spezielle Datei kann mit -c angegeben werden. Der Defaultwert für die Datei ist aber in diesem Fall ausreichend. Wir erstellen eine Kopie der mitgelieferten Datei und passen sie dann auf unsere Gegebenheiten an. Für den ersten Test (debug) können wir den WebRTC Server auch ohne die NextCloud laufen lassen.

Da der WebRTC Server eine neue Webserver Instanz bildet, müssen wir einen tcp Port sowie einen Port für UDP und TCP, von außen verfügbar machen.

 

$ uberspace-add-port -p tcp --firewall
$ uberspace-add-port -p both --firewall
$ uberspace-list-ports --open

 

Mit dem dritten Befehl, bekommen wir die geöffneten Ports angezeigt (merken).

 

WebRTC Server konfiguration

 

$ cp server.conf.in server.conf
$ vi server.conf

 

Hier wird als Editor jetzt vi verwendet, unter dem Punkt [http] finden wir schon den konfigurierten Eintrag listen. Dort tragen wir die IP-Adresse von unserem Uberspace Server ein, sowie den tcp-Port den wir zuvor geöffnet haben. Mit diesen Einstellungen kann der Server auf Funktion getestet werden.

 

$ ./spreed-webrtc-server

 

Dieser Befehl starten wir den WebRTC Server. In der Konsole können wir einige Warnungen sehen (die Konfiguration ist noch nicht beendet), den WebRTC Server können wir jetzt aber schon ansurfen.

 

http://IP-Adresse:tcp-Port

 

Strg + C beendet den Server wieder und wir können uns an die weitere Konfiguration begeben. Jetzt wird die Spreed.ME App installiert aktuell in Version 0.1.6 zum Download. Die Spreed.ME App befindet sich unter den experimentellen Erweiterungen. Daher müssen diese, falls noch nicht geschehen, links unten in der Ecke über das Zahnrad aktiviert werden. Nach dem die App installiert ist, können wir sie zwar noch nicht verwenden, aber das Konfigurieren kann losgehen!

Die Installation ist sehr ausführlich auf der GitHub Seite des Plug-Ins beschrieben. Anbei werde ich aber meine Konfigurationsänderungen aufzeigen. Nach dem der WebRTC Server für die App konfiguriert wurde, kann man nur noch über die NextCloud (OwnCloud) Seite oder einen Einladungslink (Temporäres Passwort) zur Video Konferenz gelangen.

Als erstes öffnen wir wieder server.conf Datei des WebRTC Server. Ich gehe an dieser Stelle davon aus, dass Ihr eure NextCloud (OwnCloud) nur per https erreicht. Falls noch nicht geschehen wird in diesem Tutorial zumindest beschrieben wie man ein Zertifikat erzeugt, dass man anschließend an eine CA schicken kann um es danach bei Uberspace einzubinden. Da wir im [http] Bereich damit kein ‚listen =‘ mehr benötigen, können wir diesen auskommentieren. Dafür habe ich unter ‚basePath =‘ einen Eintrag gesetzt. Dieser wird sich in der Konfiguration der App an anderer Stelle wiederholen. Im Abschnitt [https] tragen wir die selben Daten bei ‚listen =‚ ein wie zuvor ohne SSL. Nun wird der Pfad zum Zertifikat angegeben. Da der WebRTC Server nachher ja unter dem selben Domainname wie die Cloud zu erreichen ist, kann man hier das selbe Zertifikat verwenden. Die Pfade hier sind nur beispielhaft, sie können auch an anderer Stelle in Eurem Uberspace liegen.

[http]
basePath = /spreed-webrtc/

[https]
listen = <IP-Adresse des Server>:tcp-Port
certificate = /home/USERNAME/Zertifikate/Domainname/Pub-Server.crt
key = /home/USERNAME/Zertifikate/Domainname/Priv-Server.key

Weiter geht es im Bereich [app], hier wird jetzt u.a. die Verbindung zur NextCloud (OwnCloud) Erweiterung hergestellt. Außerdem werden Session-Secrets gesetzt. Diese Secrets kann man sich einfach auf der Konsole z.B. mit xxd -ps -l 32 -c 32 /dev/random erzeugen (steht notfalls auch im server.conf file). Was mir erst im laufe der Einrichtung aufgefallen ist, wird auch ein TURN-Server benötigt. Dieser kann aber auch jetzt schon vorkonfiguriert werden.

[app]
stunURIs = 
turnURIs = turn:<IP-Adresse des Server>:<Port both>?transport=udp
turnSecret = <selbst generierter Schlüssel>
sessionSecret = <selbst generierter Schlüssel>
encryptionSecret = <selbst generierter Schlüssel>
authorizeRoomJoin = true
serverToken = <selbst generierter Schlüssel>
serverRealm = local
extra = /var/www/virtual/USERNAME/NextCloud/apps/spreedme/extra # Pfad zur Cloud-Installation und zum App Verzeichnis
plugin = extra/static/owncloud.js

Als letztes werden jetzt noch einige Einstellungen unter [users] vorgenommen.

[users]
enabled = true
mode = sharedsecret
sharedsecret_secret = <selbst generierter Schlüssel>

 

Spreed.ME Erweiterung konfigurieren

 

Der Server ist soweit konfiguriert. Jetzt geht es an die Spreed.ME Erweiterung. Hierfür wechseln wir jetzt in das config-Verzeichnis der App. Dort finden wir eine config.php.in Datei vor. Diese wird dann kopiert und zum bearbeiten geöffnet.

 

$ cp config.php.in config.php
$ vi config.php

In der Datei werden jetzt folgenden Konfigurationen angepasst.

const SPREED_WEBRTC_ORIGIN = 'https://<nextcloud-domainname>:tcp-Port';
const SPREED_WEBRTC_BASEPATH = '/spreed-webrtc/';
const SPREED_WEBRTC_SHAREDSECRET = '<selber Schlüsse der zuvor unter [users] eingetragen wurde>';
const OWNCLOUD_TEMPORARY_PASSWORD_LOGIN_ENABLED = true;
const OWNCLOUD_TEMPORARY_PASSWORD_SIGNING_KEY = '<selbst generierter Schlüssel>';

Die letzte Konfiguration am Plug-In findet im Ordner ../extra/static/config/ statt. Hier befindet sich die Datei OwnCloudConfig.js.in die wir wieder kopieren und bearbeiten.

$ cp OwnCloudConfig.js.in OwnCloudConfig.js
$ vi OwnCloudConfig.js

 

In dieser Datei wir noch einmal der Domainname der Nextcloud Installation eingetragen. Mit diesem letzten Schritt ist die Konfiguration des Servers sowie der Spreed.ME Erweiterung abgeschlossen.

 

OWNCLOUD_ORIGIN: 'https://cloud.zonedata.de',

 

Turn Server

 

Beim der Turn-Server Installation kann man jetzt erstmal ne kurze Auszeit nehmen. Das einrichten dauert eine weile.

 

$ brew search turn
$ brew info coturn
$ brew install coturn

 

Das Ende einer coturn Installation kann dann so aussehen.

 

######################################################################## 100.0%
==> Caveats
A CA file has been bootstrapped using certificates from the system
keychain. To add additional certificates, place .pem files in
  /home/corellia/.linuxbrew/etc/openssl/certs

and run
  /home/corellia/.linuxbrew/opt/openssl/bin/c_rehash

==> Summary
/home/justit/.linuxbrew/Cellar/openssl/1.0.2h: 1,698 files, 14.5M, built in 5 minutes 24 seconds
==> Installing coturn dependency: libevent
==> Downloading https://linuxbrew.bintray.com/bottles/libevent-2.0.22.x86_64_linux.bottle.tar.gz
######################################################################## 100.0%
==> Pouring libevent-2.0.22.x86_64_linux.bottle.tar.gz
/home/justit/.linuxbrew/Cellar/libevent/2.0.22: 58 files, 1.9M
==> Installing coturn
==> Downloading http://turnserver.open-sys.org/downloads/v4.5.0.3/turnserver-4.5.0.3.tar.gz
######################################################################## 100.0%
==> ./configure --disable-silent-rules --mandir=/home/justit/.linuxbrew/Cellar/coturn/4.5.0.3/share/man --prefix=/home/justit/.linuxbrew/Cellar/coturn/4.5.0.3
==> make install
/home/justit/.linuxbrew/Cellar/coturn/4.5.0.3: 97 files, 4.7M, built in 20 seconds
[justit@hadar spreed-webrtc]$

 

Sobald alles durchgelaufen ist kann der Server konfiguriert werden. Hier liefert die GitHub Seite der Entwickler vom Spreed-WebRTC Server eine gutes Beispielkonfiguration. Bei vielen Einstellungen muss nur das # entfernt werden, die Konfigurationsdatei ist ziemlich groß. Hier wird auch wieder eine Beispielkonfiguration verwendet. Außerdem wir noch ein Symlink dafür erstellt. Evtl. passt der Pfad nicht mehr ganz, weil sich die coturn Version geändert hat.

$ cp /home/$USER/.linuxbrew/Cellar/coturn/4.5.0.3/etc/turnserver.conf.default /home/$USER/.linuxbrew/Cellar/coturn/4.5.0.3/etc/turnserver.conf
$ ln -s /home/$USER/.linuxbrew/Cellar/coturn/4.5.0.3/etc/turnserver.conf /home/$USER/.linuxbrew/etc/turnserver.conf
$ vi /home/$USER/.linuxbrew/Cellar/coturn/4.5.0.3/etc/turnserver.conf

 

listening-port=63804
listening-ip=185.26.156.13
relay-ip=185.26.156.13
fingerprint
lt-cred-mech
use-auth-secret
static-auth-secret=<selbst generierter Schlüssel aus der server.conf>
realm=spreedbox.local
total-quota=100
bps-capacity=0
stale-nonce
cipher-list="ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AES:RSA+3DES:!ADH:!AECDH:!MD5"
no-loopback-peers
no-multicast-peers

 

Daemon Tools

 

Damit jetzt alle Server im Hintergrund Ihr Werk tun, auch wenn der Uberspace-Server mal neu gestartet wird, oder ein Dienst sich ins Nirwana verabschiedet, wird für beide Server ein Service erstellt. Auf die Konfiguration von daemontools wird hier nicht mehr näher eingegangen. Es wurden zwei Scripte erstelle die dann aufgerufen werden.

 

# WebRTC-Skript#!/bin/sh

#WebRTC dir
export WEBRTC=$HOME/etc/spreed-webrtc

cd $WEBRTC
exec ./spreed-webrtc-server 2>&1

 

# coturn Skript
#!/bin/sh

exec /home/justit/.linuxbrew/Cellar/coturn/4.5.0.3/bin/./turnserver 2>&1

 

 

Go

 

Wenn beide Server ordnungsgemäß gestartet sind kann der Audio / Video & Chat Server unter der NextCloud (OwnCloud) je nach Endgerät, in vollem Umfang genutzt werden. Einmal in der Weboberfläche eingeloggt kann man erstmal viele Einstellungen bearbeiten.

 

 

 

 

Alle Angaben sind ohne Gewähr, die Veränderung Ihrer Systeme erfolgt auf eigene Gefahr.

6 Kommentare
  1. Bastian Gülstorf
    Bastian Gülstorf sagte:

    Moin,
    erstmal vielen Dank für die bisher tolle Schritt-für-Schritt Erläuterung. Ich bin jetzt aber bei einem Verständnis Problem angekommen.
    Beim Schritt wo ich die „server.conf“ des WebRTC anpassen will und quasi nur HTTPS zulassen will, habe ich das Problem, dass ich bisher keine TLD bei uberspace eingerichtet habe und nach wie vor die Standard-HTTPS Einrichtung von uberspace verwende.
    Jetzt klingt das aber in dem Text oder auch in dem anderen Blog-Eintrag von dir („Neues SSL Zertifikat bei Uberspace einbinden“) oder auch bei uberspace direkt (wenn ich dort die Let’s Encrypt Variante probieren will) als ob ich zwingend eine TLD oder halt Domain eingetragen haben muss?

    Hab ich das soweit richtig verstanden oder einen Knoten im Kopf?

    Antworten
    • Daniel
      Daniel sagte:

      Hallo Bastian,
      grundsätzlich ist Dein Uberspace ja über https erreichbar. In wie fern Du das Zertifikat für den WebRTC Server verwenden kannst kann ich Dir leider nicht 100% sagen. Da man in der Konfiguration ja das Zertifikat explizit angeben muss. Bei Fragen um das Uberspace eigene TLS-Zertifikat, wende Dich am besten an das Uberspace Team über hallo@uberspace.de. Dort wird Dir im Normalfall schnell und freundlich geholfen.
      So wie Du noch nie eine eigene TLD mit Zertifikat bei Uberspace eingerichtet hast, habe ich noch nie das Uberspace eigene Zertifikat verwendet 😉
      Mein Blogeintrag „Neues SSL Zertifikat bei Uberspace einbinden“ ist lediglich eine Kurzanleitung, wie man dort ein bestehendes Zertifikat, für eine Domain hinterlegen kann. Die Anleitung bezieht sich nicht nur auf den WebRTC-Server.

      Antworten
  2. Timm
    Timm sagte:

    Ich erhalte Abhängigkeitsfehler, s.u. Hast Du eine Idee?

    $ brew install coturn
    ==> Installing dependencies for coturn: glibc, xz, m4, gmp, mpfr, libmpc, isl, gcc, pkg-config, gpatch, ncurses, readline, sqlite, gdbm, openssl, berkeley-db@4, unzip, python, libevent
    ==> Installing coturn dependency: glibc
    Error: glibc cannot be built with any available compilers.
    Install Clang or brew install gcc

    Antworten

Dein Kommentar

An Diskussion beteiligen?
Hinterlasse uns Deinen Kommentar!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.