Meine Freizeitgestaltung unterliegt einer klaren Pendelbewegung, und nach modernen und sogar populären Kommunikationstechnologien wende ich mich wieder einem sehr alten Medium zu. Der Versand von E-Mails an eine überschaubare Anzahl von Empfängerinnen mittels einer einzigen Adresse lässt sich nämlich entweder mit einer Zeile in /etc/postfix/virtual bewerkstelligen, oder mit der Mailman Suite, bestehend aus den Projekten Mailman Core, Postorius, Hyperkitty, Mailmanclient, Hyperkitty Mailman plugin und Django-mailman3. Als wäre die Architektur nicht einschüchternd genug, gibt es zwei distinkte Einstiegspunkte in die Dokumentation, von denen nur einer zu einer stabilen Installationsleitung führt. Folgt man dieser Anleitung ohne jede Abweichung, denkt an das percent-encoding der Passwörter und konfiguriert die gewünschte Subdomain samt DKIM-Schlüssel und DNS-Einträgen für SPF, DKIM und DMARC (denn einige Mailprovider ignorieren die Subdomain Policy des bestehenden DMARC-Eintrags), gelangt man erstaunlich rasch zu einer funktionierenden Mailman-Instanz. Die Verwendung des Listennamens als Absenderadresse (DMARC mitigation) erzeugt in Verbindung mit use_esld = false; in /etc/rspamd/local.d/dkim_signing.conf (um die Reduktion von lists.eden.one auf die eSLD eden.one im Rahmen der DKIM-Signatur zu verhindern) wohlgeformte E-Mails, die allerdings unter Umständen mit der DKIM-Signatur der Absenderin verunziert sind:
Authentication-Results: posteo.de; dmarc=pass (p=quarantine dis=none) header.from=lists.eden.one
Authentication-Results: posteo.de; spf=pass smtp.mailfrom=eden.one
Authentication-Results: posteo.de;
dkim=pass (2048-bit key) header.d=lists.eden.one header.i=@lists.eden.one header.b=RohmQgN4;
dkim=fail reason="signature verification failed" (2048-bit key) header.d=eden.one header.i=@eden.one header.b=Io5jc3FE;
dkim-atps=neutral
Dieses Problem lässt sich mit dem Parameter remove_dkim_headers: yes in /etc/mailman3/mailman.cfg (um die ursprüngliche DKIM-Signatur zu entfernen) leicht beheben:
Authentication-Results: posteo.de; dmarc=pass (p=quarantine dis=none) header.from=lists.eden.one
Authentication-Results: posteo.de; spf=pass smtp.mailfrom=eden.one
Authentication-Results: posteo.de;
dkim=pass (2048-bit key) header.d=lists.eden.one header.i=@lists.eden.one header.b=0VbRo4SC;
dkim-atps=neutral
Im nächsten Schritt soll die Kommunikation zwischen Mailman und Postfix, die standardmäßig unverschlüsselt und unauthentifiziert über Port 25 erfolgt, abgesichert werden:
# /etc/mailman3/mailman.cfg
[mta]
smtp_user: mailman_sender
smtp_pass: mypassword
smtp_secure_mode: starttls
smtp_port: 587
smtp_verify_cert: no
Weil von diesem Moment an reject_sender_login_mismatch und smtpd_sender_login_maps greifen, benötigt mailman_sender einen Freibrief (und keinen Hack in mailman/src/mailman/mta/postfix.py, um die jeweils genutzten Listenadressen einzeln nachzutragen):
# /etc/postfix/controlled_envelope_senders
@lists.eden.one mailman_sender
Zum Schluss verschiebe ich /opt/mailman/mm/mailman-hyperkitty.cfg nach /etc/mailman3/mailman-hyperkitty.cfg und vollziehe die Änderung in /etc/mailman3/mailman.cfg nach:
[archiver.hyperkitty]
class: mailman_hyperkitty.Archiver
enable: yes
configuration: /etc/mailman3/mailman-hyperkitty.cfg
Nach diesen harmlosen Optimierungen verfalle ich auf die verhängnisvolle Idee, mailman-web und uwsgi aus Effizienzerwägungen über ein file socket kommunizieren zu lassen. Die initialen Änderungen in /etc/mailman3/uwsgi.ini und /etc/nginx/sites-enabled/mailman sind rasch erledigt, wenn man nicht vergisst, nginx die relevanten Umgebungsvariablen via uwsgi_params zu vermitteln (andernfalls: KeyError: 'REQUEST_METHOD'):
# /etc/mailman3/uwsgi.ini
[uwsgi]
# http-socket = 0.0.0.0:8000
socket = /opt/mailman/mm/var/mailman.sock
chmod-socket = 664
# /etc/nginx/sites-enabled/mailman
location / {
#proxy_pass http://127.0.0.1:8000;
uwsgi_pass unix:/opt/mailman/mm/var/mailman.sock;
include /etc/mailman3/uwsgi_params;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
}
Um mailman-web von den neuen Verhältnissen zu überzeugen, müssen zwei weitere Einstellungen angepasst werden:
# /etc/mailman3/settings.py
# override http://localhost:8000 in mailman_web/settings/mailman.py
POSTORIUS_TEMPLATE_BASE_URL = 'https://lists.eden.one'
# /etc/mailman3/mailman-hyperkitty.cfg
[general]
# base_url: https://127.0.0.1:8000/archives/
base_url: https://lists.eden.one/archives/
Nun funktioniert alles – außer der Archivierung von Nachrichten mit Hyperkitty (obwohl sie zuvor, mit http-socket, kein Problem war):
# /opt/mailman/web/logs/mailmanweb.log
PermissionError at /archives/list/testlist@lists.eden.one/thread/T6MCILAVQYV5QIOGHJB3JNJ26Z7E2Z35/reattach-suggest
[Errno 13] Permission denied: 'fulltext_index'
Es stellt sich heraus, dass das Verzeichnis fulltext_index durch das Whoosh-Backend der Haystack-Komponente referenziert wird. Ich probiere es mit einer vollständigen Pfadangabe –
# /etc/mailman3/settings.py
# override the faulty PATH in mailman_web/settings/mailman.py
HAYSTACK_CONNECTIONS = {
'default': {
'ENGINE': 'haystack.backends.whoosh_backend.WhooshEngine',
'PATH': "/opt/mailman/fulltext_index",
},
}
– und ernte einen Teilerfolg (eine andere Fehlermeldung):
ERROR 2022-12-01 09:18:00,111 1337915 hyperkitty.views.mailman Access to the archiving API endpoint was forbidden from IP 123.456.789.012, your MAILMAN_ARCHIVER_FROM setting may be misconfigured
Offenbar eine weitere Nebenwirkung des Wechsels von http-socket zu socket, die sich durch die Angabe der öffentlichen IP des Mailservers beheben lässt:
# /etc/mailman3/settings.py
# MAILMAN_ARCHIVER_FROM = ('127.0.0.1', '::1')
MAILMAN_ARCHIVER_FROM = ('123.456.789.012', '::1')
Natürlich frage ich mich langsam, ob ein socket wirklich so viel effizienter ist, aber genau in diesem Moment enden die Fehlermeldungen, und Hyperkitty arbeitet wie gewünscht: Threads lassen sich im Archiv suchen und neu zusammenfügen, und kombinierbare Threads werden sogar automatisch vorgeschlagen, wenn sich deren Betreffzeilen gleichen. Fröhliches reattachment führt allerdings dazu, dass Hyperkitty auf den Archivseiten aller Testlisten vergeblich nach anzuzeigenden Threads sucht (hyperkitty.models.thread.Thread.DoesNotExist: Thread matching query does not exist.), aber mein Debugging-Konto für diesen Monat ist schon weit überzogen.
Unterstützung bei der tastenden Fehlersuche erhalte ich ausnahmsweise nicht über eine der vielen Stackexchange-Seiten, sondern über mailman-users[at]mailman3.org, die zu meiner großen Befriedigung weniger sauber konfiguriert ist als meine Listen:
Authentication-Results: posteo.de; dmarc=pass (p=none dis=none) header.from=mailman3.org
Authentication-Results: posteo.de;
dkim=pass (1024-bit key) header.d=mailman3.org header.i=@mailman3.org header.b=0eJkGPKA;
dkim=fail reason="signature verification failed" (2048-bit key) header.d=eden.one header.i=@eden.one header.b=l4srDqkL;
dkim-atps=neutral
mailman-users[at]mailman3.org wird exklusiv von Mark Sapiro betreut, der meine Anmerkung zum Hyperkitty-Konfigurationspfad unverzüglich umsetzt und mir den Unterschied zwischen discussion list und announcement list erklärt:
The only difference between the announce style and the discussion style is that for the former, the list's allow_list_posts setting is False and for the latter it's True, and currently the only thing that controls is the content of the List-Post: header which is `<mailto:list@example.com>` for discussion lists and `NO` for announce lists.
Jedes Projekt sollte einen so freundlichen und geduldigen resident sage haben. Sehr angenehm ist auch der minimale Platzbedarf der Mailman-Datenbanken (< 20KB), vor allem im Vergleich zu gewissen raumgreifenden Sozialanwendungen. Allerdings trägt die Mailman Suite mit ihren verschiedenen Django-Anwendungen allein etwa zwei Prozentpunkte zur Systemlast bei (~ 5% CPU, ~ 15% RAM), obwohl Reichweite und Aktivität meiner Testlisten im nicht messbaren Bereich liegen.
Der Untergang von Twitter wird allerorten mit wohligem Schauer beschworen, und sehr aufgeregte, wohlmeinende Menschen raten dazu, sämtliche Direktnachrichten im Twitter-Account zu löschen und sofort ein Archiv der eigenen Twitter-Aktivitäten anzufordern. Ein Leak meiner Direktnachrichten würde lediglich mein untadeliges Sozialverhalten unterstreichen, aber das Archiv könnte interessant sein – was es nicht ist: Nicht nur der Umfang (1903 Tweets, davon 932 Replies und 254 Retweets, 1369 Likes) ist für den Nutzungszeitraum von 13 Jahren sehr überschaubar, sondern auch der Unterhaltungswert. Mit Hilfe des Archiv-Parsers und einiger regulärer Ausdrücke reformiere ich diesen Teil meiner digitalen Vergangenheit dennoch ein wenig, bevor er in die Website integriert wird. Mit Hilfe des Archivs lässt sich nämlich belegen, dass ich wenigstens einmal im Leben ein early adopter war, der sich schon im August 2018 für Mastodon interessierte, und dass URL shortener Teufelswerk sind: Sämtliche gekürzten URLs (< 2013) führen ins Nichts, während meine eigenen URLs (2009ff.) einwandfrei funktionieren.
Die Irritation über den fehlenden Verifikationshaken auf meinem Mastodon-Profil und Marco Arments beharrliche Werbung für Linode bringen mich dazu, einen separaten Webserver aufzusetzen, weil das Problem mit der direkten Nachbarschaft von Mastodon und Website zu tun haben könnte.
Allerdings wird die Website auch auf dem neuen Webserver nicht verifiziert, und ich gehe der Mastodon-Community so lange auf die Nerven, bis sich afontenot erbarmt und mich auf eine ungünstig konfigurierte /etc/hosts-Datei aufmerksam macht:
Total shot in the dark here: with certain resolver configurations, your domain name could get resolved locally to 127.0.0.1. So your Mastodon instance queries eden.one, gets the local address back. One possibility is that Mastodon rejects local IPs when DNS returns them. Probably not that unreasonable? Another possibility is that your webserver is not set up to listen on localhost.
Quick way to test this is to run nslookup eden.one on your server. If you get the localhost address back, there's a good chance this is your problem.
If so you could probably fix the problem by making sure that your local domain doesn't get resolved locally. E.g. change your hostname to be something other than eden.one, check the /etc/hosts file to see if it has any relevant entries, etc.
Einerseits sehr peinlich, andererseits: Verifiziert!
Ebenfalls verifiziert habe ich den funktionierenden Wechsel auf einen anderen Server (wenn auch nur mit der simpelsten Komponente des Server-Betriebs; einen Transfer des Mailstacks möchte ich mir lieber nicht ausmalen). Der neue Webserver ist übrigens trotz nominell schlechterer Leistungsdaten exakt gleich schnell, was die Entscheidung für eine statische Website erneut bestätigt.
Bisher habe ich die OAuth-Anmeldung über GitHub oder Google nur genutzt, wenn ich in Eile war, obgleich mein Google-Account vermutlich besser gesichert ist als die Nutzerdatenbank auf cryptobros.com. Heute nehme ich das aktuelle Sonderangebot der New York Times (20$/Jahr!) zum Anlass, ein Digitalabo abzuschließen und zum ersten Mal die Anonymisierungsfunktion des Dienstes Sign in with Apple zu verwenden. Es funktioniert in Verbindung mit Face ID erschreckend gut: Zwar schließe ich die Anmeldung mit meiner Apple ID (= E-Mail-Adresse) ab, der Zeitung wird aber nur ein Alias (abcdefghijk@privaterelay.appleid.com) übermittelt. Bei jeder weiteren Anmeldung auf der Website oder in den Apps der Zeitung kommt dasselbe Alias zum Einsatz, und auf Apple-Geräten mit Face ID/Touch ID ist der Anmeldevorgang kaum spürbar. Zu diesem Preis und im Vergleich zur Anmeldung auf der Website einer gewissen bayerischen Zeitung wirkt das etwas zukunftsträchtiger als die Bemühungen deutscher Zeitungsverlage, Zahlungen von Google zu erzwingen oder öffentlich-rechtliche Webseiten und Apps verbieten zu lassen.
Zu meinem Glück scheitert die Bezahlung des NYT-Abonnements mit Apple Pay. Die Bezahlung mit PayPal (Benutzername/Passwort/TOTP, Zahlungsmethode auswählen, bestätigen) holt mich auf den Boden der Realität zurück und verhindert, dass ich friktionslos durch das Internet gleitend Geld ausgebe. Außerdem hat Rspamd wenig Respekt vor der old gray lady und markiert einige besonders reißerische NYT-Newsletter (Your Monday Briefing: Five dead in Colorado shooting
) gnadenlos als Spam.
Auf Mastodon wird – natürlich sehr gesittet – diskutiert, ob das Netzwerk eher eine unvollständige Blogging-Plattform oder ein Messaging-Service im Gewand einer Website ist. Ältere Menschen verweisen in der Diskussion –
Now is probably a good time to say this:
If you're a blogger or artist, don't trust *any* social media as permanent.
No, not even here.
Create a website.
Keep it updated.
Manage the infrastructure.
Take regular backups.
Post links.
– instinktiv –
Each new generation on the web needs to learn that there’s no such thing as a permanent web identity on a commercial web service.
The only long-term solution to maintain your identity is:
- your own domain name
- Your own website/blog
- Several backups
Everything else is temporary. Your accounts on myspace, facebook, medium, twitter, google plus, youtube, tiktok, mastodon will one day disappear or become useless.
You don’t have a community
on those websites. Only ephemeral discussions.
– auf das POSSE/POSIOP-Prinzip und ein notwendiges Maß an Pessismismus/Paranoia. Noch radikalere Stimmen stellen auch das DNS-System als solide Grundlage einer Netzidentität in Frage und trauen nur ihren Schlüsselpaaren (mit denen sie dann vermutlich jede digitale Aktivität signieren), oder lassen ihre Toots Posts automatisch nach 14 Tagen löschen, um deren Vergänglichkeit zu unterstreichen. Tatsächlich garantieren weder der bewundernswerte Optimismus vieler Fediverse-Verfechterinnen (The Fediverse is the most important revolution in communications – probably since the Internet has been built.
) noch der Schlachtruf Protocols, Not Platforms
den langfristigen Erfolg von ActivityPub, denn bisher haben sich (oberhalb von TCP/IP und in Verbindung mit DNS) nur die Kombinationen HTTP/HTML/CSS und POP3/IMAP/SMTP/IMF als wirklich langlebig erwiesen.
Obwohl ich also in der privilegierten Situation bin, die Daten auf meiner Mastodon-Instanz täglich sichern zu können und daher das plötzliche Verschwinden aller Posts nicht fürchten muss, und obwohl selbst das Internet Archive Mastodon ernst nimmt, möchte ich mich nicht auf die langfristige Relevanz des Protokolls und Verfügbarkeit der Software verlassen. Ich lasse Nginx weiterhin ausgezeichnete Textdateien ausliefern (ohne dem Unicode-Fundamentalismus – You don't need HTML!
– meines Namensvetters zu verfallen) und warte ab, ob und wie sich ein Netzwerk-Effekt im Fediverse einstellt.
Die Idee, den Web-Werkzeugkasten weiter zu vereinfachen und Django mit all seinen Abhängigkeiten auch als Redaktionssystem zu Gunsten eines Website-Generators wie Hugo oder Pelican hinter mir zu lassen, verwerfe ich angesichts der Implikationen – Umsetzung von Brotkrumenpfaden und Querverweisen in einer völlig neuen Template-Sprache, Re-Implementierung der Zusatzfunktionen meines Backrezeptes, Transfer aller Einzelseiten aus der Datenbank in statische Markdown-Dateien – allerdings sehr schnell.
In den frühen Morgenstunden wurde Mastodon v4.0.2 veröffentlicht, und ich habe immer noch wenig zu verlieren (150 Following, 15 Follower, < 100 Posts):
su - mastodon
RUBY_CONFIGURE_OPTS=--with-jemalloc rbenv install 3.0.4
rbenv global 3.0.4
git fetch && git checkout v4.0.2
bundle install
yarn install
SKIP_POST_DEPLOYMENT_MIGRATIONS=true RAILS_ENV=production bundle exec rails db:migrate
RAILS_ENV=production bundle exec rails assets:precompile
systemctl restart mastodon-sidekiq.service; systemctl restart mastodon-streaming.service; systemctl restart mastodon-web.service
RAILS_ENV=production bundle exec rails db:migrate
systemctl restart mastodon-sidekiq.service; systemctl restart mastodon-streaming.service; systemctl restart mastodon-web.service
An dieser Stelle profitiere ich von der nahezu unveränderten Konfiguration meiner Instanz (git moniert nur den angepassten throttle-Wert in rack_attack.rb), andere Admins haben Kollateralschäden zu beklagen.
Das regelmäßige Durchlüften des Medien-Caches lässt sich mit der neuen Version besser automatisieren, und Posts lassen sich einfacher editieren, aber Avatare und Header bleiben ein Problem, das man nur auf Umwegen kontrollieren kann.
Unter der weisen Führung von Xi Jinping und seinen sorgfältig ausgewählten Mitarbeitern beeindruckt die Führungsmacht des 21. Jahrhunderts die Weltgemeinschaft unaufhörlich mit positiven Nachrichten: Dank der liberalen Pandemiepolitik genießt die chinesische Bevölkerung die Freiheit, sich nach eigenem Ermessen und in großer Zahl mit einem Virus zu infizieren, die Risiken des Raumfahrtprogramms werden – so gut es geht – auf dünn besiedelte Regionen begrenzt, und der wirtschaftlichen Entwicklung wird in vorübergehenden Schwächephasen konsequent Vorrang vor abstrakten Schutzkonzepten eingeräumt. Vor diesem Hintergrund kann auch der Regierungschef eines kleinen Handelspartners seine Bewunderung nicht verhehlen, der westliche Verbündete hat seine Rolle als Juniorpartner der Volksrepublik China schon seit längerem anerkannt und die administrative Eingliederung einer chinesischen Insel ist nur noch eine Frage der Zeit.
Je mehr datenverarbeitende Sozialanwendungen auf meinem Server laufen, desto drängender stellt sich die Frage nach einer geeigneten Backup-Strategie. Für Mastodon gibt es eine präzise Anleitung zur Sicherung der wichtigsten Daten (.env.production, Medien, PostgreSQL- und Redis-Datenbank). Weil Redis sein eigenes Backup erzeugt, benötige ich lediglich einen Cronjob für PostgreSQL –
53 12 * * * pg_dump -U mastodon -d mastodon_production > /backup/mastodon_production.sql && gzip -f -9 /backup/mastodon_production.sql
– und einige rbackup.py-Konfigurationen, die aber den Cache für entfernte Medien-Inhalte aussparen sollten (exclude: *cache*), denn:
snafu:~/live$ bin/tootctl media usage
Attachments: 1.09 GB (290 KB local)
Custom emoji: 40.1 MB (12.7 KB local)
Preview cards: 140 MB
Avatars: 1.96 GB (96.5 KB local)
Headers: 3.91 GB (413 KB local)
Mit bin/tootctl media remove --days=1 (als täglichen Cronjob) lässt sich der Attachments-Cache gut beherrschen, aber das ungebremste Caching von Avatar- und Header-Bildern fremder Menschen könnte ein Problem werden.
Damit der obige Cronjob funktioniert, ändere ich das Anmeldeverfahren für PostgreSQL von peer auf sha-cram256 für alle lokalen Nutzerinnen außer dem Superuser postgres (und hinterlege das Passwort für mastodon in .env.production).Selbst wenn man von Mastodons Caching-Problemen absieht, geht die Software sehr großzügig mit Speicherplatz um: Ein Dump der Datenbank ist schon nach wenigen Wochen deutlich größer als meine 14 Jahre alte Website-Datenbank (300 MB vs. 120 MB).
Das gilt auch für Synapse, deren Datenbank noch stärker zur Fülle neigt und mit großem Aufwand in Schach gehalten werden muss. Ich sichere sie daher nur einmalig (pg_dump synapse_production > /backup/synapse_production.sql && gzip -f -9 /backup/synapse_production.sql) und gemeinsam mit den Einstellungen (/etc/matrix-synapse).
Kommunikation ist schön, braucht aber viel Platz.
Trotz meiner Beschäftigung mit Delegation im Matrix-Kontext bin ich nicht auf die Idee gekommen, das Prinzip auf Mastodon zu übertragen. Erst zwei Toots machen mich auf die simple Konfiguration aufmerksam:
# /etc/nginx/nginx.conf
location = /.well-known/host-meta {
return 301 https://social.eden.one$request_uri;
}
# /home/mastodon/live/.env.production
LOCAL_DOMAIN=eden.one
WEB_DOMAIN=social.eden.one
Nach einem Neustart aller Beteiligten (service restart nginx; systemctl restart mastodon-web.service; systemctl restart mastodon-sidekiq.service) migriere ich den Account @janedenone@eden.one (Follower werden automatisch umgezogen, gefolgte Accounts und Bookmarks müssen per Export/Import mitgenommen werden) und verfüge nun über einen sehr schicken Namen im Fediverse. Zurück bleiben 146 Toots. Das Prinzip lässt sich (teilweise) auch ohne eigene Mastodon-Instanz anwenden, indem die Antwort der genutzten Mastodon-Instanz auf eine WebFinger-Anfrage auf dem eigenen Webserver hinterlegt wird.
Bei dieser Gelegenheit erhöhe ich das rate limit für authentifizierte Anfragen von 300 auf 3000, um die Fehlermeldung Too many requests
zu vermeiden:
# /home/mastodon/live/config/initializers/rack_attack.rb
throttle('throttle_authenticated_api', limit:3000, period: 5.minutes) do |req|
req.authenticated_user_id if req.api_request?
end
Außerdem lerne ich, dass Mastodon automatisch RSS-Feeds generiert, so dass ich Accounts grundsätzlich auch in meinem RSS-Reader folgen, das Twitter/Blogosphere-Schisma überwinden und RSS zu neuem Leben verhelfen könnte.
Nur wenige Stunden später verlinkt Dan Hon einen CLI-Client für Mastodon, der kaum Wünsche offen lässt (außer vielleicht der Erweiterung des tui-Kommandos um die Möglichkeit, vim als Editor zu verwenden), und Dr. Drang demonstriert die Verwendung der Mastodon-API mittels eines einfachen Python-Skriptes. Mastodon macht mir schon in den ersten Tagen viel Freude, trotz des bedrohlichen wachsenden Caches.
Seit der Eröffnung von social.eden.one betreibe ich zwei Anwendungen im Small Web, und obwohl ich der radikalen Vision (Jeder muss sein eigener Server sein
) eher skeptisch gegenüber stehe – die freien Serverkapazitäten und die schöne Domain eden.one fordern den Betrieb weiterer Anwendungen geradezu heraus. Nachdem vor einigen Monaten viel Zeit in den Serverbetrieb für eine völlig antiquierte Technologie (mit überraschendem Optimierungspotential auf mehreren Ebenen) geflossen ist, steht heute eine jüngere Kommunikationsform auf dem Programm.
Selbst Online-Chats sind älter als ich, und die noch heute verwendeten Protokolle evozieren eine weit zurückliegende Zeit vor dem Siegeszug des WWW. Damals chatteten meist Gruppen von Menschen themenbezogen in rooms oder channels, und Chats waren nur synchron möglich, wenn eine Einwahlmöglichkeit bestand. IRC-Dienste wie Libera haben im Wesentlichen noch dieses Profil. In modernen Chat-Plattformen für Unternehmen/Organisationen (Slack, Mattermost etc) treten neben die thematischen Kanäle Gruppen- oder Teamräume, und die Oberflächen haben sich seit den IRC-Hochzeiten deutlich weiterentwickelt. Gleichzeitig hat sich im privaten Bereich Instant Messaging als dominante Chat-Variante durchgesetzt. Diese Kommunikation (synchron oder asynchron) zwischen (mindestens) zwei Menschen erfolgt vor allem auf mobilen Endgeräten mit Diensten wie WhatsApp, Signal, Telegram oder Threema. Die Grenzen zwischen einem traditionellen Chat-Dienst und einem Messenger sind fließend, denn Kanäle lassen sich auch in einem Messenger einrichten – vor allem auf Telegram sind öffentliche Kanäle sehr populär.
Bei allen Unterschieden im Detail stützen sich fast alle Chat-/Messaging-Dienste auf eine Client-Server-Architektur, in der der Server nicht von den Nutzerinnen kontrolliert wird, und die Ausnahmen (Tox, Briar) richten sich laut Messenger-Matrix an Nerds
. Als Nicht-Nerd bleibt mir da nur, testweise eigene Chatserver aufzusetzen, um meinen trust issues und der Abhängigkeit von fremden Admins zu entkommen.
Der erste Testkandidat ist die Slack-Alternative Rocket.Chat. Ich ziehe ausnahmsweise die Installation via Snap dem manuellen Setup vor, weil ich nicht ein weiteres RDBMS (MongoDB) und eine zusätzliche Node.js-Version verwalten möchte. Entsprechend schnell geht alles, nach der Installation müssen lediglich zwei Parameter angepasst werden (u.a. um eine Kollision mit dem Mastodon-Port zu vermeiden):
$ snap install rocketchat-server
$ snap set rocketchat-server siteurl=https://chat.eden.one
$ snap set rocketchat-server port=4004
$ snap get rocketchat-server
Key Value
backup-on-refresh disable
ignore-errors false
mongo-oplog-url mongodb://localhost:27017/local
mongo-url mongodb://localhost:27017/parties
port 4004
siteurl https://chat.eden.one
Für die neue Subdomain wird ein Zertifikat benötigt (certbot certonly --nginx -d chat.eden.one), und Nginx wird als reverse proxy eingespannt:
server {
listen 443 ssl http2;
server_name chat.eden.one;
client_max_body_size 200M;
error_log /var/log/nginx/rocketchat.access.log;
ssl_certificate /etc/letsencrypt/live/chat.eden.one/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/chat.eden.one/privkey.pem;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
location / {
proxy_pass http://127.0.0.1:4004/;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Nginx-Proxy true;
proxy_redirect off;
}
}
Alle weiteren Konfigurationsschritte erfolgen über das Web-Interface der Applikation, vor allem die Erstellung eines Admin-Accounts, der Eintrag der SMTP-Zugangsdaten, die 2FA-Aktivierung und (in meinem Fall) die Beschränkung der Einrichtung neuer Konten (Admin → Accounts → Registration → Registration Form → Secret URL) sowie die Ergänzung des Templates für Einladungen um die Secret URL:
<h2>{Welcome_to Site_Name}</h2><p>{Visit_Site_Url_and_try_the_best_open_source_chat_solution_available_today}</p><a class="btn" href="[Site_URL]/register/ynUpX8gKoKwD9j9wY">{Join_Chat}</a>
Grundsätzlich kann man Rocket.Chat als standalone server betreiben, aber um Push-Benachrichtigungen an die mobilen Apps (iOS/Android) zu versenden (kostenfrei bis zu 10.000 pro Monat), muss der Server registriert werden (entgegen der Prämisse des Tests).
Nach einem Neustart des Service (systemctl restart snap.rocketchat-server.rocketchat-server.service) funktioniert alles einwandfrei (TTL < 20m). Der Komfort hat natürlich seinen Preis: Innerhalb von 24 Stunden werde ich zweimal 48 Stunden werde ich viermal vom Rocket.Chat-Vertrieb kontaktiert, basierend auf der Registrierung für die Rocket.Chat Cloud (und der heimtückischen Einstellung Allow Marketing Emails
). Der Fokus auf (zahlungsbereite) Unternehmen und auf die interne Kommunikation dieser Unternehmen ist sehr eindeutig. Rocket.Chat unterscheidet zwischen Channels, Teams, Direct Messages und Discussions, was für eine differenzierte unternehmensweite Kommunikation hilfreich, für soziale Kommunikation aber weniger relevant ist.
Ein föderierter Einsatz mit anderen Servern steht ebenfalls nicht im Vordergrund (Federation Support is a work in progress. Use on a production system is not recommended at this time.
), obwohl sich Rocket.Chat sogar mit der Matrix verbinden ließe (wenn man ihm einen eigenen Matrix-Homeserver zur Verfügung stellte). E2E-Verschlüsselung gegen maliziöse Admins (This feature is currently in beta!
) ist keine Stärke des Systems; nur unter bestimmten Bedingungen können zwei Personen mit Rocket.Chat vertraulich kommunizieren. Aktuell gehöre ich deshalb nicht zur Rocket.Chat-Zielgruppe (sorry, Aditya!).
Die Referenzimplementierung der Matrix-Spezifikation, Synapse, ist in vielerlei Hinsicht das Gegenteil von Rocket.Chat: E2E-Verschlüsselung und Föderation zählen zur Kernfunktionalität, dafür bietet Synapse kein Web-Interface und (mangels entsprechender Spezifikation) keine 2-Faktor-Authentifizierung via TOTP. Stattdessen wird bei der erstmaligen Anmeldung in einem Client ein Schlüssel erzeugt, den man in Form einer Security Phrase bei Anmeldungen in anderen Clients als zweiten Faktor verwenden muss (und den auch die Administratorin nicht kennt).
Die für Synapse empfohlene Installationsmethode ist ein Ansible Playbook, mit dem Synapse (und andere Anwendungen) in einem Docker-Container bereitgestellt werden – eindeutig zu viele Abstraktionsebenen für mich. Ich wähle den traditionellen Weg:
sudo apt install -y lsb-release wget apt-transport-https
wget -O /usr/share/keyrings/matrix-org-archive-keyring.gpg https://packages.matrix.org/debian/matrix-org-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/matrix-org-archive-keyring.gpg] https://packages.matrix.org/debian/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/matrix-org.list
sudo apt update
sudo apt install matrix-synapse-py3
Im Zuge der Installation werde ich nach dem gewünschten server_name gefragt, dessen Unabänderlichkeit und Bedeutung in den ersten Sätzen der Dokumentation unmissverständlich erklärt wird:
It is important to choose the name for your server before you install Synapse, because it cannot be changed later.
The server name determines the "domain" part of user-ids for users on your server: these will all be of the format @user:my.domain.name. It also determines how other matrix servers will reach yours for federation.
For a test configuration, set this to the hostname of your server. For a more production-ready setup, you will probably want to specify your domain (example.com) rather than a matrix-specific hostname here (in the same way that your email address is probably user@example.com rather than user@email.example.com) - but doing so may require more advanced setup: see Setting up Federation.
Natürlich überlese ich diesen eindringlichen Hinweis und wähle den Servernamen matrix.eden.one, zunächst ohne nachteilige Effekte. Wie üblich benötigt Synapse ein Zertifikat (certbot certonly --nginx -d matrix.eden.one) und einen reverse proxy:
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
# For the federation port
listen 8448 ssl http2 default_server;
listen [::]:8448 ssl http2 default_server;
server_name matrix.eden.one;
ssl_certificate /etc/letsencrypt/live/matrix.eden.one/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/matrix.eden.one/privkey.pem;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
location ~ ^(/_matrix|/_synapse/client) {
proxy_pass http://localhost:8008;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $host;
client_max_body_size 50M;
}
}
Etwas widerwillig öffne ich Port 8448 in der Firewall, damit mein frisch gestarteter Homeserver (systemctl start matrix-synapse.service) mit anderen Matrix-Servern sprechen kann, und melde mich stolz im Chatraum des Göttinger CCC (#neotopia:matrix.cccgoe.de). Dort werde ich angesichts meines Namens @janedenone:matrix.eden.one freundlich darauf hingewiesen, dass Delegation offenbar nicht richtig konfiguriert wurde (was mich zum vorschnell gewählten server_name zurückführt).
Obwohl die Umbenennung eines Homeservers kein neues Anliegen ist, wird der Wunsch nach einem anderen server_name in den FAQs als einer der wenigen Anwendungsfälle für tabula rasa genannt:
Deleting your database is unlikely to make anything better.
It's easy to make the mistake of thinking that you can start again from a clean slate by dropping your database, but things don't work like that in a federated network: lots of other servers have information about your server.
For example: other servers might think that you are in a room, your server will think that you are not, and you'll probably be unable to interact with that room in a sensible way ever again.
In general, there are better solutions to any problem than dropping the database. Come and seek help in https://matrix.to/#/#synapse:matrix.org.
There are two exceptions when it might be sensible to delete your database and start again:
- You have never joined any rooms which are federated with other servers. For instance, a local deployment which the outside world can't talk to.
- You are changing the
server_name in the homeserver configuration. In effect this makes your server a completely new one from the point of view of the network, so in this case it makes sense to start with a clean database. (In both cases you probably also want to clear out the media_store.)
Nach Rücksprache mit den netten Menschen in #synapse:matrix.org
- verlasse ich alle föderierten Räume
- stoppe ich den Dienst (
systemctl stop matrix-synapse.service)
- lösche ich die SQLite-Datenbank (
/var/lib/matrix-synapse/homeserver.db) und den Serverschlüssel (/etc/matrix-synapse/homeserver.signing.key)
- ändere ich den
server_name in /etc/matrix-synapse/conf.d/server_name.yaml (matrix.eden.one → eden.one)
- wechsele ich von SQLite auf PostgreSQL
- richte ich die
.well-known-Delegation für Server und Client ein (jeweils Port 443)
- entferne ich den Port 8448 aus der reverse proxy-Konfiguration und erweitere den Geltungsbereich der location-Anweisung
- schließe ich Port 8448 und
- starte den Dienst (
systemctl start matrix-synapse.service)
Nginx ist jetzt so konfiguriert –
# /etc/nginx/sites-enabled/default
location /.well-known/matrix/client {
return 200 '{"m.homeserver": {"base_url": "https://matrix.eden.one"}}';
default_type application/json;
add_header Access-Control-Allow-Origin *;
}
location /.well-known/matrix/server {
return 200 '{"m.server": "matrix.eden.one:443"}'; # explicit port required, default is 8448
default_type application/json;
add_header Access-Control-Allow-Origin *;
}
# /etc/nginx/sites-enabled/matrix
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name matrix.eden.one;
ssl_certificate /etc/letsencrypt/live/matrix.eden.one/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/matrix.eden.one/privkey.pem;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
location / {
proxy_pass http://localhost:8008;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host $host;
client_max_body_size 50M;
}
}
– dass der Aufruf von matrix.eden.one ein unmittelbares Erfolgserlebnis generiert –
matrix
It works! Synapse is running
Your Synapse server is listening on this port and is ready for messages.
To use this server you'll need a Matrix client.
Welcome to the Matrix universe :)
– und ich mit Hilfe der Client Well-Known URI Adressen der Form @matrixuser:eden.one verwenden kann. Dank der Synapse-Dokumentation war der Weg zu diesem Ziel etwas verschlungener als nötig: Obwohl die Installationsanleitung eine Nginx-Konfiguration für .well-known/matrix/client enthält, fehlt das Pendant für die Server-Delegation auf der reverse proxy-Seite (sie enthält nur Beispiele für Caddy und HAProxy). Mit der obigen Konfiguration ist der Federation Tester jedenfalls zufrieden.
Zum Abschluss konfiguriere ich den E-Mail-Versand (und stolpere wie üblich ein wenig über die SSL/TLS-Einstellungen). Damit sich Links in E-Mails auf matrix.eden.one (und nicht auf den server_name eden.one) beziehen, muss die passende public_base_url in /etc/matrix-synapse/homeserver.yaml eingetragen werden.
Neben Synapse benötigt man einen Matrix-Client, und es wird dringend vom Betrieb von Element (und implizit anderer Clients) unter der Homeserver-Domain abgeraten:
We do not recommend running Element from the same domain name as your Matrix homeserver. The reason is the risk of XSS (cross-site-scripting) vulnerabilities that could occur if someone caused Element to load and render malicious user generated content from a Matrix API which then had trusted access to Element (or other apps) due to sharing the same domain.
Nach meiner Erfahrung mit dem leichtfertig gewählten server_name bin ich vorsichtig geworden und verwende Element in der gehosteten Web-Version, der darauf basierenden Mac-Version und iOS-Version. Obwohl der Source-Code für Element unter einer Apache 2.0-Lizenz verfügbar ist, liegt der Schwerpunkt der Monetarisierung auf kostenpflichtigen Client-Varianten (Element One verbindet die Nutzung von Matrix, Signal, WhatsApp und Telegram innerhalb einer App für $5/Monat, Stand November 2022) und nicht auf dem SaaS-Chatserver (der Vertrieb hält sich angenehm zurück). Die Alternativen zum Element-Client sind ebenfalls Open Source-Projekte, und die Installation der CLI-basierten Clients scheitert bedauerlicherweise an der verwaisten Bibliothek python-olm.
In Verbindung mit einem Matrix-Homeserver kommen häufig ein oder zwei fremde Server zum Einsatz: Der Notary Server (default: matrix.org) stellt öffentliche Schlüssel von Matrix-Servern bereit, wenn diese Server vorübergehend nicht erreichbar sind, der Identity Server (default: vector.im) ermöglicht die Suche nach Matrix-Nutzerinnen per E-Mail-Adresse (oder Telefonnummer). Die optionale Verknüpfung von E-Mail-Adressen mit Matrix-Accounts erfordert zwei Schritte:
- Die E-Mail-Adresse wird in einem Matrix-Client eingetragen – der Homeserver versendet eine Verifikationsmail (mit Link auf matrix.eden.one).
- Die E-Mail-Adresse wird für die Suche via Identity Server freigegeben – der Betreiber Element.io versendet eine Verifikationsmail (mit Link auf vector.im).
Wenn man vor der Freigabe einer (verifizierten) E-Mail-Adresse eine Nutzerin über diese Adresse zu einem Chat einlädt, verschickt Element eine E-Mail (mit Link auf app.element.io). Hat man die Adresse freigegeben, wird die Einladung über den Homeserver (mit Link auf matrix.eden.one) zugestellt und erscheint parallel im jeweils verwendeten Client. Das ist sicher technisch und rechtlich sinnvoll gestaltet, aber etwas verwirrend, zumal alle E-Mails den Namen der auslösenden Client-Anwendung (Element) in der Betreffzeile enthalten:
# Vor der Freigabe
From: Element <noreply@element.io>
To: matrixuser@eden.one
Subject: Jan Eden has invited you to a room on Element
Hi,
Jan Eden (@jan:eden.one) has invited you into a room
on Element. To join the conversation please follow the
link below.
https://app.element.io/...
# Nach der Freigabe
From: Your Friendly Element homeserver <matrixserver@eden.one>
To: matrixuser@eden.one
Subject: [Element] @jan:eden.one has invited you to chat on Element...
Hi matrix,
[Element] @jan:eden.one has invited you to chat on Element...Empty Room
You've been invited, join at https://matrix.eden.one/...
Außerdem werden diese Einladungen (und Benachrichtigungen über neue, ungelesene Nachrichten) nur zugestellt, wenn die Nutzerin über einen Web- oder Desktop-Client angemeldet ist und dort die entsprechende Option aktiviert. Verwendet man die mobilen Element-Clients, gibt es nur Push-Benachrichtigungen. Und schließlich werden direct messages, die man über eine E-Mail-Adresse initiiert, zunächst nicht verschlüsselt (auch wenn man die Verschlüsselung nachträglich aktivieren kann), obwohl Einladungen per E-Mail in einen bereits verschlüsselten Raum möglich sind. Insgesamt spricht einiges dafür, Matrix-Kommunikation nicht auf E-Mail-Adressen zu stützen.
Element wird als Instant Messenger kategorisiert, obgleich die Matrix-Spezifikation sich ausschließlich auf öffentliche oder private Räume bezieht, von denen es mittlerweile 10 Versionen mit unterschiedlichem Funktionsumfang gibt. Der Client unterscheidet zwischen
- Rooms: This is where group discussions take place. Naming conventions help conversations be focused on a specific topic, and aid discoverability.
- People: This is where one-to-one chats take place.
Direct messages (chats) mit einzelnen Menschen lassen sich in der Element-Oberfläche (etwas) einfacher einrichten als rooms, und es gibt Befehle für die Umwandlung von direct messages in rooms und umgekehrt (/converttodm, /convertoroom). Technisch sind direct messages aber ebenfalls rooms, so dass an direct messages auch mehr als zwei Personen teilnehmen können (entgegen der Darstellung im Benutzerhandbuch). Um das Gesamtbild abzurunden, kann man direct messages und rooms in spaces gruppieren, wobei spaces technisch ebenfalls rooms sind. Obwohl diese Beschreibung wie der Fiebertraum einer UX-Designerin klingt, ist das Nebeneinander öffentlicher Chaträume (wie #synapse:matrix.org) und privater Kommunikation (mit @matrixuser:eden.one) gut gelöst und erleichtert die Kombination der beiden Chat-Nutzungsformen. Wenn man den ausbaufähigen Umgang mit E-Mail-Adressen (und das überschaubare Angebot an CLI-Clients) außer Acht lässt, ist ein Matrix-Homeserver eine ideale Lösung für Menschen, die verschlüsselt mit ihrem technikaffinen Bekanntenkreis kommunizieren und sich in Chaträumen weltweit austauschen möchten, ohne sich einer grenzenlosen Paranoia hinzugeben oder den Informationsaustausch ephemeral, low-stakes, and image-heavy
zu gestalten.
Die Serverlast hält sich übrigens nach wie vor in Grenzen (~ 1,5% CPU, ~ 10% RAM), was an meinem sparsamen Kommunikationsverhalten liegen mag. Den Aufenthalt in belebten öffentlichen Chaträumen und einen großen Bekanntenkreis kann ich mir angesichts des Speicherhungers der Synapse-Datenbank nämlich nicht leisten.
Schon seit vielen Jahren beklagen zunehmend griesgrämige Männer das Ende des freien Internets und beschwören seine Wiedergeburt aus der Asche kommerzieller Plattformen (wie im programmatischen Essay Protocols, not Platforms); Cory Doctorow zeichnet sich bei diesem Thema durch besondere Beharrlichkeit (und eine gewisse Selbstironie bei der Wahl seines Mediums) aus. Diese faszinierende Subkultur hat während der monatelangen Übernahme von Twitter erheblich an Zulauf gewonnen, und nach dem Abschluss der Transaktion (the bird is freed
) lässt der neue Besitzer keine Gelegenheit aus, ihre Kassandra-Rufe umgehend zu bestätigen, wobei seine absolute Macht über die Plattform von finanziellen Zwängen begrenzt wird. Auch sind die Ideen, Zugpferde für ihre Rolle zahlen zu lassen (und mit ihnen öffentlich zu feilschen), die Belegschaft zur Steigerung ihrer Motivation in Angst und Schrecken zu versetzen oder Werbekunden zu bedrohen, vielleicht nicht ganz zu Ende gedacht (selbst wenn findige Geschäftsleute die darin enthaltene business opportunity schnell erkannt haben).
Wohlwollende Nutzerinnen begrüßen Mr. Musk dennoch sehr herzlich (Welcome to Hell, Elon
), wünschen ihm Erfolg oder planen jedenfalls keinen Wechsel auf andere Plattformen (Why would I leave Twitter? It's like living in NY and not taking the subway. Sure it's dirty and smells bad, but it's how you get places.
), während rechte Trolle die Hölle schon mal anheizen.
Viele andere Menschen suchen nach einer Mikroblogging-Alternative und erinnern sich ihrer seit Jahren verwaisten Mastodon-Accounts oder registrieren sich (in Massen) auf einer der größeren Instanzen. Sie genießen oder bestaunen die ungewohnte Atmosphäre (What I really enjoy about this space is how there are so few crypto bros.
) und das abweichende, gesündere, überlegene feature set (Bookmarks!). Die unterbezahlten Admins der großen Instanzen ringen mit dem Ansturm und werfen zusätzliche Hardware in die Flut. Während Hugh Rundle den aktuellen eternal september als Invasion
in eine sensible Subkultur empfindet, lehnt Kathrin Passig solche Metaphern – Ansturm, Flut, Invasion – ab. Bei aller Sympathie für eine reflektierte Sprachverwendung – stark erhöhtes Interesse
und rasch wachsende Nutzerzahlen
werden der Atmosphäre auf vielen Instanzen nicht gerecht.
Es wird sich zeigen, ob Mastodon Twitter als place to be ablösen wird (unwahrscheinlich), oder ob es sich mit einer breiten Nutzerinnenbasis (> 100M) als antivirales Gegenmodell zum zentralisierten Mikroblogging etablieren kann (hoffentlich).
Das alles könnte mir – auf einer praktischen Ebene – relativ egal sein, denn ich nutze Twitter im Wesentlichen als einen (zusätzlichen) Feedreader, in dem neben verschiedenen Medien auch unterhaltsame Einzelpersonen publizieren. Shitstorms nehme ich nur in Ausnahmefällen wahr, weil ich sehr selten Reaktionen auf Tweets beachte, spektakuläre Eilmeldungen verifiziere ich auf zusätzlichen Kanälen, und Tweetbot liefert eine chronologische Timeline ohne Werbung und Trolle. Die aktive Nutzung eines Microblogging-Dienstes verträgt sich – selbst mit einem großzügigen Limit von 500 Zeichen – nicht gut mit meiner Weitschweifigkeit und mangelnden Spontaneität. Selbst der in der Evolutionsbiologie ausgemusterte Name der Plattform (Mastodon as a genus name is obsolete; the valid name is Mammut
) ist klanglich eine Zumutung und mit seiner ungalanten Anspielung auf die weibliche Physiognomie völlig aus der Zeit gefallen.
Andererseits. Die Verlockung, als Betreiberin eines (Knotens innerhalb eines) freien sozialen Netzwerks (innerhalb des Fediverse) aufzutreten, ist sehr groß, und mein Server klagt schon länger, dass er sich mit Nginx, Postfix und Dovecot unterfordert fühlt. Schon die erste Verheißung für angehende Mastodon-Admins klingt vielversprechend –
Absolute control over your own voice on the web, not subject to anyone else's rules or whims. Your server is your property, with your rules. It will exist as long as you want it to exist.
– die zweite richtet sich eher an Menschen mit ausgeprägteren sozialen Bedürfnissen als ich –
You are not isolated on your own server. You can follow anyone on any other server, and they can follow you and you can exchange messages just like if you were on the same server.
– während die dritte einen Betrieb ohne potentiell ungehobelte fremde Nutzerinnen in Aussicht stellt:
You can either limit sign-ups to be the only one on the server and run it like personal (micro)blog, maintain an invite-only community for family or friends or run a server anyone can sign up on, it's up to you!
Ich beschließe daher, das social media equivalent of Desktop Linux
passend zum YoLD als persönliches Mikroblog aufzusetzen, schließlich möchte ich nicht in dieselbe Falle tappen wie Mr. Musk (Please mind that providing a public internet service involves moderation work and community management, and that such work becomes more complicated the larger your server grows.
), Geld in zusätzliche Server/Kerne oder Zeit in die optimale Konfiguration von Sidekiq investieren.
Die fürsorgliche Mastodon-Dokumentation beginnt mit Sicherheitshinweisen und führt sehr geschmeidig durch die Installation von Ruby (on Rails), Node.js, PostgreSQL, einer Reihe von Hilfspaketen und schließlich der Mastodon-Software. Man sollte allerdings nicht von den empfohlenen, etwas veralteten Versionen (Node.js 16, Ruby 3.0.3) abweichen, wenn man nicht Komplikationen zu einem sehr späten Zeitpunkt riskieren möchte.
Zur neuen Subdomain lasse ich mir ein passendes SSL-Zertifikat ausstellen (certbot certonly --nginx -d social.eden.one) und vermenge die bestehende Nginx-Konfiguration mit der bereitgestellten Datei. Nginx stolpert zunächst über unterschiedliche ssl_session_cache-Werte für meine Website und die Mastodon-Instanz, aber der Konflikt lässt sich lösen, indem der Session-Cache im übergeordneten http-Kontext festgelegt wird. Eine weitere Verzögerung ergibt sich durch den Unterschied zwischen SMTPS auf Port 465 und SMTP auf Port 587 mit STARTTLS bzw. den Parameter SMTP_SSL=true in der Konfigurationsdatei .env.production:
Oct 29 19:00:30 eden bundle[838075]: 2022-10-29T19:00:30.636Z pid=838075 tid=isfb WARN: OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=error: wrong version number
Nach der Behebung dieses Problems und dem Start der Mastodon-Services ist die Instanz offiziell eröffnet. Mastodon übt in /var/log/syslog leise Kritik an meiner Redis-Konfiguration –
Oct 30 16:48:36 eden bundle[867373]: WARNING: Your Redis instance will evict Sidekiq data under heavy load.
Oct 30 16:48:36 eden bundle[867373]: The 'noeviction' maxmemory policy is recommended (current policy: 'volatile-ttl').
Oct 30 16:48:36 eden bundle[867373]: See: https://github.com/mperham/sidekiq/wiki/Using-Redis#memory
– aber heavy load
ist eher nicht zu erwarten: Mit Mastodon nutze ich etwa 8% des verfügbaren RAMs (statt 1%), die CPU-Last liegt unverändert bei knapp 1,5%. Angesichts der reibungslosen Installation blicke ich dem bevorstehenden Upgrade auf Mastodon v4.0 entspannt entgegen.
Als erste Amtshandlung schließe ich die Tore ein wenig (Preferences → Administration → Site settings → Approval required for sign up), aktiviere die 2-Faktor-Authentifizierung für alle Accounts (2) und übernehme die Nutzungsbedingungen von legal.social. Für einen Pedanten wie mich ist es sehr befriedigend, die bestehenden Accounts von mastodon.social und social.tchncs.de umleiten zu können. Die link verification zwischen meinem Mastodon-Profil und meiner Website mit Hilfe des Attributs rel="me" funktioniert nicht, weil Mastodon und Website auf demselben VPS laufen, und aus demselben Grund stützt sich social.eden.one auf die viel bessere implizite Domain-Verifikation:
Because Mastodon can be self-hosted, there is no better way to verify your identity than to host Mastodon on your own domain, which people already trust.
Außerdem installiere ich den begehrten blauen Haken als zusätzliches Emoji (Preferences → Administration → Custom emojis → :verified: → Copy) und benenne mich kostenlos in Jan Eden :verified:
um. Mein innerer Fünfzehnjähriger kichert zufrieden über diesen Regelbruch (And whatever you do, don’t use the verified
emoji
).
Der Fedifinder findet in meinem Twitter-Account insgesamt 8 Gefolgte mit Hinweisen auf Mastodon-Accounts, die ich als CSV-Datei importieren kann, und auch sonst mangelt es nicht an freundlicher Unterstützung beim Einstieg in den Mastodon-Teil des Fediverse. Bei der Auswahl der gefolgten Accounts geht einem kein Algorithmus zur Hand, die Stimmung ist familiärer und vereinzelte Crosspostings stören kaum. Falls Mr. Musk Twitter tatsächlich zu Grunde richtet, habe ich einen bequemen Logenplatz, denn Twitter-bezogene Toots machen einen erheblichen Teil meiner Timeline aus (so wie auch mein Feedreader derzeit voller Twitter-Reflexionen ist).
Vor lauter Aufregung vermassele ich die feierliche Einweihung mit einem #Introduction-Toot und antworte stattdessen auf einen Toot. So viel zu den Vorzügen der Spontaneität.
Mit macOS Ventura präsentiert Apple wieder einmal eine neue Variante der Fensterverwaltung:
Managing multiple overlapping windows has been a defining feature of using a Mac since 1984. For decades, it’s been a huge productivity boost to savvy Mac users, since it allows multiple panes of information of arbitrary sizes to be arranged arbitrarily on a user’s screen. But for some users, the Mac’s windowing metaphor has led to confusion and frustration, whether it’s windows covering other windows or hidden or minimized windows being unfindable.
You, an expert Mac user, may be fine with the way things are. But Apple’s got a broader audience to serve with the Mac—there are more Mac users today than ever before, and the Mac installed base just keeps growing—and it’s never really been satisfied with the available window-management tools on the Mac.
I have to admire Apple’s insistence on this topic. Over the decades it’s tried windowshades, a floating application bar, Dock minimization, single-window mode, Exposé, Spaces, Mission Control, Full Screen, and Split View, and while many of those features have been embraced by some Mac users, the company still doesn’t think that it’s cracked it.
So here comes the latest attempt to refine window management on the Mac: Stage Manager, which makes its debut with macOS Ventura (and iPadOS 16, but that’s another story). Stage Manager is best thought of as a way to create arbitrary groups of windows that you can quickly switch between.
Ich neige mit zunehmendem Alter dazu, neumodische Spielereien achselzuckend zu ignorieren, solange mein LaunchBar und app switching wie gewohnt funktionieren. Abgesehen von einer rabiaten Umgestaltung der Systemeinstellungen –
System Preferences was long overdue for a refresh, but System Settings isn’t the redesign we needed. Instead, it’s a clear example of why you can’t just graft iOS or iPadOS design onto macOS and call it quits.
– und der Einführung neuer Bugs glänzt mac OS Ventura in der Paradedisziplin neuer Betriebssystemversionen, der Entfernung hilfreicher (Anwendungen|Funktionen|Optionen). Aktuell betrifft das verborgene Login Items, Datumsformate, Network Locations –
System Preferences used to have a Network Locations
feature, where you could set up profiles that would change your network settings based on where you were—for example, if you used a fixed IP address on your Ethernet connection at home but wanted to use DHCP at work or if you wanted your computer to use wired Ethernet first at home but prioritize Wi-Fi at work.
I doubt many people will miss this since it’s not as though Ethernet adapters are common on Macs anymore, and you can set different settings for different Wi-Fi networks or Ethernet dongles anyway (your dock on your desk and your USB Ethernet dongle at home can still have different settings). But if you do rely on it, you’ll need to figure out something else.
– und die Möglichkeit, (Encapsulated) PostScript-Dateien mit der Vorschau-Anwendung zu öffnen:
Other apps that can view or convert .ps and .eps files are available from the App Store and elsewhere.
Schwer nachvollziehbar, zumal die Formatunterstützung offenbar noch im System vorhanden ist. Tatsächlich erzeuge ich regelmäßig PostScript-Dateien mit Acrobat Pro (File → Export to → PostScript), um aus proprietären, nur mit Acrobat lesbaren Dokumenten standardkonforme PDF-Dateien abzuleiten. Künftig wird GhostScript (ps2pdf) diesen Ausbruch aus dem Adobe-System unterstützen müssen. Eventuell ist diese Feature-Anämie aber auch ein subversiver Akt von CLI-Fans im macOS-Entwicklungsteam, denn Datumsformate und Netzwerkumgebungen sind nicht wirklich verschwunden – sie haben nur ihr GUI abgeben müssen.
Ganz unabhängig von U-Booten bei Apple halte ich es mit John Gruber:
I’ve updated my devices across the board, with the exception of my Macs. I have no particular or specific concerns about Ventura, I’m just always more conservative about MacOS updates than other devices, because my Macs are so essential for my work.
Die neue Führung der KPCh sorgt überraschend für Überraschungen:
Der Parteichef stellte anschließend seine neue Führungsmannschaft mit treuen Gefolgsleuten vor. Im mächtigen neuen Ständigen Ausschuss des Politbüros trat überraschend der Shanghaier Parteichef Li Qiang an zweiter Stelle auf das Podium. Die Auswahl des 63-Jährigen deutet darauf hin, dass der enge Vertraute von Xi im März neuer Regierungschef werden soll. Der bisherige Regierungschef Li Keqiang zieht sich vorzeitig zurück und gehört dem Zentralkomitee auch nicht mehr an, obwohl er erst 67 Jahre alt ist. Er wird auf der Jahrestagung des Volkskongresses im März als Premier abtreten.
Wenn eine Pensionierung selbst in anstrengenden Positionen mit 67 Jahren als vorzeitig gilt, sehe ich schwarz für Liu Ziheng, Xiang Biao und Yu Zhenming. Immerhin scheint es aber weiterhin eine informelle Altersgrenze zu geben:
Kurz vor den Abstimmungen über die Änderungen der Parteiverfassung eskortierten Saaldiener den 79-jährigen Amtsvorgänger Xis hinaus. In den Aufnahmen wirkte es so, als räume Hu seinen Sitz neben Xi nur widerwillig. Chinas staatliche Nachrichtenagentur Xinhua berichtete jedoch später, Hu habe sich nicht wohl gefühlt und sei daraufhin aus dem Saal geführt worden.
Einige Bürgerinnen der russischen Föderation entwickeln bereits in jungen Jahren einen bewundernswert subversiven Umgang mit staatlichen Sprachregelungen:
Selbst, wenn Krieg herrscht, kann der doch politische Konflikte nicht lösen. Das kann nur unser Präsident, der über uns steht. Wir normalen Bürger können da in keiner Weise helfen.
Ich möchte den Milizionär sehen, der diese schicksalergebene Anhängerin des Präsidenten wegen der fehlerhaften Bezeichnung der militärischen Spezialoperation und des Plädoyers für ein Ende der Kampfhandlungen belangen würde.
Bei jeder manuellen Eingabe eines GnuPG-Passworts im macOS-Terminal steht mir die vorbildliche Zusammenarbeit von pinentry-gnome und Seahorse vor Augen, und trotz des Cachings durch den gpg-agent gebe ich solche Passwörter sehr oft ein. Das von Ralph Seichter betreute Paket GnuPG for OS X unterstützt zwar die Hinterlegung der Passwörter im macOS-Schlüsselbund, aber ich möchte ungern Homebrew und manuelles Paketmanagement mischen. Erfreulicherweise ist die schlüsselbundunterstützende GPGOSX-Komponente pinentry-mac auch via Homebrew verfügbar. Nach der Installation (brew install pinentry-mac) genügen eine einzige Zeile –
# ~/.gnupg/gpg-agent.conf
pinentry-program /opt/homebrew/bin/pinentry-mac
– und ein Neustart des gpg-agent, um wiederholte Passworteingaben zu vermeiden. Obwohl die Kombination von Schlüsselbund und Touch ID noch etwas eleganter wäre, begnüge ich mich vorerst mit feature parity zwischen macOS und Ubuntu/Gnome. In diesem Zusammenhang erwäge ich kurz, ob 1Password die Verwaltung meiner SSH-Schlüssel übernehmen könnte, aber in diesem Korb sind bereits mehr als genug Eier.
Als hätte das Unternehmen sein Profil nicht bereits hinreichend geschärft, möchte N26 nun auch noch den Handel mit Kryptowährungen anbieten.
Unabhängig von der in Teilen überraschend positiven Außenwahrnehmung ist Deutschland besonders (betroffen|verwundbar|abhängig|rückständig) in Bezug auf Fachkräftemangel, Energieversorgung, Exporte (insbesondere von Personenkraftwagen), Produktfälschungen, Klimawandel, Artensterben, Bewegungsmangel, Digitalisierung, Innovationsfähigkeit, Infrastruktur und das Bildungssystem.
Es ist wohl an der Zeit, über eine Auswanderung in das entfesselte Global Britain unter der visionären Liz Truss (growth, growth, growth) oder ein stabiles demokratisches Gemeinwesen innerhalb der Europäischen Union nachzudenken.
Eine Zurechtweisung durch die eigene Mutter scheint in Österreich ein starkes politisches Motiv zu sein –
Die WKStA führt die Ermittlungen in der mittlerweile umfangreichen Affäre, die durch Schmids Aussagen nun auch wieder in die öffentliche Aufmerksamkeit rückt. Zahlreiche Medien zitierten Passagen aus Schmids Aussagen bei der WKStA, so etwa der ORF: Wir haben Dinge gemacht, die nicht in Ordnung waren. Zum Umdenken hat mich bewogen, dass meine Mutter gesagt hat, wir haben dich so nicht erzogen. Wenn du etwas falsch gemacht hast, dann steh dazu, und das mit allen Konsequenzen.
– das manchmal zufällig mit (selbstverständlich nachrangigen) juristischen Erwägungen korreliert:
Ein weiteres Motiv könnte Schmids Wunsch sein, in künftigen Verfahren als Kronzeuge geführt zu werden und damit sein eigenes Strafmaß gegebenenfalls signifikant zu reduzieren. Laut WKStA ist Schmid im April mit diesem Anliegen an die Ermittler herangetreten.
Offensichtlich hat das vierte Gebot in Thomas Schmids persönlichem Katechismus Vorrang sowohl vor dem siebten als auch vor dem achten Gebot.
Die Verwendung eines Ubuntu Server-Images und das anschließende Upgrade auf Ubuntu Desktop (apt install ubuntu-desktop) auf einem ThinkPad ändert nur auf den ersten Blick nichts an der Konfiguration als Desktop-System. Tatsächlich werden Netzwerkverbindungen unter Ubuntu entweder durch networkd (Server) oder den Network Manager (Desktop) verwaltet, und die Installation von Ubuntu Server impliziert eine Entscheidung für networkd.
Beim Start des Systems besteht networkd zum Beispiel darauf, dass ein Ubuntu-Server über eine aktive Ethernet-Verbindung verfügen sollte, und akzeptiert die fehlende Verbindung erst nach geschlagenen zwei Minuten. Diese Beharrlichkeit kann mit einer Ergänzung der netplan-Konfigurationsdatei umgangen werden:
# /etc/netplan/00-installer-config.yaml
network:
ethernets:
enp0s31f6:
dhcp4: true
optional: true
version: 2
Auch die Verwendung des lokalen DNS-Servers kann networkd auf diesem Weg nähergebracht werden:
# /etc/netplan/00-installer-config-wifi.yaml
network:
version: 2
wifis:
wlp4s0:
access-points:
MySSID:
password: mypassword
dhcp4: true
dhcp4-overrides:
use-dns: false
nameservers:
addresses: [192.168.78.42]
Allerdings bleibt das Problem, dass eine von networkd verwaltete Verbindung aus Sicht des Network Managers (und damit in der Gnome-Oberfläche) unavailable
ist. Die Übergabe der Netzwerkverwaltung erfordert radikale Schritte:
sudo rm /etc/netplan/00-installer-config-wifi.yaml
sudo vi /etc/netplan/01-network-manager-all.yaml
# Let NetworkManager manage all devices on this system
network:
version: 2
renderer: NetworkManager
sudo netplan generate
sudo netplan apply
sudo service NetworkManager restart
Nach einem Neustart erscheinen sämtliche WLAN-Einstellungen wie von Zauberhand in der Gnome Shell.
Im Zuge der Inbetriebnahme von vim auf einem neuen System fällt mir auf, dass sich eine visual selection nicht mehr mit der Zeichenfolge s) einklammern lässt, obwohl ich die gesamte Konfiguration (.vim/ und .vimrc) unverändert vom bisher genutzten System übernommen habe. Der Grund wirft kein gutes Licht auf meine Update-Gewohnheiten:
The s visual mode map was removed 11 years years ago. 6fb16ea
Trotzdem frage ich mich, warum der Commit von 2011 auf dem neuen System wirksam wurde, obwohl das antiquierte ~/.vim/plugin/surround.vim mit umgezogen ist. Das Geheimnis muss ungelöst bleiben, bietet aber die Gelegenheit, vim-surround und vim-ragtag zu aktualisieren und .vim/ aufzuräumen.