Wir haben jetzt einen chat server für das Matrix protokoll. Toll ist daran dass es dezentralisiert ist und aber im gegensatz zu XMPP und co saubere end-to-end verschlüsselung mit einem brauchbaren signatur modell für mehrere geräte pro user unsterstützt.
Für desktop/mobile gibt es hier den Element client. Die dazugehörige web-app haben wir auch auf https://riot.it-syndik.at/ laufen wem das lieber ist.
Die Home Server URL für clients ist https://matrix.it-syndik.at, die user IDs haben dann aber die schön kurtze it-syndik.at domain, so wie zb. @fritz-gruber:it-syndik.at.
Registrierung is für alle mit *@it-syndikat.org email addresse offen. Registrieren kann man sich direkt über den web-client (register tab) oder direkt in den desktop/mobile apps.
Wer ne *@it-syndikat.org mail addresse oder einfach nur nen matrix account braucht will bitte bei @dxld melden.
TODO:
IRC bridge für #itsyndikat?, Done.
TURN server für VoIP calls
Aktuell hat er nur so 512M RAM und sqlite db, mal schauen wie viele user das aushaltet. Hat jetzt 1.5G wenn man #matrix:matrix.org joined sauft der synapse sofort wie sau.
Aktuell laufende Synapse version checken: curl https://matrix.it-syndik.at/_synapse/admin/v1/server_version
Riot/Element-web liegt auch in der matrix VM in /var/www/riot/. Das muss noch manuell geupgraded werden via update.sh (link zu post unten) in dem ordner. Das lädt den tarball von Github runter, verifiziert die gpg signatur, packts aus und biegt den /var/www/riot/riot-live symlink um wenn alles gut is.
Matrix HTTP dschungel
Der synapse server hocht auf synapse.it-syndik.at:8448 (aka matrix.parabox.it-syndik.at) und zwar auf seiner nativen IPv6 addr und mit port forwarding auch auf unserer public IPv4 addr. TLS terminiert hier in der matrix VM.
Der yxorp horcht als TLS-SNI tcp reverse proxy auf den diversen matrix domains, nur mit IPv4, und leitet das an die matrix VM über v4 weiter. Auf der v6 seite ist die matix VM direkt im DNS eingetragen. TLS wird hier also auch rein in der matrix VM terminiert. Der trick ist hier auf in der v4 listen direktive proxy_protocol zu aktivieren aber auf v6 nicht.
Unter https://it-syndik.at/.well-known/matrix/server werden andere matrix server (federation) ganz nett gefragt doch bitte direkt mit synapse.it-syndik.at:8448 zu reden. Das dass ein anderes TLS cert is als unter matrix.it-syndik.at is wurscht weil die server nicht mit dem client endpoint reden.
Ich hab jetzt mal den #lobby:it-syndik.at public room gemacht mit der intention den dann zum #itsyndikat IRC channel zu bridgen. Da muss aber noch ein OP ein OPt-in machen
Hab grad bemerkt dass das upgrade von 1.21.2-1~bpo10+1 auf 1.23.0-1~bpo10+1 nicht automatisch passiert is. Turns out: man muss da im Unattended-Upgrade::Origins-Pattern den “Debian Backports” origin auskommentieren, sonst ignoriert unattended-upgrades zeug aus backports einfach.
Hab element-web gerade auch noch von 1.7.13 auf 1.7.15 geupgraded. In dem release hat sich der tarball name zu element-$v.tar.gz geändert und ich hab das update.sh angepasst.
Die 1.7.14 version haben wir gar übersprungen. Muss noch irgendwas aufsetzen das motzt wenn die version out of date is, oder einfach auch auto-update machen.
Element Web/Riot update script
/var/www/riot/update.sh:
#!/bin/sh
set -eu
IFS=
ver=$1; shift || { echo "Usage $0 NEW_VERSION"; exit 1; }
cd "$(dirname "$0")"
verlte() {
[ "$1" = "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" ]
}
if verlte 1.7.15 $ver; then
dir=element-v$ver
tarball=$dir.tar.gz
else
dir=riot-v$ver
tarball=$dir.tar.gz
fi
wget -c https://github.com/vector-im/element-web/releases/download/v$ver/$tarball.asc
wget -c https://github.com/vector-im/element-web/releases/download/v$ver/$tarball
if ! gpgv --keyring ${PWD}/trustedkeys.kbx $tarball.asc $tarball; then
echo
echo Verifying tarball signature failed! Refusing to unpack.
echo
exit 1
fi
tar --one-top-level -xaf $tarball
ln -snf $dir riot-live.tmp
mv -T riot-live.tmp riot-live
echo
echo All good, update is live.
Das update ist jetzt immer noch nicht automatisch passiert. Diesmal hat die APT::Periodic:: config im apt.conf gefehlt. Das kann man entweder mit dpkg-reconfigure unattended-upgrades oder direkt über
einschalte. dpkg-reconfigure schreibt auch einfach in das file.
Zusätzlich ist mir dann noch eingefallen dass ja der synapse service nicht unbedingt restarted wird bei dem upgrade. Dabei kann warscheinlich needrestart helfen. Da bin ich drauf gestoßen dass das ding ne config option hat für “restart zeug einfach”:
/etc/needrestart/needrestart.conf:
# Restart mode: (l)ist only, (i)nteractive or (a)utomatically.
#
# ATTENTION: If needrestart is configured to run in interactive mode but is run
# non-interactive (i.e. unattended-upgrades) it will fallback to list only mode$
#
$nrconf{restart} = 'a';
Ich bin noch nicht sicher ob das den synapse dann wirklich neu startet wenn die maschiene nicht sowieso wegen nem kernel update rebootet. Sehen wir beim nächsten update
Jetzt haben wir auf jeden fall mal synapse 1.24.0.
Ich hab heute endlich mal den TURN server fürs VoIP konfiguriert. Der hat jetzt eine eigene public IP und läuft unter turn.it-syndikat.org.
Leider funktioniert das ganze noch nicht so wie es soll. Authentifizierung der TURN requests scheint zu funktionieren aber verbindungen zwischen zwei clients hinter normalem NAT wollen einfach nicht funktionieren. Das ganze ist leider ziemlich schwierig zu debuggen, weils keine gute test software gibt die ich finden kann. Hrmpf.
Kleines update von der reverse proxy front: Turns out nginx macht bei proxy_pass keine TLS validation per default. Hab das mal eingeschaltet. Das ist jetzt nicht unbedingt kritisch weils ja eh nur durchs hypervisor netzwerk geht aber sein muss das trozdem nicht.
Update: die TLS terminierung ist jetzt ala TLS-SNI reverse proxy für yxorp implementiert. Die matrix VM macht jetzt alle certs selber und yxorp macht nur auf v4 TLS-SNI proxy.
Update (lang verspätet): Seit der parabox apokalypse zickt der matrix server für manche user (mich) rum, verwende (und maintane) den deswegen nicht mehr weil der beschluss gefasst wurde den nicht neu zu deployen um das zu fixen.
Aktueller maintainer? Macht noch wer updates? Not sure. Probably not.
Von synapse auf conduit zu migrieren wäre sicher auch angesichts der feindlichen Übernahme durch New Vector nicht schlecht. Das große Problem dabei sind immer lokale user-accounts, aber wenn die eh broken sind, ists egal.
Checkliste:
lokale room aliases entfernen
lokale user aus allen rooms leaven (z.B. einfach user löschen/disablen)
Also das is jetzt schon etwas überspitzt, die haben das ding ja auch zum großteil entwickelt. Mir passt das zwar auch nicht so recht aber die alternativen implementierungen machen halt dann evtl. wieder probleme.
Ich würde derweil noch bei deren impls. bleiben und switchen if/when das matrix protokoll mal einen stabilen zustand erreicht. Also: nachdem sie IETF MLS implementiert haben oder so ;)
Einmal ist ~keinmal~ nicht maintainen :) Wenn mans keinem sagt kann man dann nicht erwarten dass es wer wisse. Ich hab auch upgrades (fast)immer im meta geloggt solltest dir abschauen.
Server migration tools sind seit Jahren in Arbeit und es gibt immer noch nix annähernd brauchbares, wenn wir Server neu aufsetzen wollen, dann bitte nur einmal.
