Zuletzt geändert von René Schmidt am 2023/09/20 13:20

Zeige letzte Bearbeiter
1 (% class="jumbotron" %)
2 (((
3 (% class="container" %)
4 (((
5 = Matrix-Synapse =
6
7 Matrix ist ein neues Kommunikationssystem, allerdings nicht mit dem Anspruch, das nächste coole, hippe Teil zu werden, sondern Matrix setzt von Anfang an auf Integration und will Brücken zu anderen Systemen bauen.
8
9 Die Kommunikation im Internet hat sich leider zu einer zerklüfteten Inselwelt entwickelt, in der jede Gruppe mit ihrem eigenen System arbeitet und inkompatibel zur Außenwelt ist. Da der Umzug von einem Netzwerk in ein anderes umständlich ist und viele Netzwerke ihre speziellen Vorteile haben, will Matrix die Nutzer eben dort nicht wegholen, sondern dort erreichen. Jeder darf das System nutzen, das ihm gefällt – egal ob XMPP, IRC, Whatsapp, Telegram, Hangouts, Facebook oder SMS – und Matrix kommuniziert mit ihnen. Ein Ansatz, der mir wahnsinnig gut gefällt!
10
11 Wer sich Matrix erst einmal nur ansehen will, kann den Webclient Element benutzen und einen öffentlichen Raum wie #matrix:matrix.org oder #linux:matrix.org besuchen. Wem es dann gefällt, der kann sich einen eigenen Zugang einrichten, am besten auf einem der alternativen Server aus dem Hello-Matrix-Verzeichnis, damit im Netzwerk nicht ein riesiger Klumpen bei matrix.org entsteht.
12
13 An Matrix ist aber auch das gute, dass sich jeder leicht seinen eigenen Server einrichten kann, so dass alle Daten in der eigenen Hand liegen. Eine Anleitung dafür befindet sich unter anderem in Kuketz‘ Blog, in der Dokumentation von Matrix-Synapse und hier auf dieser Seite.
14 )))
15 )))
16
17 (% class="row" %)
18 (((
19 (% class="col-xs-12 col-sm-8" %)
20 (((
21 = Gründe für Matrix und dessen Nutzung =
22
23 Früher habe ich für fast alle Kurzkommunikation mit anderen Menschen Whatsapp und Jabber/XMPP genutzt, aber mit beiden Systemen hatte ich Probleme, für die ich keine Lösung gefunden habe. Wichtig ist für mich, dass ich unterwegs am Handy, daheim am Laptop oder manchmal auch spontan an einem anderen Rechner (z. B. am Arbeitsplatz) Mitteilungen lesen oder schreiben kann.
24
25 Mit Matrix habe ich eine Lösung gefunden, die meinen Wünschen am besten gerecht wird. Mit dem Server Synapse konnte ich relativ schnell und einfach einen eigenen Home-Server einrichten, der mich unabhängig vom Wohlwollen anderer macht. Zur Nutzung von Matrix gibt es über F-Driod die App Element fürs Handy und am Laptop nutze ich Element als Webclient, was mir den Vorteil bietet, dass ich von überall darauf zugreifen kann.
26
27 Für die Teilnahme an Matrix ist auch keine Telefonnummer und keine E-Mailadresse notwendig. Man kann solche Merkmale mit seinem Konto verknüpfen und in einem Verzeichnis eintragen, aber man muss es nicht tun.
28
29 Bisher (April 2019) ist die Verschlüsselung von Matrix noch in Entwicklung, aber ich benutze sie ohne gravierende Probleme – einfach in den Raumeinstellungen aktivieren. Für Matrix findet jede Kommunikation in einem Raum statt, in dem man sich selbst und beliebig viele andere Personen befinden können; man kann auch allein in einem Raum bleiben und auf diese Weise Notizen zwischen Geräten austauschen oder unterschiedliche Räume mit der gleichen Person zu verschiedenen Themen betreiben.
30
31 Über Matrix lassen sich Bilder, Videos und Dateien versenden und diese werden über den Home-Server (nicht über einen zusätzlichen Upload-Server) ausgetauscht, so dass Inhalte vom Handy auch im Verlauf am Laptop und umgekehrt zu sehen sind. Durch diese Synchronisation über den Home-Server werden auch gelesenen Nachrichten vom Handy am Laptop nicht wieder vorlegt.
32
33 In Räumen kann man eine URL-Vorschau aktivieren, so dass im Verlauf eine Info zur Webseite eingeblendet wird. Diese wird vom Home-Server generiert, wodurch der Webseite nicht die IP-Adresse des Clients verraten wird. Die Vorschau wird für alle URLs in einer Nachricht angezeigt und wenn sie stört, kann man sie ausblenden.
34
35 Für Textnachrichten unterstützt Matrix die Formatierung mit Markdown, was in Gesprächen über Programmausgaben oder Dateieinträge richtig von Vorteil ist, bis dahin dass an der Box für Blockcode ein Knopf zum Kopieren hängt. Weiterhin gibt es eine Unterstützung für die Eingabe von Emojis und es lassen sich Sticker versenden.
36
37 Eine Nachricht kann man auch im Nachhinein löschen (bearbeiten ist geplant) und mit der notwendigen Berechtigung sogar die Nachrichten anderer, um größere Runden entsprechend zu moderieren. Für öffentliche Räume kann der Verlauf über die Webseite view.matrix eingesehen werden. Weiterhin kann man mit Element über Räume auch Telefonate und Videokonferenzen führen oder den Bildschirm übertragen.
38
39 == Der Home-Server ==
40
41 Weitere Informationsquellen
42
43 Eine umfangreiche Einführung in Matrix für Nutzer der TU Dresden.
44 Eine Erklärung zu Matrix, die detaillierter auf Fragen zur Implementierung von Matrix und der Verschlüsselung, der Unternehmensstruktur der entwickelnden Firma New Vector, Datenschutz und anderen Themen eingeht.
45 Serververzeichnis Matrix Public Homeservers mit einer Liste öffentlicher Bridges (Telegram, Discord, Twitter u. s. w.)
46 Raumverzeichnisse:
47 grin.hu
48 Nordgedanken
49 Matrix Traveler
50 Space-Verzeichnis
51 Übersicht zu Paketen von Matrix-Clients und -Server in Debian
52
53 == Home-Server einrichten ==
54
55 Synapse unter Debian einrichten / Backup erstellen: https:~/~/decatec.de/home-server/matrix-synapse-backups-erstellen-und-wiederherstellen-manuell-oder-per-skript/
56
57 Wer Debian-Buster einsetzt, kann sich über Backports nur eine veraltete Version von Synapse installieren. Auch in Bullseye wird Synapse nicht direkt enthalten sein, weil so häufig neue Versionen erscheinen, die nicht zum Zweijahreszyklus von Debian passen.
58
59 Gegenwärtig (Juni 2021) in der Freeze-Phase für Bullseye wird die Version in Backports auch nicht mehr aktualisiert, weshalb man Fasttrack einsetzen muss:
60
61 (% class="box" %)
62 (((
63 % echo 'deb http:~/~/ftp.de.debian.org/debian/ buster-backports main' |sudo tee -a /etc/apt/sources.list
64 % sudo apt update
65 % sudo apt install -t buster-backports fasttrack-archive-keyring
66 )))
67
68 (% class="box" %)
69 (((
70 % echo 'deb http:~/~/fasttrack.debian.net/debian/ buster-fasttrack main' |sudo tee -a /etc/apt/sources.list
71 % sudo apt update
72 % sudo apt install -t buster-backports matrix-synapse/buster-fasttrack
73 )))
74
75 Für ältere Versionen bietet das Matrix-Projekt ein Repository an. Damit ist die Installation und die Aktualisierung gewohnt einfach.
76
77 (% class="box" %)
78 (((
79 % curl https:~/~/packages.matrix.org/debian/matrix-org-archive-keyring.gpg |sudo dd of=/etc/apt/trusted.gpg.d/matrix-org.gpg
80 % echo "deb https:~/~/packages.matrix.org/debian/ stretch main" |sudo tee -a /etc/apt/sources.list
81 % sudo apt update && sudo apt install matrix-synapse-py3
82 )))
83
84 Die Einstellungen für Synapse sind in der Datei /etc/matrix-synapse/homeserver.yaml. Hier sind nur die relevanten Anpassungen gezeigt, aber besser ist es, sich die vollständige Datei anzusehen.
85
86 (% class="box" %)
87 (((
88 public_baseurl: https:~/~/alea.gnuu.de/
89 admin_contact: 'mailto~:admin@example.org'
90 )))
91
92 (% class="box" %)
93 (((
94 database:
95 name: psycopg2
96 args:
97 dbname: matrix
98 user: matrix-synapse
99 host: /run/postgresql
100 application_name: synapse
101 )))
102
103 (% class="box" %)
104 (((
105 url_preview_enabled: true
106 url_preview_ip_range_blacklist:
107 - '127.0.0.0/8'
108 - '10.0.0.0/8'
109 - '172.16.0.0/12'
110 - '192.168.0.0/16'
111 - 'fe80::/10'
112 )))
113
114 (% class="box" %)
115 (((
116 enable_metrics: false
117 macaroon_secret_key: "Geheimen Schlüssel mit `pwgen -s 64 1` erzeugen"
118 expire_access_token: true
119 )))
120
121 Bei Matrix geschieht der Abruf der URL-Vorschau vom Server, was gegenüber Whatsapp den Vorteil hat, dass die Adresse des Nutzers nicht durch Versenden von Links erspäht werden kann – die Serveradresse ist durch die Federation eh bekannt. Allerdings sollten lokale Adresse vom Abruf ausgeschlossen werden, damit interne Webseiten nicht unberechtigt ausgespäht werden können.
122
123 === Datenbank Einrichten ===
124
125 Als Datenbanksystem kann man zwar sqlite nutzen, aber wenn nichts gegen den Einsatz von Postgres spricht, sollte man von Beginn an dieses verwenden. Damit hierbei die passwortlose Anmeldung funktioniert, muss der Datenbanknutzer genauso wie der Systembenutzer des Synapse-Prozesses (systemctl show -pUser matrix-synapse.service) heißen. Die Datenbank und der Benutzer müssen vor dem ersten Start mit folgendem Befehl erstellt werden:
126
127 (% class="box" %)
128 (((
129 % sudo -u postgres sh -c 'createuser matrix-synapse
130 && createdb -O matrix-synapse -l C -E UTF-8 -T template0 matrix'
131 )))
132
133 Bei der Dienstverwaltung muss noch eingestellt werden, dass der Start von Synapse erst nach Postgres erfolgt:
134
135 (% class="box" %)
136 (((
137 % sudo systemctl edit matrix-synapse.service
138 [Unit]
139 After=network-online.target postgresql.service
140 )))
141
142 Neben den Parametern für connect können in der homeserver.yaml für database noch Parameter für das Connection-Pooling angegeben werden.
143
144 Postgres Tuning
145
146
147 = Speicherbegrenzung von Synapse =
148
149 Da Synapse sehr zum Speichergebrauch neigt, ist es ratsam diesem durch den Kernel eine Grenze zu setzen, damit das Gesamtsystem nicht beeinträchtigt wird. Eine Anpassung des Wertes SYNAPSE_CACHE_FACTOR hat bei mir langfristig keine Wirkung gezeigt, da dieser Wert nur bei der Initialisierung der Caches genutzt wird und keine Begrenzung darstellt. Ebenso konnte man langfristig mit jemalloc keine spürbare Verbesserung erreichen.
150
151 (% class="box" %)
152 (((
153 % sudo systemctl edit matrix-synapse.service
154 [Service]
155 MemoryMax=80%
156 )))
157
158
159 == Sicherheitsbeschränkung mit AppArmor ==
160
161 Da keine Software fehlerfrei ist, bietet der Linux-Kernel die Möglichkeit, mit AppArmor die Zugriffsreche von Prozessen stärker einzugrenzen. Mithilfe eines Profils legt man fest, welche Zugriffe gestattet sind, und alles was darüber hinaus geht, wird unterbunden. Dieses Profil speichert man unter /etc/apparmor.d/matrix-synapse ab und aktiviert es mit apparmor_parser -r /etc/apparmor.d/matrix-synapse. Damit das Profil für den Prozess verwendet wird, muss die Information in der Systemd-Unit angegeben werden:
162
163 (% class="box" %)
164 (((
165 % sudo systemctl edit matrix-synapse.service
166 [Service]
167 AppArmorProfile=matrix-synapse
168 )))
169
170 Im Journal sieht man gegebenenfalls Verstöße gegen die Regeln: journalctl -t audit. Sollte es zu Problemen kommen, kann man das Profil auch in den Testmodus schalten, womit die Verstöße protokolliert, aber nicht unterbunden werden. Hierfür ändert man in der Profildatei die Definition wie folgt ab und lädt das Profil mit dem obigen Befehl neu (ein Neustart von Synapse ist nicht erforderlich):
171
172 (% class="box" %)
173 (((
174 profile matrix-synapse flags=(complain) {
175 )))
176
177
178 == Protokollierung mit Journal einrichten ==
179
180 In der Konfiguration des Dienstes kann man auch noch den Namen angeben, der von journal verwendet werden soll, damit journalctl -t synapse (statt python) funktioniert:
181
182 (% class="box" %)
183 (((
184 [Service]
185 SyslogIdentifier=synapse
186 )))
187
188 In Synapse selbst kann man auch noch die Protokollierung an journal anpassen, indem man das Paket python3-systemd installiert und in /etc/matrix-synapse/log.yaml folgende Anpassungen vornimmt:
189
190 (% class="box" %)
191 (((
192 @@ -4,6 +4,8 @@
193 formatters:
194 precise:
195 format: '%(asctime)s - %(name)s - %(lineno)d - %(levelname)s - %(request)s- %(message)s'
196 +  journal_fmt:
197 +   format: '%(name)s: [%(request)s] %(message)s'
198 )))
199
200 (% class="box" %)
201 (((
202 (% class="box" %)
203 (((
204 filters:
205 context:
206 @@ -16,12 +18,17 @@
207 formatter: precise
208 filename: /var/log/matrix-synapse/homeserver.log
209 maxBytes: 104857600
210 -    backupCount: 10
211 +    backupCount: 6
212 filters: [context]
213 console:
214 class: logging.StreamHandler
215 formatter: precise
216 level: WARN
217 +  journal:
218 +    class: systemd.journal.JournalHandler
219 +    formatter: journal_fmt
220 +    filters: [context]
221 +    SYSLOG_IDENTIFIER: synapse
222 )))
223 )))
224
225 (% class="box" %)
226 (((
227 loggers:
228 synapse:
229 @@ -32,4 +39,4 @@
230 )))
231
232 (% class="box" %)
233 (((
234 root:
235 level: INFO
236 -    handlers: [file, console]
237 +    handlers: [file, journal]
238 )))
239
240
241 = Nginx einrichten =
242
243
244
245 In der Anfangszeit vor 2019 wurde Synapse direkt ins Internet gestellt. Bis auf sehr begrenzte Anwendungsfälle, wo eine Transportverschlüsselung nicht benötigt wird, ist es jedoch sinnvoller, einen Reverse-Proxy zu verwenden, der sich um TLS kümmert und gegebenenfalls noch weitere Maßnahmen genutzt werden kann. Die Einrichtung ist recht leicht, da nur alle Zugriffe
246
247
248 (% class="box" %)
249 (((
250 server {
251 listen 443 http2 ssl;
252 listen [::]:443 http2 ssl;
253 )))
254
255 (% class="box" %)
256 (((
257 root /srv/www/default;
258 )))
259
260 (% class="box" %)
261 (((
262 ssl_certificate /etc/letsencrypt/live/HOST/fullchain.pem;
263 ssl_certificate_key /etc/letsencrypt/live/HOST/privkey.pem;
264 )))
265
266 (% class="box" %)
267 (((
268 add_header Strict-Transport-Security "max-age=15552000; includeSubdomains; preload";
269 )))
270
271 (% class="box" %)
272 (((
273 location /_matrix/ {
274 access_log off;
275 proxy_pass http:~/~/[::1]:8008;
276 proxy_set_header X-Forwarded-For $remote_addr;
277 proxy_set_header X-Forwarded-Proto $scheme;
278 }
279 )))
280
281 (% class="box" %)
282 (((
283 location /.well-known/matrix/server {
284 access_log off;
285 add_header Access-Control-Allow-Origin *;
286 add_header Content-type application/json;
287 return 200 '{"m.server": "alea.gnuu.de:443"}';
288 }
289 )))
290
291 (% class="box" %)
292 (((
293 location /.well-known/matrix/ {
294 access_log off;
295 proxy_pass http:~/~/[::1]:8008;
296 proxy_set_header X-Forwarded-For $remote_addr;
297 proxy_set_header X-Forwarded-Proto $scheme;
298 }
299 }
300 )))
301 )))
302
303 (% class="col-xs-12 col-sm-4" %)
304 (((
305 {{box title="**Contents**"}}
306 {{toc/}}
307 {{/box}}
308
309
310
311
312
313
314
315
316
317
318
319
320
321 __**Man kann sich auch mehrere Profile erstellen oder unterschiedliche Server nutzen, um ggf. Arbeit und privates zu trennen.**__
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356 )))
357 )))
358
359
360 = Funktionstest =
361
362
363 Wenn alles durch ist, den Dienst (neu-)starten und dann sollte er auf dem Port 8008 lauschen.
364
365
366 (% class="box" %)
367 (((
368 % sudo systemctl restart matrix-synapse.service
369 % sudo ss -tlp |grep 8008
370 LISTEN     0      0        ::1:8008        :::*         users:(("python",pid=24088,fd=10))
371 )))
372
373
374 Ob der Server für Clients erreichbar ist, kann man per netcat oder telnet prüfen (auch fürs System-Monitoring hilfreich):
375
376 (% class="box" %)
377 (((
378 % netcat localhost 8008 <<<$'GET /_matrix/client/versions HTTP/1.0\r\n\r'
379 HTTP/1.0 200 OK
380 Content-Length: 54
381 Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, Authorization
382 Server: Synapse/0.29.0
383 Cache-Control: no-cache, no-store, must-revalidate
384 Date: Sun, 20 May 2018 15:16:36 GMT
385 Access-Control-Allow-Origin: *
386 Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
387 Content-Type: application/json
388 )))
389
390 (% class="box" %)
391 (((
392 {"versions": ["r0.0.1", "r0.1.0", "r0.2.0", "r0.3.0"]}
393 )))
394
395
396 Im Log /var/log/matrix-synapse/homeserver.log sollte dann etwas in dieser Art stehen:
397
398
399 (% class="box" %)
400 (((
401 2018-05-20 17:12:18,831 - synapse.access.http.8008 - 95 - INFO - GET-65532- - - 8008 - Received request: GET /_matrix/client/versions
402 2018-05-20 17:12:18,832 - synapse.access.http.8008 - 129 - INFO - GET-65532- - - 8008 - {None} Processed request: 1ms (0ms, 0ms) (0ms/0ms/0) 54B 200 "GET /_matrix/client/versions HTTP/1.0" "None"
403 )))
404
405
406 Ob der Server für andere Server erreichbar ist, also ob die Federation funktioniert, kann man über die Adresse https:~/~/matrix.org/federationtester/api/report?server_name=… mit dem entsprechenden Servernamen prüfen. In der Ausgabe sollte irgendwo "AllChecksOK": true erscheinen und am Ende sollte "ConnectionErrors": {} leer sein. Alternativ dazu gibt es noch den Fed-tester.
407
408
409 = Worker einrichten =
410
411
412 Worker sind noch eine recht junge Entwicklung (Stand: Mai 2019) von Synapse, aber ihr Einsatz lohnt sich. Ziel der Entwicklung ist es, Teile aus dem Hauptprozess herauszulösen und in eigenständige Prozesse zu gliedern. Auf diese Weise kann man …
413
414
415 = Element einrichten =
416
417
418 Element ist ein Webclient für Matrix, der vom Matrix-Team entwickelt wird. Man kann ihn direkt von app.element.io aus nutzen oder man richtet sich eine eigene Instanz ein. Es gibt zwar ein Debian-Paket, aber dieses hängt vom Paket gconf ab und zieht auf einem Server einen Rattenschwanz an Paketen hinterher. Deshalb verwende ich das allgemeine Paket und entpacke es in /srv/www/m.jo-so.de.
419
420 In dem Verzeichnis liegt die Datei config.sample.json, welche nach config.json kopiert werden muss. Darin sollte bei default_hs_url die Adresse des eigenen Matrix-Servers eingetragen werden. Ich habe bei mir die Anmeldung von Gästen deaktiviert "disable_guests": true, bei den Raum-Servern meinen eigenen ergänzt und bei piwik den Schlüssel url durch X-url ersetzt, damit auch sicher kein Piwik angesprochen wird.
421
422 Matrix nutzt zwei verschiedene Kommunikationswege: 8008 für Clients und 8448 für andere Server, so wie es auch bei XMPP der Fall ist. Da Matrix eine REST-Schnittstelle verwendet, kann man den Verkehr zum eigentlichen Matrix-Dienst durch einen Nginx leiten, so dass der Matrix-Dienst nicht als root laufen muss und man die Möglichkeiten Nginx‘ nutzen kann: SSL-Zertifikate, HTTP/2.0, Einschränken der IP-Adressbereiche, HTTP-Authentifizierung und die Vermischung mit anderen Inhalten, denn Matrix nutzt nur das Verzeichnis /_matrix.
423
424
425 (% class="box" %)
426 (((
427 server {
428 listen 443 http2 ssl;
429 listen [::]:443 http2 ssl;
430 )))
431
432 (% class="box" %)
433 (((
434 root /srv/www/default;
435 )))
436
437 (% class="box" %)
438 (((
439 location /_matrix/ {
440 access_log off;
441 proxy_pass http:~/~/[::1]:8008;
442 proxy_set_header X-Forwarded-For $remote_addr;
443 }
444 )))
445
446 (% class="box" %)
447 (((
448 location /.well-known/matrix/server {
449 access_log off;
450 add_header Access-Control-Allow-Origin *;
451 return 200 '{"m.server": "alea.gnuu.de:443"}';
452 }
453 )))
454
455 (% class="box" %)
456 (((
457 location /.well-known/matrix/ {
458 access_log off;
459 proxy_pass http:~/~/[::1]:8008;
460 proxy_set_header X-Forwarded-For $remote_addr;
461 }
462 )))
463
464 (% class="box" %)
465 (((
466 location /m/ {
467 access_log off;
468 alias /srv/www/m.jo-so.de/;
469 }
470 }
471 )))
472
473 (% class="box" %)
474 (((
475 % sudo systemctl reload nginx.service
476 )))
477
478
479 Als einfachere Funktionsprüfung kann man im Browser die Adresse /_matrix/client/versions seines Servers aufrufen und sollte eine Ausgabe ähnlich wie bei https:~/~/matrix.org/_matrix/client/versions erhalten.
480
481 Ein kleines Skript für die regelmäßige Aktualisierung von Element habe ich in der Anleitung zu jq beschrieben.
482
483
484 = Neuen Benutzer anlegen =
485
486
487 Man kann es allen Nutzern erlauben, ein neues Konto über die Weboberfläche anzulegen, in dem man in der Serverkonfiguration homeserver.yaml die Option enable_registration: true setzt. Falls man jedoch nur einen geschlossenen Nutzerkreis haben will, kann man in der Serverkonfiguration bei registration_shared_secret: "<SECRET KEY>" eine geheime Zeichenkette (generiert mit pwgen -s 64 1) eintragen und dann mit dem Kommandozeilenprogramm register_new_matrix_user neue Benutzer anlegen:
488
489
490 (% class="box" %)
491 (((
492 % register_new_matrix_user -c /etc/matrix-synapse/homeserver.yaml http:~/~/localhost:8008
493 New user localpart [root]: user
494 Password:
495 Confirm password:
496 Make admin [no]:
497 Sending registration request...
498 Success.
499 )))
500
501
502 Das Zurücksetzen des Passworts gibt es die händische Bearbeitung der Datenbank und eine API-Funktion, die man mit curl aufrufen kann.
503
504
505 = TURN für Video- und Audioverbindungen einrichten =
506
507
508 Für Video- und Audioverbindungen ist neben dem Matrix-Server noch ein TURN-Server notwendig, der zwischen Geräten vermittelt, die sich nicht direkt erreichen können; z. B. durch NAT. Direkt von Debian gibt es das Paket coturn.
509
510 Nach der Installation (apt install coturn) muss die Konfigurationsdatei /etc/turnserver.conf wie folgt angepasst werden (Entnommen aus der Doku von synapse):
511
512
513 (% class="box" %)
514 (((
515 lt-cred-mech
516 use-auth-secret
517 static-auth-secret=Geheimen Schlüssel mit `pwgen -s 64 1` erzeugen
518 realm=jo-so.de
519 no-tcp-relay
520 cert=/etc/letsencrypt/live/host/fullchain.pem
521 pkey=/etc/letsencrypt/live/host/privkey.pem
522 no-multicast-peers
523 denied-peer-ip=10.0.0.0-10.255.255.255
524 denied-peer-ip=172.16.0.0-172.31.255.255
525 denied-peer-ip=192.168.0.0-192.168.255.255
526 pidfile="/dev/null"
527 secure-stun
528 mobility
529 no-tlsv1
530 )))
531
532 Den geheimen Schlüssel und die TURN-Verbindungen muss man noch in der homeserver.yaml eintragen und den Synapse-Server neustarten.
533
534 (% class="box" %)
535 (((
536 turn_uris:
537 - "turn:alea.gnuu.de:3478?transport=udp"
538 - "turn:alea.gnuu.de:3478?transport=tcp"
539 )))
540
541 (% class="box" %)
542 (((
543 turn_shared_secret=Geheimer Schlüssel
544 )))
545
546 Die Konfiguration für Systemd wird bei der Installation automatisch generiert, weshalb ich sie durch folgende ersetzt (systemctl edit ~-~-full coturn.service) habe. Damit läuft der Prozess auch nicht mehr als Benutzer root.
547
548 (% class="box" %)
549 (((
550 # https:~/~/github.com/coturn/coturn/blob/master/rpm/turnserver.service.fc
551 )))
552
553 (% class="box" %)
554 (((
555 [Unit]
556 Description=coturn
557 Documentation=man:coturn(1) man:turnadmin(1) man:turnserver(1)
558 After=network.target
559 )))
560
561 (% class="box" %)
562 (((
563 [Service]
564 User=turnserver
565 Group=turnserver
566 SupplementaryGroups=ssl-cert
567 PIDFile=/run/turnserver.pid
568 ExecStart=/usr/bin/turnserver -c /etc/turnserver.conf ~-~-log-file stdout
569 Restart=on-abort
570 )))
571
572 (% class="box" %)
573 (((
574 LimitNOFILE=999999
575 LimitNPROC=60000
576 LimitRTPRIO=infinity
577 LimitRTTIME=7000000
578 CPUSchedulingPolicy=other
579 UMask=0007
580 NoNewPrivileges=yes
581 )))
582
583 (% class="box" %)
584 (((
585 [Install]
586 WantedBy=multi-user.target
587 )))
588
589 AppArmor /etc/apparmor.d/usr.bin.turnserver
590
591 (% class="box" %)
592 (((
593 include <tunables/global>
594 )))
595
596 (% class="box" %)
597 (((
598 profile /usr/bin/turnserver {
599 include <abstractions/base>
600 include <abstractions/ssl_certs>
601 include <abstractions/ssl_keys>
602 )))
603
604 (% class="box" %)
605 (((
606 /etc/turnserver.conf r,
607 owner /var/lib/turn/turndb rwk,
608 }
609 )))
610
611
612 Sicherheitshinweis: Trotz der Einstellungen für Verschlüsselung des TURN-Servers konnte man mit Wireshark noch die Inhalte der Verbindung einsehen. Leider konnte man nichts finden, wie die TURN-Verbindung weiter abgesichert werden kann.
613
614 (% class="box" %)
615 (((
616 Source: laptop (Port: 59697)
617 Destination: alea.gnuu.de (Port: 3478)
618 Protocol: STUN
619 Info: Allocate Request UDP lifetime: 3600 user: 1527072691:@test:alea.gnuu.de realm: alea.gnuu.de with nonce
620 )))
621
622 (% class="box" %)
623 (((
624 Source: laptop (Port: 59697)
625 Destination: alea.gnuu.de (Port: 3478)
626 Protocol: STUN
627 Info: CreatePermission Request XOR-PEER-ADDRESS: 192.168.178.21:48261 user: 1527072691:@test:alea.gnuu.de realm: alea.gnuu.de with nonce
628 )))
629
630 Im Wireshark konnte man aber auch beobachten, dass meine beiden Testgeräte direkt per IPv6 kommuniziert haben, ohne den Weg über den TURN-Server.
631
632
633 = Wechsel der Datenbank zu Postgres =
634
635 Ursprünglich wurde mit sqlite begonnen und später die Datenbank auf Postgres umgestellt. Hier die Befehle zum Einrichten des Benutzers und der Datenbank. Dabei ist darauf zu achten, dass der Benutzername identisch mit dem Systembenutzer seien muss, unter dem auch der Dienst läuft, sonst funktioniert die passwortlose Anmeldung per Socket nicht; systemctl show -pUser matrix-synapse.service.
636
637
638 (% class="box" %)
639 (((
640 % sudo apt install python-psycopg2
641 % sudo -u postgres sh -c 'createuser matrix-synapse
642 && createdb -O matrix-synapse -l C.UTF-8 -T template0 matrix'
643 )))
644
645 In der Konfiguration homeserver.yaml müssen noch die Einstellungen wie folgt geändert werden:
646
647
648 (% class="box" %)
649 (((
650 # Database configuration
651 database:
652 # The database engine name
653 name: psycopg2
654 # Arguments to pass to the engine
655 args:
656 database: matrix
657 user: matrix-synapse
658 host: /run/postgresql
659 application_name: matrix-synapse
660 )))
661
662 Zusätzlich zu den Parametern für connect kann man noch Parameter für das Connection-Pooling angeben. Leider ist zu dem von Synapse genutzten Connection-Pool zu sagen, dass es ungenutzte (idle) Verbindungen nicht automatisch schließt. Eine Lösung hierfür habe ich noch nicht gefunden.
663
664 Bei Systemd sollte man dann noch angeben, dass der Server erst nach Postgres gestartet wird:
665
666 (% class="box" %)
667 (((
668 % sudo systemctl edit matrix-synapse.service
669 [Unit]
670 After=network-online.target postgresql.service
671 )))
672
673 Für die Datenmigration von sqlite zu Postgres gibt es das Programm synapse_port_db. Dieses kann auch mehrfach ausgeführt werden, falls man den Dienst weiterlaufen lässt und eine Kopie der sqlite-Datenbank verwendet hat oder es zu Fehlern kam. Den Dienst kann man aber auch einfach für die gesamte Zeit abgeschalten.
674
675 (% class="box" %)
676 (((
677 % cd /tmp && sudo -u matrix-synapse synapse_port_db -v ~-~-curses \
678 ~-~-sqlite-database /var/lib/matrix-synapse/homeserver.db \
679 ~-~-postgres-config /etc/matrix-synapse/homeserver.yaml
680 )))
681
682 Wenn es zu einem Fehler kommt und in der Datei port-synapse.log etwas von Failed to insert: room_depth steht, dann zuerst einmal nachsehen, ob der Fehler 3214 bereits gelöst ist oder ggf. den ALTER TABLE-Befehl von dort ausführen und die Migration noch einmal starten.
683
684
685 = Wartungsarbeiten =
686
687 Auf der Webseite von Matrix werden diverse Anleitungen zur Wartung von Synapse und Moderation von Matrix angeboten.
688
689
690 = Datensicherung =
691
692
693 Wichtig für eine Wiederherstellung einer Matrix-Installation sind
694
695 die Konfigurationdateien unter /etc/matrix-synapse,
696 die Dateien unter /var/lib/matrix-synapse und
697 die Datenbank.
698
699 Um das Backup zu verkleinern kann man die Verzeischnisse /var/lib/matrix-synapse/media/(remote_|url_cache)*/* auslassen. Deren Inhalt lässt sich im Nachhinein über andere Server wiederherstellen.
700
701 Bei der Wiederherstellung des Systems muss man mit dem Zugangsschlüssel (Access-Token) eines Admin-Benutzers den Cache zurücksetzen, damit Synapse die Dateien, die vom Backup ausgeschlossen waren, neu beschafft. Den Zugangsschlüssel findet man in Element unter Einstellungen, Hilfe, Fortgeschritten und nutzt diesen für purge_remote_media mit aktuellem Zeitstempel:
702
703
704 (% class="box" %)
705 (((
706 curl -H "Authorization: Bearer <access_token>" -d '' "http:~/~/localhost:8008/_synapse/admin/v1/purge_media_cache?before_ts=$(date +%s000)"
707 )))
708
709 (% class="box" %)
710 (((
711 (
712 echo 'DELETE FROM remote_media_cache WHERE filesystem_id NOT IN ('; \
713 find /var/lib/matrix-synapse/media/remote_content -type f -printf '%P\n' \
714 ~|sed "s,^[^/]*/,',; s,/~,~,g; s/\$/',/; \$s/,\$~/~/" |tail; \
715 echo ');'; \
716 echo 'DELETE FROM remote_media_cache_thumbnails WHERE media_id NOT IN (SELECT media_id FROM remote_media_cache);'
717 ) > /tmp/cleanup_rmc.sql
718 )))
719
720
721 = Ungenutzte Räume entfernen =
722
723 Wenn Nutzer einen Raum verlassen, der über mehrere Server verteilt liegt, bleiben auf dem eigenen Server die alten Nachrichten zurück. Da diese nicht mehr genutzt werden, ist es sinnvoll, diese zu entfernen:
724
725 (% class="box" %)
726 (((
727 mx_token=<Token eines Admins>
728 for room in $(curl -s ~-~-header "Authorization: Bearer $mx_token" \
729 'http:~/~/localhost:8008/_synapse/admin/v1/rooms?limit=800' \
730 ~|jq -r '[ .rooms[] | select(.joined_local_members == 0) ] |sort_by(.state_events) | .[].room_id')
731 do
732 echo -n "Purging $room: "
733 time curl -s -o /dev/null ~-~-header "Authorization: Bearer $mx_token" \
734 -X POST -H "Content-Type: application/json" -d "{ \"room_id\": \"$room\" }" \
735 'http:~/~/localhost:8008/_synapse/admin/v1/purge_room'
736 done
737 )))
738
739
740 == state_groups_state aufräumen ==
741
742
743 In der Tabelle state_groups_state legt Synapse irgendwelche Daten ab (weiß jemand welche? Stift oben rechts nutzen), die zum Teil redundant sind. Daher kann man diese Tabelle mit dem Programm rust-synapse-compress-state aufräumen und somit den Speicherverbrauch eindämmen.
744
745 Wer Rust installiert hat, kompiliert das Programm besser selbst aus den Quellen, denn Releases passieren eher selten:
746
747 (% class="box" %)
748 (((
749 cargo install ~-~-git https:~/~/github.com/matrix-org/rust-synapse-compress-state synapse_compress_state
750 )))
751
752 Danach liegt das Programm im Verzeichnis ~~/.cargo/bin/synapse-compress-state. Beim Aufruf erstellt es aber nur eine SQL-Dateien, die die eigentlichen Änderungen beschreiben. Man muss also nach jedem Durchlauf des Programms noch das entstandene SQL-Skript ausführen. Daher habe ich mir das Hilfsprogramm synapse-clear-state erstellt, um auch alle anderen Schritte dafür durchzuführen. Dieses Hilfsprogramm rufe ich mithilfe von Systemd auf, damit es im Hintergrund läuft (bei mir dauert es über 2 Stunden) und ich die Meldungen im Nachhinein prüfen kann
753
754 (% class="box" %)
755 (((
756 % sudo systemd-run ~-~-nice=4 -pCPUSchedulingPolicy=batch \
757 -pIOSchedulingClass=idle ~-~-uid=matrix-synapse ~-~-collect \
758 ~-~-unit=synapse-clear-state ~~/bin/synapse-clear-state
759 % journalctl -Stoday -u synapse-clear-state
760 )))
761
762 Das Programm hat nämlich die Macke und erzeugt ein größeres Ergebnis als der Ausgangszustand. Da auch die Prüfung auf die Korrektheit des neuen Zustands teilweise sehr lange dauert, kann man mit der Option -m bei synapse-compress-state die Mindestanzahl an Tabellenzeilen angeben, für die der neue Zustand genommen wird. Abgesehen von dieser Macke liefert das Programm aber teilweise eine Reduktion auf 10 % (sic!) bei einigen Räumen.
763
764 Synapse muss während der Ausführung nicht angehalten werden, sodass es egal ist, wie lange das Programm läuft oder ob man es zwischendurch abbricht. Ich rufe es bei mir unregelmäßig alle paar Wochen auf.
765
766 = device_inbox aufräumen =
767
768 Die Schema-Definition der Datenbank von Synapse ist piep. Daher werden Einträge in der Tabelle device_inbox nicht gelöscht, wenn die dazugehörigen Geräte gelöscht werden. Mit folgendem SQL-Befehl kann man dies händisch erledigen:
769
770 (% class="box" %)
771 (((
772 DELETE
773 ~-~- SELECT COUNT(*)
774 FROM device_inbox
775 WHERE device_id IN (SELECT device_id FROM devices WHERE hidden = true)
776 OR device_id NOT IN (SELECT device_id FROM devices);
777 )))
778
779 = event_forward_extremities aufräumen =
780
781 Wenn ein Server offline ist, kommen die Daten im Nachhinein nicht immer in der korrekten Reihenfolge an. Dadurch kann es passieren, dass Synapse in der Tabelle event_forward_extremities ungünstige Einträge erzeugt, die dazu führen, dass Synapse sehr viel Arbeitsspeicher verbraucht und der Dienst teilweise unbenutzbar wird. Daher sollte man regelmäßig prüfen, ob diese ungünstigen Einträge entstanden sind und bei mehr als fünf diese entfernen. Ein paar wenige stören nicht und man kann sie belassen, weil sonst Synapse abgeschaltet werden muss (was potentiell zu neuen fehlerhaften Einträgen führt).
782
783 Ich beobachte diese fehlerhaften Einträge auch noch mit Synapse 1.34, aber ich prüfe auch nur etwa einmal im Monat darauf. Zum Entfernen verwende ich ein angepasstes Skript , das ich anhand des Beitrags im Bugtracker erstellt habe:
784
785 (% class="box" %)
786 (((
787 sudo -u matrix-synapse LC_ALL=C.UTF-8 psql -f matrix-clean-extremities.sql matrix
788 )))
789
790 = Alte Anhänge löschen =
791
792 Die beiden Verzeichnisse mit remote in /var/lib/matrix-synapse/media können mit der Zeit verdammt groß werden. Sie enthalten Bilder, Video und Dateien, die Nutzer auf anderen Servern in Räume geschickt haben. Nach einem gewissen Zeitraum sind die Dateien aber nicht mehr von Bedeutung und können gelöscht werden. Sollte doch einmal ein Nutzer auf dem lokalen Server so weit zurück scrollen oder springen, werden die Datei von anderen Servern wieder geholt, da mindestens der Ursprungsserver diese als lokale Daten betrachten und sie nicht löschen sollte.
793
794 Aber sicher ist dies nicht und bisher habe ich auch noch keine Möglichkeit gefunden, Chats zu exportieren. Wer also den nötigen Festplattenplatz hat, sollte die Dateien lieber liegenlassen, denn das Löschen betrifft alle Räume, inklusive privater, verschlüsselter Chats mit Urlaubsbildern und Dokumenten.
795
796 Purge Remote Media API
797
798 (% class="box" %)
799 (((
800 curl -H "Authorization: Bearer <access_token>" -d '' \
801 "http:~/~/localhost:8008/_synapse/admin/v1/purge_media_cache?before_ts=$(date -d-6months +%s)000"
802 )))
803
804 = Alte Nachrichten löschen =
805
806 Räume, in denen viel geschrieben wird, wachsen dementsprechend schnell an. Wer auf seinem Server Platz schaffen will oder wer alte Nachrichten aufgrund der Datensparsamkeit beseitigen möchte, kann dies für einzelne Räume durchführen.
807
808 Jedoch gilt wie oben bei den alten Anhängen: Sollte ein Nutzer die alten Nachrichten wieder anfragen, werden diese von den Nachbarservern beschafft, sofern sie dort noch verfügbar sind. Für private Unterhaltungen könnten das einige Nutzer nicht so lustig auffassen, wenn sie auf die Konzertpläne vom letzten Jahr oder die Glückwünsche vom letzten runden Geburtstag nicht mehr zugreifen können. Daher: Wer den Platz hat, sollte die Nachrichten besser aufheben.
809
810 (% class="box" %)
811 (((
812 curl -H "Authorization: Bearer <access_token>" \
813 -H "Content-Type: application/json" \
814 -d '{ "delete_local_events": false, "purge_up_to_ts": '$(date -d-6months +%s)000' }' \
815 "http:~/~/localhost:8008/_synapse/admin/v1/purge_history/$room_id"
816 )))
817
818 Purge History
819
820 = Beseitigung von Räumen aus der Datenbank =
821
822 Dadurch das ein defektrer Zustand des Synapse-Servers erreicht wurde , sodass der Raum #matrix:matrix.org nicht mehr beitreten werden konnte, er aber auch nicht aus Element entfernen konnte. Es gibt im git das Programm nuke-room-from-db, mit dem man die Datenbank bereinigen kann.
823
824 = Unerwünschte Räume entfernen =
825
826 Matrix ist so entworfen, dass der Administrator eines Servers nicht in den Inhalt eines Raumes eingreifen kann. Wenn in einem Raum Nachrichten und Anhänge ausgetauscht werden, die vom Administrator nicht erwünscht sind, kann der Administrator nur den kompletten Raum vom Server löschen. Konkret: Wenn in einem Raum niemand Spamer und störende Nutzer hinauswirft, kann der Serveradministrator nichts tun – er hat technisch keine Möglichkeiten, die Benutzer zu entfernen, weil der Raum über alle beteiligten Server verteilt liegt und er die Struktur mit händischen Eingriffen zerstören würde.
827
828 Der folgende Aufruf löscht den Raum mit der MX-ID $room_id und blockiert den erneuten Beitritt zu dem Raum. Die Teilnehmer des lokalen Servers werden alle vom Raum abgemeldet und in einen neuen Raum eingetragen, in dem der Nutzer @abuse:example.com Administrator ist und die Nutzer keine Schreibrechte haben. Als Information erscheint im neuen Raum die Nachricht message. Den alten Raum würde ich erst in einem zweiten Schritt durch die normale Funktion zum Aufräumen aus der Datenbank entfernen, damit der Aufruf nicht zu lange dauert.
829
830 (% class="box" %)
831 (((
832 curl -H "Authorization: Bearer <access_token>" \
833 -X DELETE -d '{
834 "new_room_user_id": "@abuse:example.com",
835 "room_name": "Löschung des Raums …",
836 "message": "Der Raum … wurde gelöscht, weil …",
837 "block": true,
838 "purge": false
839 }' "http:~/~/localhost:8008/_synapse/admin/v1/rooms/$room_id"
840 )))
841
842 = Versiegelung von Räumen =
843
844 Matrix bietet die Möglichkeit, in einem Raum einen Grabstein (engl. tombstone (DeepL-Übersetzung)) zu platzieren und somit die Kommunikation über diesen Raum zu beenden. Diese Funktionalität wird bei der Aktualisierung der Raumversionen genutzt, indem in den alten Raum ein Grabstein gesetzt und ein neuer Raum (mit aktueller Version) eröffnet wird. Auf diesem Grabstein steht dann auch der Verweis auf den neuen Raum, wo das Leben weiter geht. 😉
845
846 Diese Versiegelungen für einen Raum kann man in Element mit /devtools und Send Custom Event erstellen. Der Event Type ist dann m.room.tombstone und als Content gibt man folgendes an:
847
848 (% class="box" %)
849 (((
850 {
851 "body": "This room has been replaced, blblabla",
852 "replacement_room": "!newroom:example.org"
853 }
854 )))
855
856 Oder man erstellt die entsprechende Nachricht über die Kommandozeile mit folgendem Aufruf. Dabei muss $mx_token von einem Admin des Raumes sein und $old_roomid bzw. $new_roomid die ID (mit !…:example.org) sein:
857
858 (% class="box" %)
859 (((
860 curl -s -X PUT -H "Authorization: Bearer $mx_token" \
861 -H "Content-Type: application/json" \
862 ~-~-data-binary "{\"replacement_room\":\"$new_roomid\"}" \
863 "https:~/~/…/_matrix/client/r0/rooms/$old_roomid/state/m.room.tombstone"
864 )))
865
866 = Administration von Räumen
867 Zugangsbegrenzungen über die Raum-ACL =
868
869 Man kann für jeden Raum einzeln auch konfigurieren, welche Domains darauf Zugriff haben sollen. Diese ACL kann man über spezielle Events verändern:
870
871 in Element im Raum die Entwicklerwerkzeuge mit dem Befehl /devtools öffnen
872 auf Send custom event klicken
873 unten rechts auf den Knopf Event drücken
874 bei Event Type m.room.server_acl eintragen, State Key leer lassen
875 bei Event Content die Regeln (s. u.) einfügen
876 Send klicken
877 danach auf Back klicken
878 über Explore Room State, m.room.server_acl die ACL kontrollieren
879 im Chatverlauf erscheint die Meldung … set the server ACLs for this room. { "allow": [ "*" ], "allow_ip_literals": false, "deny": [ "matrix.kiwifarms.net", "*.kiwifarms.net" ] }
880
881 = Clients für Matrix =
882
883 == Element ==
884
885 Im Kontextmenü der Räume kann man über Direct message den Eintrag zwischen Rooms und People verschieben. Für People wird man über jede Nachricht benachrichtigt, bei Rooms nur für die, in denen man erwähnt wird.
886 Für Element-Web gibt es einige Tastenkürzel zur Bedienung, die man sich mit Strg+/ (also Strg+Shift+7) ansehen kann.
887 Liste der Emojis
888 Wenn es Probleme mit den Nachrichten oder Räumen gibt, kann man in den Einstellungen des eigenen Kontos ganz unten auf Cache leeren und neu laden (in der App Cache leeren in den Einstellungen fast ganz unten) klicken. Falls das nicht hilft, ab
889 In den Einstellungen des eigenen Kontos kann man Schlüssel von Geräten löschen, die man nicht mehr nutzt. Rechts neben den Geräten die Haken setzen und dann Löschen drücken. Somit kann man auch bei Verlust eines Clients dessen Schlüssel aus dem Verkehr ziehen.
890 Element unterstützt auch die Übertragung des Bildschirms. Dazu muss man auf den Video-Anruf-Knopf klicken und die Umschalttaste dabei drücken. Bei Chrome muss hierfür der Browser mit der Option ~-~-enable-usermedia-screen-capturing gestartet oder die Erweiterung Element-Screen-Sharing.
891
892 = Hydrogen =
893
894
895 Hydrogen Chat, vector-im/hydrogen-web: Lightweight matrix client with legacy and mobile browser support
896 unterstützt Verschlüsselung
897 unterstützt mehrere Accounts gleichzeitig, wobei man immer wechseln muss; es gibt keine gemischte Ansicht
898 scheint auf dem Framework von Element aufzubauen, sieht jedenfalls ähnlich wie Element aus
899 kann Kachelansicht mit mehreren Chats gleichzeitig
900 wirkt sehr spartanisch von Bedienung her (2021-12-29): keine Sprungmarke zur zuletzt gelesenen Nachricht; kein Home ohne geöffneten Chat
901
902 = Weitere Apps =
903
904
905 Fluffychat: Gibt es als App, Desktop-Programm und Web-Seite, orientiert sich mehr an Whatsapp. Der Raum für Fragen ist #fluffychat:matrix.org
906 SchildiChat: Ein angepasstes Element, das sich mehr an gängigen Messengern orientiert
907 Pattle: Hat ein anderes Bedienkonzept als Element und orientiert sich mehr an herkömmlichen Messengern.
908 Cinny, cinnyapp/cinny-desktop: Yet another matrix client for desktop
909
910 = Desktop-Programme =
911
912
913 Übersicht von Matrix-Clients
914 nheko (nheko) ähnelt laut Bildern im Web sehr WhatsApp und unterstützt verschlüsselte Räume
915 Quaternion sieht aus wie ein üblicher Chat-Client, unterstützt keine verschlüsselten Räume (Mai 2018)
916 Fractal ist eine GNOME-Anwendung und in Rust geschrieben. Bisher unterstützt es noch keine verschlüsselten Räume. (Mai 2018)
917 Setting Up WeeChat Again with weechat-matrix – paritybit.ca
918 gomuks: Ein konsolenbasierter Client programmiert in Go. Github »Right now [release 0.2.0], the client supports all of features a Matrix client should have including encrypted chats, easy interaction with files, room management, message redaction, replying, and editing, setting different nicknames for different rooms, and desktop notifications.« (Gomuks is the Best CLI Matrix Client – paritybit.ca)
919
920 = Kommunikation mit anderen Netzwerken
921 IRC =
922
923 Von matrix.org werden offiziell Verbindungen in verschiedene IRC-Netze angeboten. Um zum Beispiel in den IRC-Channel #firefox bei moznet einzutreten, betritt man den Matrix-Raum #mozilla_#firefox:matrix.org. Genaueres gibt’s in der Anleitung zum IRC-Appservice.
924
925 Nachdem man das erste Mal einen Chatraum für ein anderes Netzwerk betreten hat, wird man von dem Dienst für das Netzwerk in einen zusätzlichen Raum eingeladen; alternativ kann dem auch selbst einen Direktchat mit dem Appservice user starten. In diesem Raum kann man über spezielle Nachrichten den Dienst steuern: * mit !nick seinen Namen in dem fremden Netzwerk ändern, * mit !join weitere Räume betreten – ich betrete neue Räume fast nur mit diesem Befehl und lasse mich in den eigentlichen Matrix-Raum einladen * mit !help die allgemeine Hilfe abfragen
926
927 Wenn man Schwierigkeiten mit den Räumen hat, weil zum Beispiel der Nickname nicht stimmt oder Nachrichten nicht ankommen, kann man mit dem Befehl !quit auch komplett die Brücke verlassen und von vorn beginnen.
928
929 = Nick-Name registrieren bei libera.chat =
930
931 Einige Channels in IRC sind nur für registrierte Benutzer (+r) zugänglich. Daher ist es sinnvoll, sich in diesen Netzwerken einen Namen zu registrieren. Exemplarisch beschreibe ich hier den Weg für Libera Chat, aber mit anderen Netzwerken sollte es genauso ablaufen:
932
933 mithilfe eines Webclients zum Netzwerk verbinden
934 seinen gewünschten Namen auswählen: /nick jo-so
935 ein Passwort mit dem Lieblingspasswortmanager generieren und die Registrierung starten: /msg NickServ REGISTER YourPassword youremail@example.com
936 die E-Mail abrufen und den Befehl daraus im Webchat ausführen: /msg NickServ VERIFY REGISTER jo-so …; dies sollte mit einer Erfolgsmeldung bestätigt werden
937 den Webchat schließen
938 im Matrix-Raum mit dem Appservice user für liberachat IRC Bridge status den Nickname und das Passwort hinterlegen: !username jo-so und !storepass YourPassword
939 danach !reconnect ausführen
940 wenn die Verbindung wieder besteht, sollte nach !nick die Meldung »Currently connected to IRC networks: irc.libera.chat as jo-so« (DeepL-Übersetzung) erfolgen
941
942 Theoretisch müsste auch alles von Matrix aus funktionieren, aber ich habe dies nicht getestet.
943
944 mit dem Appservice user einen Direktchat starten
945 !nick jo-so
946 !cmd MSG NickServ REGISTER YourPassword youremail@example.com
947 !cmd MSG NickServ VERIFY REGISTER jo-so …
948 !username jo-so
949 !storepass YourPassword
950
951 Weitere Dokumentationen:
952
953 Nickname Registration | Libera Chat
954 End user FAQ · matrix-appservice-irc Wiki
955
956
957
958