Das virtuelle Meeting mit OpenMeeting

Für ein Projekt mit mehreren verteilten Entwicklern war es notwendig eine Lösung zu finden die es ermöglicht gemeinsam an Entwürfen für eine Programmoberfläche zu arbeiten.

Verschiedene Lösungen wurden ausprobiert. Die einen bedingten ein Abo, dass man nicht kaufen wollte, die anderen waren etwas suspekt ob der doch heiklen Daten die darüber verschickt wurden. Schließlich sollte die Programmoberfläche ja etwas neues darstellen. Um die Neugierde anderer nicht herauszufordern ging bald der Ruf in meine Richtung ob es nicht etwas gäbe dass folgenden Ansprüchen genügt:

Installiert auf eigenen Servern Über mehrere Betriebsysteme hinweg (Win; MAC; Linux; was noch so geht) Das gleichzeitige Bearbeiten von Bildern soll möglich sein Ein Chat sollte möglich sein Ein Audio- oder Videochat wäre wünschenswert das ganze so abgesichert wie nur irgend möglich….

Nach ein bisschen überlegen und kramen in den Unterlagen die ich so sammle hab ich tatsächlich eine Lösung gefunden die zumindest aus der Ablage die gewünschte Funktionalität verspricht.

Das sollte einen näheren Blick wert sein.

Die Wahl fiel auf OpenMeeting, welches zu meinem eigenem Erstaunen mittlerweile zur Apache Foundation gewechselt wurde/hatte.

Also Installationanleitung durchgesehen. Zielserver wird ein CentOS 6.3 – die Anleitung gibts für CentOS 5. Naja – soviel wird schon nicht unterschiedlich sein.

Was ganz gut klappte war die Grundinstallation an sich.

Folgende Änderungen habe ich vorgenommen:

• Die SOX-Librarys hab ich direkt aus dem Repository übernommen, da diese aktuell genug sind.
• Die Quellen für ffmpeg sind mittlerweile mit git clone git://source.ffmpeg.org/ffmpeg.git ffmpeg zu holen
• Statt OpenOffice.org hab ich LibreOffice direkt aus dem Repository installiert

Die Installation lief dann auch relativ zügig durch und lief prompt nach dem ersten mal.

Nach einem ersten Test im lokalen Netz musste ich allerdings eine „Designschwäche“ feststellen. Da das Ding am Client unbedingt Adobe Flash braucht, könnte sich der Plattformübergreifende Einsatz einschränken. Adobe hat bekannterweise den Flashsupport für Linux eingestellt und bringt nur noch Sicherheitsaktualisierungen aber keine neue Version raus. Ausgewirkt hat sich das bei unseren internen Tests nur beim Hochladen von Dateien auf das Whiteboard. Manche Clients konnten einfach nicht hochladen. Was jetzt genau schuld ist weiß ich noch nicht, werd ich aber noch weiter verfolgen.

Absicherung über SSL

Etwas gefinkelt war allerdings der Wunsch nach SSL-Absicherung der Kommunikation. Geglückt ist es dann schluß endlich mit folgendem Vorgehen:

# In das Conf-Verzeichnis der Installation wechseln
cd /<Installationsverzeichnis>/conf
# Das Verzeichnis "key_generierung" erstellen
mkdir key_generierung
cd key_generierung
# Erst mal ein neues Serverzertifikat erstellen
openssl genrsa -des3 -out server.key 2048
# CSR erstellen damit dieser signiert werden kann
openssl req -new -key server.key -out server.csr
# Zertifik selbst bestätigen für 10 Jahre 
openssl x509 -req -days 3650 -in server.csr -signkey server.key -out server.crt

Soweit so gut – jetzt hat man mal ein normales selbstsigniertes Serverzertifikat. Aber wie bringt man das in den JAVA-Keystore ?

„Ganz“ einfach: Der Keystore liegt nach der OpenMeeting Installation im Verzeichnis <Installationsverzeichnis>/conf/keystore. Also in das /conf – Verzeichnis wechseln und folgendes eingeben

# In das Conf-Verzeichnis der Installation wechseln
cd /<Installationsverzeichnis>/conf
# Erst mal das CSR aus dem Keystore holen
keytool -certreq -keyalg RSA -alias red5 -file red5.csr -keystore keystore
# Eine -eindeutige- Seriennummer generieren
echo 04 > serial.txt
# Den CSR aus dem Keystore mit dem selbst erstelltem Serverkey signieren
openssl x509 -CA key_generierung/server.crt -CAkey key_generierung/server.key -CAserial serial.txt -req -in red5.csr -out red5.cer -days 3650
# Das Serverzertifikat in den Keystore importieren
keytool -import -file key_generierung/server.crt -keystore keystore -alias serverCA
# Das selbsterstellte (!) Serverzertifikat in den vertrauten CA-Store laden
keytool -import -file key_generierung/server.crt -keystore keystore -alias serverCA -trustcacerts
# Das erstellte Serverzeritifikate laden
keytool -import -file red5.cer -keystore keystore -alias red5

Danach noch die Ports in 2 Dateien eintragen:

1) /conf/red5.properties ändern (rtmps.port=5443) und das Kennwort für den Keystore eintragen (rtmps.keystorepass=xyxyXYXYxyxy)

2) /webapps/openmeetings/config.xml den Port zwischen den Tags <rtmpsslport>5443</rtmpsslport> eintragen und die SSL wie Proxy festlegen: <useSSL>yes</useSSL> sowie <proxyType>best</proxyType>

Die entsprechenden Zeilen sind schnell gefunden….

Ist das so weit gelungen, fehlt noch eine Änderung in /conf/red5-core.xml. Dort müssen die Kommentarzeilen um den Block RTMPS entfernt werden. Der Anfang eines Kommtares in XML-Dateien wird damit eingeleitet <!– und das Ende mit –> festgelegt. Beide Kommentarzeilen löschen und Datei wieder speichern. Somit ist einer gesicherten Übertragung mit RTMPS nichts mehr im Wege stehen.

Wer jetzt noch das Webinterface über SSL absichern will (und Ihr wollt 😀 ) hat noch ein paar Schritte zur Vollkommenheit:

1. Kopieren der bestehenden /conf/jee-container-ssl.xml Datei auf die existierende /conf/jee-contaniner.xml (evntuell vorher wegsichern ? kann nicht schaden….)
2. Ändern des Tags <protocol>http</protocol> auf <protocol>https</protocol>
3. Das Port mittels https.port=443 in /conf/red5.properties eintragen

OpenMeeting neu starten und es sollte nun Verschlüsselt klappen.

Viel Spaß dabei…..