Wiki source code of Matrix Messenger Installation

Version 1.1 by René Schmidt on 2023/09/20 13:17

Hide last authors
René Schmidt 1.1 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 % echo 'deb http:~/~/ftp.de.debian.org/debian/ buster-backports main' |sudo tee -a /etc/apt/sources.list
62 % sudo apt update
63 % sudo apt install -t buster-backports fasttrack-archive-keyring
64
65 % echo 'deb http:~/~/fasttrack.debian.net/debian/ buster-fasttrack main' |sudo tee -a /etc/apt/sources.list
66 % sudo apt update
67 % sudo apt install -t buster-backports matrix-synapse/buster-fasttrack
68
69 Für ältere Versionen bietet das Matrix-Projekt ein Repository an. Damit ist die Installation und die Aktualisierung gewohnt einfach.
70
71 % curl https:~/~/packages.matrix.org/debian/matrix-org-archive-keyring.gpg |sudo dd of=/etc/apt/trusted.gpg.d/matrix-org.gpg
72 % echo "deb https:~/~/packages.matrix.org/debian/ stretch main" |sudo tee -a /etc/apt/sources.list
73 % sudo apt update && sudo apt install matrix-synapse-py3
74
75 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.
76
77 public_baseurl: https:~/~/alea.gnuu.de/
78 admin_contact: 'mailto~:admin@example.org'
79
80 database:
81 name: psycopg2
82 args:
83 dbname: matrix
84 user: matrix-synapse
85 host: /run/postgresql
86 application_name: synapse
87
88 url_preview_enabled: true
89 url_preview_ip_range_blacklist:
90 - '127.0.0.0/8'
91 - '10.0.0.0/8'
92 - '172.16.0.0/12'
93 - '192.168.0.0/16'
94 - 'fe80::/10'
95
96 enable_metrics: false
97 macaroon_secret_key: "Geheimen Schlüssel mit `pwgen -s 64 1` erzeugen"
98 expire_access_token: true
99
100 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.
101
102 === Datenbank Einrichten ===
103
104 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:
105
106 % sudo -u postgres sh -c 'createuser matrix-synapse
107 && createdb -O matrix-synapse -l C -E UTF-8 -T template0 matrix'
108
109 Bei der Dienstverwaltung muss noch eingestellt werden, dass der Start von Synapse erst nach Postgres erfolgt:
110
111 % sudo systemctl edit matrix-synapse.service
112 [Unit]
113 After=network-online.target postgresql.service
114
115 Neben den Parametern für connect können in der homeserver.yaml für database noch Parameter für das Connection-Pooling angegeben werden.
116
117 Postgres Tuning
118
119
120 = Speicherbegrenzung von Synapse =
121
122 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.
123
124 % sudo systemctl edit matrix-synapse.service
125 [Service]
126 MemoryMax=80%
127
128
129 == Sicherheitsbeschränkung mit AppArmor ==
130
131 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:
132
133 % sudo systemctl edit matrix-synapse.service
134 [Service]
135 AppArmorProfile=matrix-synapse
136
137 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):
138
139 profile matrix-synapse flags=(complain) {
140
141
142 == Protokollierung mit Journal einrichten ==
143
144 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:
145
146 [Service]
147 SyslogIdentifier=synapse
148
149 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:
150
151 @@ -4,6 +4,8 @@
152 formatters:
153 precise:
154 format: '%(asctime)s - %(name)s - %(lineno)d - %(levelname)s - %(request)s- %(message)s'
155 +  journal_fmt:
156 +   format: '%(name)s: [%(request)s] %(message)s'
157
158 (% class="box" %)
159 (((
160 filters:
161 context:
162 @@ -16,12 +18,17 @@
163 formatter: precise
164 filename: /var/log/matrix-synapse/homeserver.log
165 maxBytes: 104857600
166 -    backupCount: 10
167 +    backupCount: 6
168 filters: [context]
169 console:
170 class: logging.StreamHandler
171 formatter: precise
172 level: WARN
173 +  journal:
174 +    class: systemd.journal.JournalHandler
175 +    formatter: journal_fmt
176 +    filters: [context]
177 +    SYSLOG_IDENTIFIER: synapse
178 )))
179
180 loggers:
181 synapse:
182 @@ -32,4 +39,4 @@
183
184 root:
185 level: INFO
186 -    handlers: [file, console]
187 +    handlers: [file, journal]
188
189
190 = Nginx einrichten =
191
192
193
194 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
195
196
197 (% class="box" %)
198 (((
199 server {
200 listen 443 http2 ssl;
201 listen [::]:443 http2 ssl;
202 )))
203
204 (% class="box" %)
205 (((
206 root /srv/www/default;
207 )))
208
209 (% class="box" %)
210 (((
211 ssl_certificate /etc/letsencrypt/live/HOST/fullchain.pem;
212 ssl_certificate_key /etc/letsencrypt/live/HOST/privkey.pem;
213 )))
214
215 (% class="box" %)
216 (((
217 add_header Strict-Transport-Security "max-age=15552000; includeSubdomains; preload";
218 )))
219
220 (% class="box" %)
221 (((
222 location /_matrix/ {
223 access_log off;
224 proxy_pass http:~/~/[::1]:8008;
225 proxy_set_header X-Forwarded-For $remote_addr;
226 proxy_set_header X-Forwarded-Proto $scheme;
227 }
228 )))
229
230 (% class="box" %)
231 (((
232 location /.well-known/matrix/server {
233 access_log off;
234 add_header Access-Control-Allow-Origin *;
235 add_header Content-type application/json;
236 return 200 '{"m.server": "alea.gnuu.de:443"}';
237 }
238 )))
239
240 (% class="box" %)
241 (((
242 location /.well-known/matrix/ {
243 access_log off;
244 proxy_pass http:~/~/[::1]:8008;
245 proxy_set_header X-Forwarded-For $remote_addr;
246 proxy_set_header X-Forwarded-Proto $scheme;
247 }
248 }
249 )))
250 )))
251
252 (% class="col-xs-12 col-sm-4" %)
253 (((
254 {{box title="**Contents**"}}
255 {{toc/}}
256 {{/box}}
257
258
259
260
261
262
263
264
265
266
267
268
269
270 __**Man kann sich auch mehrere Profile erstellen oder unterschiedliche Server nutzen, um ggf. Arbeit und privates zu trennen.**__
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305 )))
306 )))
307
308
309 = Funktionstest =
310
311
312 Wenn alles durch ist, den Dienst (neu-)starten und dann sollte er auf dem Port 8008 lauschen.
313
314
315 (% class="box" %)
316 (((
317 % sudo systemctl restart matrix-synapse.service
318 % sudo ss -tlp |grep 8008
319 LISTEN     0      0        ::1:8008        :::*         users:(("python",pid=24088,fd=10))
320 )))
321
322
323 Ob der Server für Clients erreichbar ist, kann man per netcat oder telnet prüfen (auch fürs System-Monitoring hilfreich):
324
325 (% class="box" %)
326 (((
327 % netcat localhost 8008 <<<$'GET /_matrix/client/versions HTTP/1.0\r\n\r'
328 HTTP/1.0 200 OK
329 Content-Length: 54
330 Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, Authorization
331 Server: Synapse/0.29.0
332 Cache-Control: no-cache, no-store, must-revalidate
333 Date: Sun, 20 May 2018 15:16:36 GMT
334 Access-Control-Allow-Origin: *
335 Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
336 Content-Type: application/json
337 )))
338
339 (% class="box" %)
340 (((
341 {"versions": ["r0.0.1", "r0.1.0", "r0.2.0", "r0.3.0"]}
342 )))
343
344
345 Im Log /var/log/matrix-synapse/homeserver.log sollte dann etwas in dieser Art stehen:
346
347
348 (% class="box" %)
349 (((
350 2018-05-20 17:12:18,831 - synapse.access.http.8008 - 95 - INFO - GET-65532- - - 8008 - Received request: GET /_matrix/client/versions
351 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"
352 )))
353
354
355 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.
356
357
358 = Worker einrichten =
359
360
361 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 …
362
363
364 = Element einrichten =
365
366
367 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.
368
369 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.
370
371 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.
372
373
374 (% class="box" %)
375 (((
376 server {
377 listen 443 http2 ssl;
378 listen [::]:443 http2 ssl;
379 )))
380
381 (% class="box" %)
382 (((
383 root /srv/www/default;
384 )))
385
386 (% class="box" %)
387 (((
388 location /_matrix/ {
389 access_log off;
390 proxy_pass http:~/~/[::1]:8008;
391 proxy_set_header X-Forwarded-For $remote_addr;
392 }
393 )))
394
395 (% class="box" %)
396 (((
397 location /.well-known/matrix/server {
398 access_log off;
399 add_header Access-Control-Allow-Origin *;
400 return 200 '{"m.server": "alea.gnuu.de:443"}';
401 }
402 )))
403
404 (% class="box" %)
405 (((
406 location /.well-known/matrix/ {
407 access_log off;
408 proxy_pass http:~/~/[::1]:8008;
409 proxy_set_header X-Forwarded-For $remote_addr;
410 }
411 )))
412
413 (% class="box" %)
414 (((
415 location /m/ {
416 access_log off;
417 alias /srv/www/m.jo-so.de/;
418 }
419 }
420 )))
421
422 (% class="box" %)
423 (((
424 % sudo systemctl reload nginx.service
425 )))
426
427
428 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.
429
430 Ein kleines Skript für die regelmäßige Aktualisierung von Element habe ich in der Anleitung zu jq beschrieben.
431
432
433 = Neuen Benutzer anlegen =
434
435
436 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:
437
438
439 (% class="box" %)
440 (((
441 % register_new_matrix_user -c /etc/matrix-synapse/homeserver.yaml http:~/~/localhost:8008
442 New user localpart [root]: user
443 Password:
444 Confirm password:
445 Make admin [no]:
446 Sending registration request...
447 Success.
448 )))
449
450
451 Das Zurücksetzen des Passworts gibt es die händische Bearbeitung der Datenbank und eine API-Funktion, die man mit curl aufrufen kann.
452
453
454 = TURN für Video- und Audioverbindungen einrichten =
455
456
457 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.
458
459 Nach der Installation (apt install coturn) muss die Konfigurationsdatei /etc/turnserver.conf wie folgt angepasst werden (Entnommen aus der Doku von synapse):
460
461
462 (% class="box" %)
463 (((
464 lt-cred-mech
465 use-auth-secret
466 static-auth-secret=Geheimen Schlüssel mit `pwgen -s 64 1` erzeugen
467 realm=jo-so.de
468 no-tcp-relay
469 cert=/etc/letsencrypt/live/host/fullchain.pem
470 pkey=/etc/letsencrypt/live/host/privkey.pem
471 no-multicast-peers
472 denied-peer-ip=10.0.0.0-10.255.255.255
473 denied-peer-ip=172.16.0.0-172.31.255.255
474 denied-peer-ip=192.168.0.0-192.168.255.255
475 pidfile="/dev/null"
476 secure-stun
477 mobility
478 no-tlsv1
479 )))
480
481 Den geheimen Schlüssel und die TURN-Verbindungen muss man noch in der homeserver.yaml eintragen und den Synapse-Server neustarten.
482
483 (% class="box" %)
484 (((
485 turn_uris:
486 - "turn:alea.gnuu.de:3478?transport=udp"
487 - "turn:alea.gnuu.de:3478?transport=tcp"
488 )))
489
490 (% class="box" %)
491 (((
492 turn_shared_secret=Geheimer Schlüssel
493 )))
494
495 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.
496
497 (% class="box" %)
498 (((
499 # https:~/~/github.com/coturn/coturn/blob/master/rpm/turnserver.service.fc
500 )))
501
502 (% class="box" %)
503 (((
504 [Unit]
505 Description=coturn
506 Documentation=man:coturn(1) man:turnadmin(1) man:turnserver(1)
507 After=network.target
508 )))
509
510 (% class="box" %)
511 (((
512 [Service]
513 User=turnserver
514 Group=turnserver
515 SupplementaryGroups=ssl-cert
516 PIDFile=/run/turnserver.pid
517 ExecStart=/usr/bin/turnserver -c /etc/turnserver.conf ~-~-log-file stdout
518 Restart=on-abort
519 )))
520
521 (% class="box" %)
522 (((
523 LimitNOFILE=999999
524 LimitNPROC=60000
525 LimitRTPRIO=infinity
526 LimitRTTIME=7000000
527 CPUSchedulingPolicy=other
528 UMask=0007
529 NoNewPrivileges=yes
530 )))
531
532 (% class="box" %)
533 (((
534 [Install]
535 WantedBy=multi-user.target
536 )))
537
538 AppArmor /etc/apparmor.d/usr.bin.turnserver
539
540 (% class="box" %)
541 (((
542 include <tunables/global>
543 )))
544
545 (% class="box" %)
546 (((
547 profile /usr/bin/turnserver {
548 include <abstractions/base>
549 include <abstractions/ssl_certs>
550 include <abstractions/ssl_keys>
551 )))
552
553 (% class="box" %)
554 (((
555 /etc/turnserver.conf r,
556 owner /var/lib/turn/turndb rwk,
557 }
558 )))
559
560
561 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.
562
563 (% class="box" %)
564 (((
565 Source: laptop (Port: 59697)
566 Destination: alea.gnuu.de (Port: 3478)
567 Protocol: STUN
568 Info: Allocate Request UDP lifetime: 3600 user: 1527072691:@test:alea.gnuu.de realm: alea.gnuu.de with nonce
569 )))
570
571 (% class="box" %)
572 (((
573 Source: laptop (Port: 59697)
574 Destination: alea.gnuu.de (Port: 3478)
575 Protocol: STUN
576 Info: CreatePermission Request XOR-PEER-ADDRESS: 192.168.178.21:48261 user: 1527072691:@test:alea.gnuu.de realm: alea.gnuu.de with nonce
577 )))
578
579 Im Wireshark konnte man aber auch beobachten, dass meine beiden Testgeräte direkt per IPv6 kommuniziert haben, ohne den Weg über den TURN-Server.
580
581
582 = Wechsel der Datenbank zu Postgres =
583
584 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.
585
586
587 (% class="box" %)
588 (((
589 % sudo apt install python-psycopg2
590 % sudo -u postgres sh -c 'createuser matrix-synapse
591 && createdb -O matrix-synapse -l C.UTF-8 -T template0 matrix'
592 )))
593
594 In der Konfiguration homeserver.yaml müssen noch die Einstellungen wie folgt geändert werden:
595
596
597 (% class="box" %)
598 (((
599 # Database configuration
600 database:
601 # The database engine name
602 name: psycopg2
603 # Arguments to pass to the engine
604 args:
605 database: matrix
606 user: matrix-synapse
607 host: /run/postgresql
608 application_name: matrix-synapse
609 )))
610
611 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.
612
613 Bei Systemd sollte man dann noch angeben, dass der Server erst nach Postgres gestartet wird:
614
615 (% class="box" %)
616 (((
617 % sudo systemctl edit matrix-synapse.service
618 [Unit]
619 After=network-online.target postgresql.service
620 )))
621
622 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.
623
624 (% class="box" %)
625 (((
626 % cd /tmp && sudo -u matrix-synapse synapse_port_db -v ~-~-curses \
627 ~-~-sqlite-database /var/lib/matrix-synapse/homeserver.db \
628 ~-~-postgres-config /etc/matrix-synapse/homeserver.yaml
629 )))
630
631 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.
632
633
634 = Wartungsarbeiten =
635
636 Auf der Webseite von Matrix werden diverse Anleitungen zur Wartung von Synapse und Moderation von Matrix angeboten.
637
638
639 = Datensicherung =
640
641
642 Wichtig für eine Wiederherstellung einer Matrix-Installation sind
643
644 die Konfigurationdateien unter /etc/matrix-synapse,
645 die Dateien unter /var/lib/matrix-synapse und
646 die Datenbank.
647
648 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.
649
650 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:
651
652
653 (% class="box" %)
654 (((
655 curl -H "Authorization: Bearer <access_token>" -d '' "http:~/~/localhost:8008/_synapse/admin/v1/purge_media_cache?before_ts=$(date +%s000)"
656 )))
657
658 (% class="box" %)
659 (((
660 (
661 echo 'DELETE FROM remote_media_cache WHERE filesystem_id NOT IN ('; \
662 find /var/lib/matrix-synapse/media/remote_content -type f -printf '%P\n' \
663 ~|sed "s,^[^/]*/,',; s,/~,~,g; s/\$/',/; \$s/,\$~/~/" |tail; \
664 echo ');'; \
665 echo 'DELETE FROM remote_media_cache_thumbnails WHERE media_id NOT IN (SELECT media_id FROM remote_media_cache);'
666 ) > /tmp/cleanup_rmc.sql
667 )))
668
669
670 = Ungenutzte Räume entfernen =
671
672 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:
673
674 (% class="box" %)
675 (((
676 mx_token=<Token eines Admins>
677 for room in $(curl -s ~-~-header "Authorization: Bearer $mx_token" \
678 'http:~/~/localhost:8008/_synapse/admin/v1/rooms?limit=800' \
679 ~|jq -r '[ .rooms[] | select(.joined_local_members == 0) ] |sort_by(.state_events) | .[].room_id')
680 do
681 echo -n "Purging $room: "
682 time curl -s -o /dev/null ~-~-header "Authorization: Bearer $mx_token" \
683 -X POST -H "Content-Type: application/json" -d "{ \"room_id\": \"$room\" }" \
684 'http:~/~/localhost:8008/_synapse/admin/v1/purge_room'
685 done
686 )))
687
688
689 == state_groups_state aufräumen ==
690
691
692 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.
693
694 Wer Rust installiert hat, kompiliert das Programm besser selbst aus den Quellen, denn Releases passieren eher selten:
695
696 (% class="box" %)
697 (((
698 cargo install ~-~-git https:~/~/github.com/matrix-org/rust-synapse-compress-state synapse_compress_state
699 )))
700
701 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
702
703 (% class="box" %)
704 (((
705 % sudo systemd-run ~-~-nice=4 -pCPUSchedulingPolicy=batch \
706 -pIOSchedulingClass=idle ~-~-uid=matrix-synapse ~-~-collect \
707 ~-~-unit=synapse-clear-state ~~/bin/synapse-clear-state
708 % journalctl -Stoday -u synapse-clear-state
709 )))
710
711 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.
712
713 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.
714
715 = device_inbox aufräumen =
716
717 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:
718
719 (% class="box" %)
720 (((
721 DELETE
722 ~-~- SELECT COUNT(*)
723 FROM device_inbox
724 WHERE device_id IN (SELECT device_id FROM devices WHERE hidden = true)
725 OR device_id NOT IN (SELECT device_id FROM devices);
726 )))
727
728 = event_forward_extremities aufräumen =
729
730 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).
731
732 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:
733
734 (% class="box" %)
735 (((
736 sudo -u matrix-synapse LC_ALL=C.UTF-8 psql -f matrix-clean-extremities.sql matrix
737 )))
738
739 = Alte Anhänge löschen =
740
741 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.
742
743 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.
744
745 Purge Remote Media API
746
747 (% class="box" %)
748 (((
749 curl -H "Authorization: Bearer <access_token>" -d '' \
750 "http:~/~/localhost:8008/_synapse/admin/v1/purge_media_cache?before_ts=$(date -d-6months +%s)000"
751 )))
752
753 = Alte Nachrichten löschen =
754
755 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.
756
757 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.
758
759 (% class="box" %)
760 (((
761 curl -H "Authorization: Bearer <access_token>" \
762 -H "Content-Type: application/json" \
763 -d '{ "delete_local_events": false, "purge_up_to_ts": '$(date -d-6months +%s)000' }' \
764 "http:~/~/localhost:8008/_synapse/admin/v1/purge_history/$room_id"
765 )))
766
767 Purge History
768
769 = Beseitigung von Räumen aus der Datenbank =
770
771 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.
772
773 = Unerwünschte Räume entfernen =
774
775 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.
776
777 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.
778
779 (% class="box" %)
780 (((
781 curl -H "Authorization: Bearer <access_token>" \
782 -X DELETE -d '{
783 "new_room_user_id": "@abuse:example.com",
784 "room_name": "Löschung des Raums …",
785 "message": "Der Raum … wurde gelöscht, weil …",
786 "block": true,
787 "purge": false
788 }' "http:~/~/localhost:8008/_synapse/admin/v1/rooms/$room_id"
789 )))
790
791 = Versiegelung von Räumen =
792
793 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. 😉
794
795 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:
796
797 (% class="box" %)
798 (((
799 {
800 "body": "This room has been replaced, blblabla",
801 "replacement_room": "!newroom:example.org"
802 }
803 )))
804
805 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:
806
807 (% class="box" %)
808 (((
809 curl -s -X PUT -H "Authorization: Bearer $mx_token" \
810 -H "Content-Type: application/json" \
811 ~-~-data-binary "{\"replacement_room\":\"$new_roomid\"}" \
812 "https:~/~/…/_matrix/client/r0/rooms/$old_roomid/state/m.room.tombstone"
813 )))
814
815 = Administration von Räumen
816 Zugangsbegrenzungen über die Raum-ACL =
817
818 Man kann für jeden Raum einzeln auch konfigurieren, welche Domains darauf Zugriff haben sollen. Diese ACL kann man über spezielle Events verändern:
819
820 in Element im Raum die Entwicklerwerkzeuge mit dem Befehl /devtools öffnen
821 auf Send custom event klicken
822 unten rechts auf den Knopf Event drücken
823 bei Event Type m.room.server_acl eintragen, State Key leer lassen
824 bei Event Content die Regeln (s. u.) einfügen
825 Send klicken
826 danach auf Back klicken
827 über Explore Room State, m.room.server_acl die ACL kontrollieren
828 im Chatverlauf erscheint die Meldung … set the server ACLs for this room. { "allow": [ "*" ], "allow_ip_literals": false, "deny": [ "matrix.kiwifarms.net", "*.kiwifarms.net" ] }
829
830 = Clients für Matrix =
831
832 == Element ==
833
834 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.
835 Für Element-Web gibt es einige Tastenkürzel zur Bedienung, die man sich mit Strg+/ (also Strg+Shift+7) ansehen kann.
836 Liste der Emojis
837 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
838 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.
839 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.
840
841 = Hydrogen =
842
843
844 Hydrogen Chat, vector-im/hydrogen-web: Lightweight matrix client with legacy and mobile browser support
845 unterstützt Verschlüsselung
846 unterstützt mehrere Accounts gleichzeitig, wobei man immer wechseln muss; es gibt keine gemischte Ansicht
847 scheint auf dem Framework von Element aufzubauen, sieht jedenfalls ähnlich wie Element aus
848 kann Kachelansicht mit mehreren Chats gleichzeitig
849 wirkt sehr spartanisch von Bedienung her (2021-12-29): keine Sprungmarke zur zuletzt gelesenen Nachricht; kein Home ohne geöffneten Chat
850
851 = Weitere Apps =
852
853
854 Fluffychat: Gibt es als App, Desktop-Programm und Web-Seite, orientiert sich mehr an Whatsapp. Der Raum für Fragen ist #fluffychat:matrix.org
855 SchildiChat: Ein angepasstes Element, das sich mehr an gängigen Messengern orientiert
856 Pattle: Hat ein anderes Bedienkonzept als Element und orientiert sich mehr an herkömmlichen Messengern.
857 Cinny, cinnyapp/cinny-desktop: Yet another matrix client for desktop
858
859 = Desktop-Programme =
860
861
862 Übersicht von Matrix-Clients
863 nheko (nheko) ähnelt laut Bildern im Web sehr WhatsApp und unterstützt verschlüsselte Räume
864 Quaternion sieht aus wie ein üblicher Chat-Client, unterstützt keine verschlüsselten Räume (Mai 2018)
865 Fractal ist eine GNOME-Anwendung und in Rust geschrieben. Bisher unterstützt es noch keine verschlüsselten Räume. (Mai 2018)
866 Setting Up WeeChat Again with weechat-matrix – paritybit.ca
867 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)
868
869 = Kommunikation mit anderen Netzwerken
870 IRC =
871
872 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.
873
874 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
875
876 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.
877
878 = Nick-Name registrieren bei libera.chat =
879
880 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:
881
882 mithilfe eines Webclients zum Netzwerk verbinden
883 seinen gewünschten Namen auswählen: /nick jo-so
884 ein Passwort mit dem Lieblingspasswortmanager generieren und die Registrierung starten: /msg NickServ REGISTER YourPassword youremail@example.com
885 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
886 den Webchat schließen
887 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
888 danach !reconnect ausführen
889 wenn die Verbindung wieder besteht, sollte nach !nick die Meldung »Currently connected to IRC networks: irc.libera.chat as jo-so« (DeepL-Übersetzung) erfolgen
890
891 Theoretisch müsste auch alles von Matrix aus funktionieren, aber ich habe dies nicht getestet.
892
893 mit dem Appservice user einen Direktchat starten
894 !nick jo-so
895 !cmd MSG NickServ REGISTER YourPassword youremail@example.com
896 !cmd MSG NickServ VERIFY REGISTER jo-so …
897 !username jo-so
898 !storepass YourPassword
899
900 Weitere Dokumentationen:
901
902 Nickname Registration | Libera Chat
903 End user FAQ · matrix-appservice-irc Wiki
904
905
906
907

Applications

Need help?

If you need help with XWiki you can contact: