diff --git a/online-werkzeuge-admin.pdf b/online-werkzeuge-admin.pdf
index 2c351b5ec22639f0389abda12f5df8616033a0cc..185396ba3d1da906527296d34d0b52d1e0bc0ecd 100644
Binary files a/online-werkzeuge-admin.pdf and b/online-werkzeuge-admin.pdf differ
diff --git a/online-werkzeuge-admin.tex b/online-werkzeuge-admin.tex
index 90b76385d90d57f2606395b9ad144af1e8b51b7d..127975ee79e595be19b27070d17b92640d285a6f 100644
--- a/online-werkzeuge-admin.tex
+++ b/online-werkzeuge-admin.tex
@@ -28,6 +28,13 @@
\newcommand{\sep}{~$\cdot$~}
\newcommand{\mylicense}{CC-by-sa (Version 3.0) oder GNU GPL (Version 3 oder höher)}
+\lstdefinestyle{terminal}{basicstyle=\small\ttfamily\color{darkgreen},
+ language={},
+ columns=fixed,
+ moredelim=**[is][\color{darkred}]{¡}{¿},
+ moredelim=**[is][\color{blendedblue}]{°}{¿},
+ moredelim=**[is][\sffamily\it\lstset{columns=fullflexible}]{²}{¿}}
+
\begin{document}
\makebox(0,0.005)[tl]{\includegraphics[scale=0.72]{logo-hochschule-bochum-cvh-text-v2.pdf}}\hfill
@@ -104,7 +111,7 @@
\item
Wir haben einige proprietäre Online-Kommunikationswerkzeuge ausprobiert
und können das oft behauptete Plus an Funktionsumfang und Stabilität
- unter gleichen Bedingungen nicht bestätigen.
+ \emph{unter gleichen Bedingungen\/} nicht bestätigen.
(So darf man zum Beispiel ein Web-Interface
nur mit einem anderen Web-Interface vergleichen,
nicht jedoch mit einer installierten Software.)
@@ -165,8 +172,8 @@
\section{Let's Encrypt}
- Die diversen Online-Dienste benötigen X.509-Zertifikate.
-% Oft laufen die Dienste auf separaten (virtuellen) Rechnern.
+ Für sichere Verbindungen mittels TLS
+ benötigen die Online-Dienste X.509-Zertifikate.
Wir zeigen hier, wie man mit Hilfe von \newterm{Let's Encrypt}
sichere Zertifikate erhält.
@@ -181,7 +188,7 @@
In unserem Beispiel läuft der DNS-Server auf einem Rechner \file{comm-0},
der \term{Let's Encrypt\/}-Client hingegen auf einem anderen Rechner \file{main-1},
- auf dem letztlich das Zertifikat benötigt wird.
+ auf dem tatsächlich das Zertifikat benötigt wird.
Die Installation erfolgt mittels:
\begin{lstlisting}[style=terminal]
@@ -225,12 +232,27 @@
Zum Aktualisieren des DNS-Records wird einmalig \file{dnssec-keygen}
(Installation mittels \lstinline[style=cmd]{apt install bind9utils}) und
jedesmal \file{nsupdate} (\lstinline[style=cmd]{apt install dnsutils}) benötigt.
- Nach dem Erstellen des Schlüssels in \file{/etc/bind} (Kommando s.\,u.)
- und der Konfiguration des Rechners \file{comm-0} kann das Update erfolgen.
+
+ \goodbreak
+
+ Wir erstellen zunächst im Verzeichnis \file{/etc/bind}
+ mit \file{dnssec-keygen} einen Schlüssel:
+ \begin{lstlisting}[style=terminal]
+ root@main-1:/etc/bind# ¡dnssec-keygen -a hmac-sha512 -b 512 -n host \
+ main-1.$DOMAIN¿
+ \end{lstlisting}
+ (Auch hier muß \lstinline[style=cmd]{$DOMAIN} durch
+ die von Ihnen verwendete Internet-Domain ersetzt werden.)
+
+% Nach dem Erstellen des Schlüssels in \file{/etc/bind} (Kommando s.\,u.)
+% und der Konfiguration des Rechners \file{comm-0} kann das Update erfolgen.
+
+ Für das dynamische DNS-Update verwenden wir das folgende Shell-Skript:
\begin{lstlisting}[style=terminal]
root@main-1:~# ¡cat /usr/local/sbin/letsencrypt_dns_update¿
#!/bin/bash
- # Generate key using: dnssec-keygen -a hmac-sha512 -b 512 -n host ¡main-1.$DOMAIN¿
+ # Generate key using:
+ # dnssec-keygen -a hmac-sha512 -b 512 -n host ¡main-1.$DOMAIN¿
if [ -z "$CERTBOT_DOMAIN" ] || [ -z "$CERTBOT_VALIDATION" ]
then
@@ -240,7 +262,8 @@
HOST="_acme-challenge"
- /usr/bin/nsupdate -k /etc/bind/keys/Kmain-1.¡$DOMAIN¿.+165+52870.private << EOM
+ /usr/bin/nsupdate -k \
+ /etc/bind/keys/Kmain-1.¡$DOMAIN¿.+165+52870.private << EOM
server comm-0.¡$DOMAIN¿
zone ${HOST}.${CERTBOT_DOMAIN}
update delete ${HOST}.${CERTBOT_DOMAIN} TXT
@@ -249,43 +272,43 @@
EOM
echo ""
\end{lstlisting}
+ Der auf \file{main-1} erzeugte Schlüssel
+ muß natürlich von \file{comm-0} auch akzeptiert werden.
+ Hierzu tragen wir in die Datei \file{/etc/bind/named.conf.local} folgendes ein:
+ \begin{lstlisting}[style=terminal]
+ zone "_acme-challenge.mumble.¡$DOMAIN¿" {
+ type master;
+ file "/etc/bind/dynamic/db._acme-challenge.mumble.¡$DOMAIN¿";
-\iffalse
-
-## comm-0
-
-Der auf main-1 erzeugte Key muss natürlich von comm-0 auch akzeptiert werden:
+ # look for dnssec keys here:
+ key-directory "/etc/bind";
-root@comm-0:~# grep -A6 -F mumble.¡$DOMAIN¿ /etc/bind/named.conf.local; grep '^include .*main-1' /etc/bind/named.conf.local
-zone "_acme-challenge.mumble.¡$DOMAIN¿" {
- type master;
- file "/etc/bind/dynamic/db._acme-challenge.mumble.¡$DOMAIN¿";
+ allow-update { key main-1.¡$DOMAIN¿; };
+ };
- # look for dnssec keys here:
- key-directory "/etc/bind";
+ include "/etc/bind/keys/key.main-1.¡$DOMAIN¿";
- allow-update { key main-1.¡$DOMAIN¿; };
-};
-include "/etc/bind/keys/key.main-1.¡$DOMAIN¿";
+ root@comm-0:~# cat /etc/bind/keys/key.main-1.¡$DOMAIN¿
+ key main-1.¡$DOMAIN¿. {
+ algorithm HMAC-SHA512;
+ secret "$KEY_AUS_/etc/bind/keys/Kmain-1.¡$DOMAIN¿.+165+52870.private_AUF_MAIN-1";
+ };
+ \end{lstlisting}
-root@comm-0:~# cat /etc/bind/keys/key.main-1.¡$DOMAIN¿
-key main-1.¡$DOMAIN¿. {
- algorithm HMAC-SHA512;
- secret "$KEY_AUS_/etc/bind/keys/Kmain-1.¡$DOMAIN¿.+165+52870.private_AUF_MAIN-1";
-};
+\iffalse
Damit die eigentliche Challenge direkt beim eigenem DNS-Server abgefragt
wird (um Verzögerungen durch den nötigen AXFR-Transfer zu umgehen, wird
der entsprechende DNS-Eintrag auf den sonst für cvh-server.de benutzten
Servern auf unseren eigenen Server delegiert), außerdem muss
-mumble.¡$DOMAIN¿ natürlich einen CNAME oder A-Eintrag erhalten:
+mumble.cvh-server.de natürlich einen CNAME oder A-Eintrag erhalten:
-root@comm-0:~# grep -F mumble /var/lib/bind/db.¡$DOMAIN¿
+root@comm-0:~# grep -F mumble /var/lib/bind/db.cvh-server.de
mumble IN CNAME main-0
_acme-challenge.mumble IN NS dns-0
Aus Sicherheitsgründen wollen wir Port 53 aber von dort nicht allgemein
-beantworten, sondern uns eigentlich auf die \term{Let's Encrypt\/}-Server
+beantworten, sondern uns eigentlich auf die Letsencrypt-Server
beschränken. Leider scheinen deren Anfragen nun von sehr vielen
verschiedenen Amazon-Servern zu kommen (siehe root@root-1:~# grep -F
letsencrypt /etc/iptables.rules, welches aktuell unvollständig ist),
@@ -296,6 +319,285 @@ außen erlaubt.
TODO: Schöner lösen!
+# Mumble
+
+Läuft auf main-1.cvh-server.de.
+
+apt install mumble-server
+
+Standardmäßig besetzt Mumble den Port 64738. Da ich zwei unabhängige
+Server haben wollte, läuft auf der VM eine zweite Instanz auf Port
+64739. Die Hardware auf der die VM läuft, hat zwei offizielle
+IP-Adressen, dort wird das jeweils wieder nach außen unter Port 64738 angeboten.
+
+## root-0:
+root@jitsi:~# grep mumble /etc/iptables.rules
+-A PREROUTING -d 88.99.194.201/32 -p tcp -m multiport --dports 1191,1935,8888,64738 -m comment --comment main-1,..,fex,mumble -j DNAT --to-destination 192.168.137.11
+-A PREROUTING -s 130.180.23.228/30 -d 88.99.194.201/32 -p udp -m multiport --dports 5060,64738 -m comment --comment sip,mumble -j DNAT --to-destination 192.168.137.11
+-A PREROUTING -d 88.99.194.245/32 -p tcp -m tcp --dport 64738 -m comment --comment second-0-mumble -j DNAT --to-destination 192.168.137.11:64739
+-A PREROUTING -d 88.99.194.245/32 -p udp -m udp --dport 64738 -m comment --comment second-0-mumble -j DNAT --to-destination 192.168.137.11:64739
+
+## Konfiguration auf main-0
+Konfiguration der vorkonfigurierten Instanz geschieht durch /etc/mumble-server.ini.
+
+Die Zweit-Instanz wird durch /etc/mumble-server2.ini konfiguriert. Ich habe zum Starten das Init-Skript kopiert und angepasst:
+
+root@main-1:~# diff --unified /etc/init.d/mumble-server{,2}
+--- /etc/init.d/mumble-server 2019-02-28 17:36:21.000000000 +0100
++++ /etc/init.d/mumble-server2 2020-03-17 13:59:37.916856121 +0100
+@@ -1,7 +1,7 @@
+ #! /bin/sh
+ #
+ ### BEGIN INIT INFO
+-# Provides: mumble-server
++# Provides: mumble-server2
+ # Required-Start: $network $local_fs $remote_fs
+ # Required-Stop: $network $local_fs $remote_fs
+ # Should-Start: $mysql dbus
+@@ -13,7 +13,7 @@
+ ### END INIT INFO
+
+ PATH=/sbin:/bin:/usr/sbin:/usr/bin
+-NAME=mumble-server
++NAME=mumble-server2
+ DESC="Mumble VoIP Server"
+ PIDDIR=/run/$NAME
+ PIDFILE=$PIDDIR/$NAME.pid
+@@ -23,7 +23,7 @@
+
+ test -x $DAEMON || exit 0
+
+-INIFILE=/etc/mumble-server.ini
++INIFILE=/etc/mumble-server2.ini
+ DAEMON_OPTS="-ini $INIFILE"
+ MURMUR_USE_CAPABILITIES=0
+ MURMUR_LIMIT_NOFILE=0
+
+Wichtig: Es reicht nicht, die Angabe des PIDFILE dort anzupassen. Dies
+muss auch in der ini-Datei passieren, wichtig ist es auch eine getrennte
+Datenbank zu benutzen:
+
+--- /etc/mumble-server.ini 2020-03-15 23:45:20.694309575 +0100
++++ /etc/mumble-server2.ini 2020-03-15 23:44:17.324835415 +0100
+@@ -13,7 +13,7 @@
+
+ ; Path to database. If blank, will search for
+ ; murmur.sqlite in default locations or create it if not found.
+-database=/var/lib/mumble-server/mumble-server.sqlite
++database=/var/lib/mumble-server/mumble-server2.sqlite
+
+ ; Murmur defaults to using SQLite with its default rollback journal.
+ ; In some situations, using SQLite's write-ahead log (WAL) can be
+@@ -102,13 +102,13 @@
+ ; logs to the file 'murmur.log'. If you leave this field blank
+ ; on Unix-like systems, Murmur will force itself into foreground
+ ; mode which logs to the console.
+-logfile=/var/log/mumble-server/mumble-server.log
++logfile=/var/log/mumble-server/mumble-server2.log
+
+ ; If set, Murmur will write its process ID to this file
+ ; when running in daemon mode (when the -fg flag is not
+ ; specified on the command line). Only available on
+ ; Unix-like systems.
+-pidfile=/run/mumble-server/mumble-server.pid
++pidfile=/run/mumble-server2/mumble-server2.pid
+
+ ; The below will be used as defaults for new configured servers.
+ ; If you're just running one server (the default), it's easier to
+@@ -120,7 +120,7 @@
+ welcometext="<br />Welcome to this server running <b>Murmur</b>.<br />Enjoy your stay!<br />"
+
+ ; Port to bind TCP and UDP sockets to.
+-port=64738
++port=64739
+
+## Letsencrypt
+Standardmäßig läuft Mumble mit einem selbst-signiertem Zertifikat, was
+zu Warnmeldungen beim ersten Verbinden führt und dem damit verbundenen
+Sicherheitsverlust. Die Erlangung eines entsprechenden Zertifikats wurde
+bereits oben beschrieben. Um das Zertifikat und den Schlüssel für Mumble
+zu nutzen, wird es mit dem folgenden Skript installiert:
+root@main-1:~# cat /usr/local/sbin/letsencrypt-install-new-keys
+#!/bin/sh
+
+install -m 644 -o root -g mumble-server /etc/letsencrypt/live/mumble.cvh-server.de/fullchain.pem /var/lib/mumble-server/cert.pem
+install -m 640 -o root -g mumble-server /etc/letsencrypt/live/mumble.cvh-server.de/privkey.pem /var/lib/mumble-server/privkey.pem
+
+systemctl force-reload mumble-server
+
+## Benutzerverwaltung
+
+Zu Beginn existiert in Mumble lediglich der Benutzer SuperUser. Neue
+Benutzer*innen können sich direkt mit dem Mumble-Server verbinden und
+dann mittels des Menüpunktes Self->Register ihr beim Starten des
+Mumble-Clients erzeugtes (oder von einem anderen Rechner importiertes)
+Zertifikat mit dem aktuell verwendeten Benutzernamen verknüpfen.
+
+Mit dem Mumble-Client kann der SuperUser dann genutzt werden, um die
+entsprechenden Personen in eine neu erstellte privilegierte Gruppe
+"lehrende" aufzunemen und diesen Rechte zu geben, die es z.B.
+ermöglichen, störende Teilnehmer*innen eines Gesprächs ggf.
+stummzuschalten oder auszuschließen.
+
+
+# OpenMeetings
+
+Da die Installationsanleitungen für OpenMeetings von der Installation
+auf einem Ubuntu-System ausgehen und andere Softwarepakete (insb. ros)
+gezeigt haben, dass für Ubuntu vorgesehene Software u.U. nur
+problematisch auf einem Debian GNU/Linux zum Laufen zu bringen ist,
+wurde hierfür eine VM auf Ubuntu-Basis installiert:
+
+root@root-1:~# xen-create-image --size=15Gb --swap=4096Mb --memory=4096Mb --maxmem=4096Mb --dist=bionic --ip=192.168.137.90 --no-pygrub --hostname=ubuntu-0.cvh-server.de --mirror=http://mirror.hetzner.de/ubuntu/packages
+
+Bei der Anleitung wurde im Wesentlichen
+https://cwiki.apache.org/confluence/display/OPENMEETINGS/Tutorials+for+installing+OpenMeetings+and+Tools?preview=/27838216/140774282/Installation%20OpenMeetings%205.0.0-M3%20on%20Ubuntu%2018.04%20LTS.pdf
+gefolgt, allerdings wurde ffmpeg nicht selbst kompiliert, sondern aus
+den Paketquellen installiert.
+
+## Kurento Media Server
+
+Der Kurento-Media-Server ist für die Verarbeitung von Medienströmen
+(Audio-, Video- und Screensharing-Streams) notwendig und wird von
+OpenMeetings verwendet. Damit Medienströme weitergeleitet werden können,
+obwohl sich sowohl OpenMeetings als auch i.d.R. die Teilnehmenden hinter
+einem NAT befinden, wird dieser so konfiguriert, dass er Zugriff auf
+einen TURN-Server besitzt.
+
+root@ubuntu-0:~# grep ^turnURL /etc/kurento/modules/kurento/WebRtcEndpoint.conf.ini
+turnURL=kurento:$TURN_PASSWORT@88.99.194.201:3478
+
+### Coturn
+
+Dieser TURN-Server wird außerhalb einer VM direkt auf dom0 (siehe
+https://en.wikipedia.org/wiki/Xen) mittels 'apt install coturn'
+installiert, die verwendete Konfiguration lautet:
+
+root@root-1:~# cat /etc/turnserver.conf
+listening-port=3478
+tls-listening-port=5349
+fingerprint
+lt-cred-mech
+user=kurento:$TURN_PASSWORT
+realm=root-0.cvh-server.de
+total-quota=100
+stale-nonce
+cert=/etc/ssl/le/fullchain.pem
+pkey=/etc/ssl/le/privkey.pem
+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
+verbose
+
+## Raumkonfiguration
+
+Räume und Benutzer wurden über die Weboberfläche angelegt, da keine
+einfache Möglichkeit gefunden wurde, die Lehrenden jeweils automatisch
+zu Moderatoren zu machen, wurden diese jeweils über ein Shellskript zu
+Moderatoren jeden Raumes ernannt. Nach Anwendung ist einmalig
+root@ubuntu-0:~# /etc/init.d/tomcat3 restart
+auszuführen.
+
+root@ubuntu-0:~# cat /usr/local/sbin/give_rights_to_all_lecture_rooms
+#!/bin/sh
+(for user in 2 5 6 7 8 12 30 31 32 33 34 35; do
+for room in $(seq 21 32); do
+echo "insert into room_moderator (roomId, user_id) values ($room, $user);"
+done
+done) | mysql --database=open503 -B
+
+# NoVNC
+
+Installation mittels 'apt install novnc'.
+
+## systemd
+
+Um mehrere Räume bereitstellen zu können, wird ein entsprechendes Skript
+für systemd geschrieben. Dies lässt NoVNC dauerhaft laufen, alternativ
+wäre auch eine Aktivierung beim Kontaktaufbau zum entsprechenden
+TCP-Socket denkbar.
+
+root@main-0:~# cat /etc/systemd/system/novnc@.service
+[Unit]
+Description = start noVNC service %i
+After=syslog.target network.target
+
+[Service]
+Type=simple
+User=novnc
+ExecStart = /usr/local/sbin/hsbo_novnc %i
+
+[Install]
+WantedBy=multi-user.target
+
+root@main-0:~# cat /usr/local/sbin/hsbo_novnc
+#!/bin/bash
+
+i=$1; shift
+exec /usr/share/novnc/utils/launch.sh --listen $((6080 + $i)) --vnc localhost:$((5900 + $i)) $*
+
+Wir wollen 13 Instanzen, diese werden mittels
+root@main-0:~# for i in $(seq 0 12); do systemctl start novnc@$i; systemctl enable novnc@$i;done
+gestartet und dauerhaft aktiviert (sodass sie nach einem Reboot wieder zur Verfügung stehen).
+
+## Apache
+
+NoVNC soll hinter einem Apache-Proxy bleiben. Zur Kommunikation werden WSS (secure Websockets) benötigt.
+Daher müssen mittels 'a2enmod proxy_wstunnel proxy_http' die entsprechenden Module aktiviert werden.
+
+Die entsprechende Apache-Konfiguration sieht so aus, die Verbindungen sollen grundsätzlich verschlüsselt passieren:
+
+root@main-0:~# cat /etc/apache2/sites-enabled/novnc.cvh-server.de.conf
+<VirtualHost _default_:80>
+ ServerAdmin webmaster@cvh-server.de
+ ServerName novnc.cvh-server.de
+ ServerAlias www.novnc.cvh-server.de
+
+ Redirect / https://novnc.cvh-server.de/
+
+ ErrorLog ${APACHE_LOG_DIR}/novnc.cvh-server.de-error.log
+ LogLevel warn
+ CustomLog ${APACHE_LOG_DIR}/novnc.cvh-server.de-access.log combined
+
+</VirtualHost>
+
+<VirtualHost _default_:443 _default_:8443>
+ ServerAdmin webmaster@cvh-server.de
+ ServerName novnc.cvh-server.de
+ ServerAlias www.novnc.cvh-server.de
+
+ ProxyPass /websockify ws://localhost:6080/websockify
+ ProxyPassReverse /websockify ws://localhost:6080/websockify
+
+ ProxyPass /websock/0/ ws://localhost:6080/websockify
+ ProxyPassReverse /websock/0/ ws://localhost:6080/websockify
+
+ ProxyPass /websock/1/ ws://localhost:6081/websockify
+ ProxyPassReverse /websock/1/ ws://localhost:6081/websockify
+
+…
+ ProxyPass /websock/12/ ws://localhost:6092/websockify
+ ProxyPassReverse /websock/12/ ws://localhost:6092/websockify
+
+ ProxyPass / http://localhost:6080/
+ ProxyPassReverse / http://localhost:6080/
+
+ ErrorLog ${APACHE_LOG_DIR}/novnc.cvh-server.de-error.log
+ LogLevel warn
+ CustomLog ${APACHE_LOG_DIR}/novnc.cvh-server.de-access.log combined
+ SSLEngine on
+</VirtualHost>
+
+
+Auf die einzelnen Räume kann jetzt über URLs der Form
+
+https://novnc.cvh-server.de/vnc.html?host=novnc.cvh-server.de&port=443&path=websock/0/&reconnect=1&resize=scale
+https://novnc.cvh-server.de/vnc.html?host=novnc.cvh-server.de&port=443&path=websock/1/&reconnect=1&resize=scale
+…
+https://novnc.cvh-server.de/vnc.html?host=novnc.cvh-server.de&port=443&path=websock/12/&reconnect=1&resize=scale
+
+zugegriffen werden.
+
\fi
\emph{(Fortsetzung folgt.)}