technische learnings

 Teil 4

4. Jetzt kommen wir aber tatsächlich zur Technik.

Opensource vom Volume bis zum Mauszeiger. Eine weitere Studie. Eine weitere Herausforderung.

Nachdem wir die Event-Software festgelegt hatten konnten wir alle weiteren Services festnageln. Die meisten der unten angeführten Projekte benötigen noch weitere technische Komponenten bzw. enabling Services, die aber häufig einfach als abhängige Pakete mit installiert und von der Paketverwaltung konfiguriert wurden und so unserer Aufmerksamkeit entgingen. Hier die wichtigsten:

Als Betriebssysteme wählten wir:

Debian 10 als Basis für den Workadventure-Server

Ubuntu 18 / 20.04, unser Standard Server und Desktop OS

Mint 19.3 an unserem Grafik, Blender und Videoschnitt PC

FossaPub auf einem 8Gb USB-Stick als Notfallbetriebssystem während meine Laptop-Festplatte schlapp machte

OpnSense als Firewall mit Failover-Verbindung als unsere Internet Leitung durch einen Baum zerstört wurde

Huawei OS für den mobilen Accesspoint auf den die Firewall beim Leitungsausfall umgeleitet hat

Android um den ADAC, Polizei und Feuerwehr zu Verständigen, als wir in einen schweren Verkehrsunfall verwickelt wurden; Um hunderte Telegram Nachrichten an Opencaching zu versenden, zu empfangen und zu beantworten; Um den einen oder anderen Cache zu verstecken oder zu suchen; Um eine Rede zu halten und via Tablet zum Openstreaming-Server zu übertragen; Um zu testen ob Workadventure auf Tablet und Smartphone möglich ist

und eine Windows 7 64bit Unlimited CD als Kaffeeuntersetzer (Diese wurde während der Arbeiten durch einen Bierdeckel ersetzt, da nicht mal als Kaffeeuntersetzer wirklich brauchbar, außerdem war die Lizenzsituation unklar)

Workadventure als Frontend mit Traefik als reverse Proxy für Docker

Jitsi-Meet (mit Videobridge) als Backend

Nginx als Webserver und Reverse Proxy

Apache2 um die Maps für Workadventure vorzuhalten

CoTurn als separaten STUN/TURN Server um die Trafic-Last von den Jitsi-Servern zu nehmen und zu einem anderen Provider zu lenken und die Kommunikation zwischen gut verstecken Clients zu ermöglichen

OpenStreamingPlattform mit selbst gebruzeltem Nginx mit RTMP-Erweiterung als Ergänzung bzw. Vereinfachung zu Youtube (siehe Artikel zu Streaming)

Icinga2 um die Auslastung und die Verfügbarkeit der Services im Blick zu behalten und mich notfalls via SMS aus dem Bett zu holen

Wekan Kanban Board (Snap) als agile Programmplanung während des Events

Nextcloud als ToDo-Liste, für Abstimmungen, zum Dateiaustausch, als Notizblock und zum sammeln aller Informationen zum 8. HQ

OpenLDAP für die Benutzerlogins

PhpOpenLDAP für die Verwaltung und Erstellung der Benutzerlogins

PhpMyAdmin um alle MySQL Datenbanken zu verwalten

BigBlueButton unsere Standard-Videokonferenz-Software

Kivitendo um unsere anfallenden Rechnungen zu verbuchen

Matomo um das Interesse an unseren Aktivitäten zu sehen

Bind9 um die Workadventure-Domains zu verwalten

Wordpad als Blog-Software und zur Koordination unserer Social Media Aktivitäten

whitebophir als kollaboratives Whiteboard

Joomla um unsere Webseite zu betreiben

MySQL / MariaDB um Daten zu bunkern

PostgresSQL um Daten und Datensicherungen zu bunkern

BareOS und BORG um Datensicherungen zu erstellen

TileED zur Erstellung der Maps

Blender für alle 3d Elemente

GIMP für sämtliche Bildbearbeitung

LibreOffice Texte, Tabellenkalkulationen

Freeplane für meine geliebten Mindmaps

Blufish Editor für HTML, PHP, JavaScript und solchen Kram

GPSBabel und GPSPrune um die Königsseekoordinaten umzurechnen

Shotcut für alle Videobearbeitungen

Filezilla zur Dateiübertragung

KeyPassXC damit wir uns die Passwörter nicht alle merken mussten

Thunderbird um (verschlüsselt) via E-Mail zu kommunizieren

Firefox um die HQ-Welt zu sehen

MidnightCommander zur Serverkonfiguration

OpenSSH zur Serverfernwartung

Zugegeben viele dieser Anwendungen waren schon vorkonfiguriert oder benötigten keine separaten Konfigurationsschritte. Sie waren aber definitiv alle an der Entstehung der HQ-Welt beteiligt.

Widmen wir uns deswegen mal den für den Betrieb wesentlichen Komponenten. Debian und Ubuntu sind entgegen ihres Rufs schnell aufgesetzt und brauchen insbesondere als virtuelle Server kaum Konfiguration. Die Installation der KVM-Basis möchte ich hier nicht im einzelnen beschreiben, da wir die Server nach dem Testbetrieb sowieso zu einem Cloudhoster transferiert hatten. Unseren guten Erfahrungen mit Hetzner sind wir treu geblieben und haben diesen ausgewählt.

Eine Debian 10 Instanz entsteht via Webfrontend in wenigen Sekunden, nach generellen Updates sollte sie betriebsbereit sein. Wenn man wie wir auf Linux-Desktops arbeitet sind alle notwendigen Komponenten zur Fernbetreuung via SSH vorhanden, sonst kann man auch auf die etwas unkomfortablere Web-Konsole zurückgreifen.

Workadventure

Auf Github und bei Workadventu.re sind die Installationsanweisungen etwas dürftig:

Install Docker.

Run: docker-compose up -d

The environment will start.

Diese Aussage ist zwar grundlegend richtig, aber nur wenig hilfreich. Tatsächlich passiert erst mal – wie erwartet – gar nichts bzw. antwortet docker mit einer Fehlermeldung.

Richtiger ist, man konfiguriert passend seine Domäne – ohne die wird es schwierig – das sollte dann in etwa so aussehen:

wa.wimmer.bayern. 600 IN A xxx.xxx.xxx.xxx

api.wimmer.bayern. 600 IN CNAME wa.wimmer.bayern.

back.wimmer.bayern. 600 IN CNAME wa.wimmer.bayern.

pusher.wimmer.bayern. 600 IN CNAME wa.wimmer.bayern.

play.wimmer.bayern. 600 IN CNAME wa.wimmer.bayern.

Dann holt man sich den Inhalt von TCM auf seine eigene Festplatte z.B. nach /opt

cd /opt

git clone https://github.com/thecodingmachine/workadventure.git

cd workadventure

jetzt würde docker-compose up -d und http://play.workadventure.localhost/ vielleicht sogar einem Ziel führen, wir sind aber nicht lokal sondern auf einem entfernten Server. Also bearbeiten wir zuerst .env und docker-compose.yaml

die .env solltet ihr mit euren Daten füllen, als Jitsi-Meet könnt ihr natürlich auch den freien server meet.jit.si verwenden, der braucht jitsi_private_mode, jitsi_iss und jitsi_secret natürlich nicht, den Turn-server ändert ihr auch nur wenn ihr einen habt, eine Domain und Emailadresse sind aber wichtig. Die Start-URL hat mich einige graue Haare gekostet, ist aber, wenn man es verstanden hat, auch simpel. „/_/global/“ ist sozusagen verpflichtend, danach kommt die Url zu eurem Web wo ihr die Map hinterlegt habt, dann der oder die Unterordner und dann die .json datei

In der docker-compose.yaml würde ich die Sektionen maps, uploader und coturn entfernen, die verwirren nur, der integrierte maps-Webserver ist sehr langsam, auch die verweise in den anderen Sektionen, z.B. Uploader URL in Front würde ich auskommentieren . Für maps verwenden wir einen eigenen Webserver, bei Bedarf auch einen separaten coturn server, den uploader lassen wir weg. Hört sich simpel an, hat mich aber einige Wochen Bastelei gekostet.

Den Traefik habe ich auf 2.4 hoch gesetzt, und die Api-UI deaktiviert.

Front, Pusher und Back habe ich auf den Master-Zweig in Github gesetzt, Development lief zwar auch, war mir aber zu heiß. Noch ein wichtiger Tip: .yaml Dateien sind empfindlich was Einrückungen und Tabs betrifft, die müssen stimmen – sonst macht der Server gar nix.

jetzt steht einem docker-compose up -d eigentlich nichts mehr im Wege, docker lädt ziemlich viel herunter und backt die Images wenn alles gut geht könnt ihr jetzt mit play.eure.domain das erste mal in euer Workadventure bzw. in die Default-Map rein schauen.

So weit schaut das simpel aus, die Fehlersuche ist aber die Hölle, da die Fehlermeldungen nicht oder nur dürftig dokumentiert sind.