Den ersten eigenen Mastodon Server aufsetzen - Tipps zur Installation

Die Entwicklungen der letzten Tage und Wochen auf Twitter treibt zahlreiche Nutzer dazu sich Alternativen zu suchen. Eine Möglichkeit könnte hierbei Mastodon sein, das sich zurzeit großer Beliebtheit erfreut. Doch die dezentrale Struktur von Mastodon mit einzelnen, unabhängigen Servern bietet neben vielen Vor- eben auch auch entscheidende Nachteile. Auf diese Aspekte möchte ich aber in einem gesonderten Beitrag später noch einmal eingehen.

Hier soll es lediglich um die Erstellung eines eigenen Mastodon-Servers gehen. Damit können einige der Nachteile des dezentralen Systems ausgeglichen werden, es kommen dafür allerdings weiterer Arbeitsaufwand zur Betreuung und Administration des Servers hinzu.

Grundsätzlich ist die Anleitung unter joinmastodon.org schon ziemlich detailiert und erklärt die meisten Arbeitsschritte relativ genau. Lediglich die Installation von Mastodon auf Ubuntu 20.04 und 22.04 gestaltete sich etwas schwieriger. Der Grund war, dass die von Mastodon verwendete Ruby Version noch OpenSSL 1.1 voraussetze, während die beiden genannten Ubuntu-Versionen bereits OpenSSL 3.0 an Bord hatte. Dies führte dann zu Fehlermeldungen wie dieser:

BUILD FAILED (Ubuntu 20.04 using ruby-build 20221116)

Auch hierzu werde ich demnächst noch mal etwas schreiben. In diesem Beitrag möchte ich aber nur kurz auf die Installation unter Debian 11 mit der oben verlinkten Anleitung eingehen.
Bei dieser musste ich nämlich an den folgenden zwei Punkten bei der Installation von mehreren Servern abweichen.

Swap-Datei anlegen & Node.js Speicherlimit erhöhen

Nachdem Mastodon von Github gezogen wurde, geht es im Schritt “Installing the last dependencies” darum mit bash bundle install -j$(getconf _NPROCESSORS_ONLN) die Ruby und JavaScript-Abhängigkeiten zu installieren. Dies schlug bei den frisch aufgesetzten Debian 11-Servern mit folgender Meldung fehl:

<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
 1: 0xb06730 node::Abort() [node]
 2: 0xa1b6d0  [node]
 3: 0xce1e60 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [node]
 4: 0xce2207 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [node]
 5: 0xe99875  [node]
 6: 0xe9a356  [node]
 7: 0xea887e  [node]
 8: 0xea92c0 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
 9: 0xeac23e v8::internal::Heap::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
10: 0xe6d77a v8::internal::Factory::NewFillerObject(int, bool, v8::internal::AllocationType, v8::internal::AllocationOrigin) [node]
11: 0x11e64e6 v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [node]
12: 0x15da159  [node]

That failed! Maybe you need swap space?

Um dies zu beheben, wurde zuerst eine Swap-Datei auf dem Server angelegt, wie auch in der Fehlermeldung angeregt. Allerdings brachte dies nicht den gewünschten Erfolg, die Fehlermeldung tauchte erneut auf.

Erfolgreicher gestaltete sich allerdings das Speicherlimit von Node.js zu erhöhen. Höchstwahrscheinlich ist bei diesem Prozess der Speicher voll gelaufen und hat dabei Daten verloren (Memory Leak), die dazu führten, dass die Installation fehlschlug. Um dies zu umgehen, wurde der Speicher von den standardmäßigen 512 auf 2048MB erhöht:

export NODE_OPTIONS="--max-old-space-size=2048"

NGINX-Konfiguration anpassen

Folgt man der Anleitung Schritt für Schritt, erhält man nach der Konfiguration des NGINX eine Fehlermeldung, da die Anleitung leider einen Fehler in der Logik hat. Konkret passiert dies bei dem Kommand systemctl reload nginx nachdem die Konfigurationsdatei verändert wurde. Die Fehlermeldung lautet:

Job for nginx.service failed.
See "systemctl status nginx.service" and "journalctl -xe" for details.

Dies geschieht, weil in dem zweiten server-Block in der Konfiguration bereits Zeilen unkommentiert eingefügt wurden, obwohl noch kein SSL-Zertifikat erstellt wurde. Dies kann behoben werden, indem vor reload des NGINX die Datei unter /etc/nginx/sites-available/mastodon folgendermaßen geändert und die ersten Zeilen des zweiten Blocks auskommentiert sind:

server {
  listen 80;
  listen [::]:80;
  server_name domain.de;
  root /home/mastodon/live/public;
  location /.well-known/acme-challenge/ { allow all; }
  location / { return 301 https://$host$request_uri; }
}

server {
  # listen 443 ssl http2;
  # listen [::]:443 ssl http2;
  # server_name domain.de;

  # ssl_protocols TLSv1.2 TLSv1.3;
  # ssl_ciphers HIGH:!MEDIUM:!LOW:!aNULL:!NULL:!SHA;
  # ssl_prefer_server_ciphers on;
  # ssl_session_cache shared:SSL:10m;
  # ssl_session_tickets off;

  # Uncomment these lines once you acquire a certificate:
  # ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
  # ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Nachdem der Certbot durchgelaufen und die entsprechenden SSL-Zertifikate generiert und hinterlegt wurden, können die Zeilen auskommentiert und der Pfad für ssl_certificate und ssl_certificate_key entsprechend angepasst werden.

Mit diesen Tipps sollte der erste Start des Mastodon-Servers bzw. der Mastodon Instanz auf dem Server dann problemlos möglich sein.