Firefox-Sync-Server selbst hosten

 (blog.diego.dev)
1 Punkte von GN⁺ 2025-03-03 | 1 Kommentare | Auf WhatsApp teilen
  • Nach dem Wechsel von Firefox zu LibreWolf sollte die Browser-Synchronisierung selbst betrieben werden; nach der Prüfung mehrerer Repositories und Docker-Konfigurationen entstand schließlich ein funktionierender Server
  • Mozillas alter syncserver ist zwar eine All-in-one-Konfiguration, warnt aber vor eingestellter Wartung, sodass das Rust-basierte syncstorage-rs die realistischere Option wurde
  • Das offizielle Docker-Verfahren war wegen der Kopiervorgänge für grpcio, protobuf und mozilla-rust-sdk schwer nachzuvollziehen; die Community-Konfiguration syncstorage-rs-docker wurde zur tatsächlichen Deployment-Basis
  • Die endgültige Konfiguration startet per docker-compose.yaml MariaDB 10.6.13 und firefox_syncserver; Caddy fungiert als Reverse Proxy auf firefox_syncserver:8000
  • Persistente DB-Daten, knapper Speicherplatz und Experimente mit Docker-Abläufen waren die größten Hürden; wer mit Docker- oder DB-Betrieb nicht vertraut ist, muss mit hoher Einrichtungskomplexität rechnen

Warum der Wechsel von syncserver zu syncstorage-rs erfolgte

  • Nach dem Umstieg von Firefox auf LibreWolf begann die Arbeit daran, einen Firefox-Sync-Server selbst zu hosten
  • Der zuerst gefundene Mozilla syncserver war ein All-in-one-Paket fürs Self-Hosting
    • Enthielt den tokenserver für die Authentifizierung und syncstorage für die Speicherung gemeinsam
    • In der Build-Historie gab es ein „failed“-Tag
    • Im Repository wird darauf hingewiesen, dass es nicht mehr gewartet wird und man zum neuen Rust-basierten Projekt wechseln soll
  • Anschließend fiel die Wahl auf syncstorage-rs
    • Eine moderne, Rust-basierte Version des bisherigen Projekts
    • Es gab kein sofort nutzbares Docker-Image
    • Die Dokumentation enthielt zwar Anweisungen zum Ausführen mit Docker, der Konfigurationsablauf war jedoch komplex
  • In der offiziellen Docker-Dokumentation gab es mehrere Stellen, an denen es nicht weiterging
    • Es wurde empfohlen, die Versionen von grpcio und protobuf an die von google-cloud-rust-raw verwendeten Versionen anzupassen
    • Der Inhalt von mozilla-rust-sdk musste manuell in das oberste Root-Verzeichnis kopiert werden
    • Auch nach Prüfung von Repository, Dockerfile, Makefile und CircleCI-Workflow war der nächste Schritt nicht klar
  • syncstorage-rs-docker bietet eine einfachere Docker-Konfiguration
    • Dort wurde beschrieben, dass nach Problemen mit der ursprünglichen Dokumentation ein Docker-Container für die eigene Infrastruktur erstellt wurde
    • Auf Basis dieser Konfiguration wurde die tatsächliche Servereinrichtung umgesetzt

Mit Docker Compose und Caddy abgeschlossene Deployment-Konfiguration

  • In docker-compose.yaml wurden Dienste für MariaDB und den Firefox-Sync-Server hinzugefügt
    • firefox_mariadb nutzt das Image linuxserver/mariadb:10.6.13
    • Das DB-Daten-Volume ist auf /data/ffsync/dbdata:/config gesetzt
    • firefox_syncserver baut das Dockerfile aus /root/ffsync und exponiert den Port 8000:8000
    • Zu den wichtigsten Umgebungsvariablen gehören SYNC_URL, SYNC_CAPACITY, SYNC_MASTER_SECRET, METRICS_HASH_SECRET, SYNC_SYNCSTORAGE_DATABASE_URL und SYNC_TOKENSERVER_DATABASE_URL
  • Bei DB-Passwörtern sollte man Sonderzeichen wie "/|%" eher vermeiden
    • Während der Einrichtung konnten dadurch Probleme entstehen
  • Um die Build-Zeit während der Tests zu verkürzen, wurde das Argument BUILDKIT_INLINE_CACHE zu Docker Compose hinzugefügt
  • Die DB-Initialisierung erfolgte, indem das Repository geklont und anschließend Dockerfile sowie initdb.sh auf den Server kopiert und teilweise angepasst wurden
    • MariaDB-Container starten: docker-compose up -d firefox_mariadb
    • Initialisierungsskript ausführen: chmod +x initdb.sh ./initdb.sh
    • Gesamten Stack starten: docker-compose up -d
  • Der Caddy-Reverse-Proxy wurde so konfiguriert, dass er auf den neuen Sync-Server zeigt
    • Das Konfigurationsbeispiel verbindet mydomain:443 mit reverse_proxy firefox_syncserver:8000
    • Nach dem Aktualisieren des DNS-Eintrags wurde Caddy neu gestartet, und der Sync-Server funktionierte

Hürden und Zeitaufwand bei der Einrichtung

  • Das größte Problem waren die persistenten MariaDB-Daten; bei Container-Neustarts mussten alte Daten bei Bedarf gelöscht werden
  • Durch wachsende Docker-Images und Zwischendateien wurde der Speicherplatz auf dem Server knapp
  • Bis der richtige Ablauf gefunden war, mussten mehrere Docker-Konfigurationen ausprobiert werden
  • Ein eigener Firefox-Sync-Server ist ohne Erfahrung mit Docker oder DB-Verwaltung nicht schnell erledigt, wurde aber dank Community-Arbeiten wie syncstorage-rs-docker einrichtbar
  • Die gesamte Einrichtung dauerte etwa 2 Stunden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-03-03
Hacker-News-Kommentare

  • Auch diese Konfiguration hängt für einige Begleitdienste wie Authentifizierung, E-Mail und Account-Metadaten weiterhin von der Mozilla-Infrastruktur ab
    https://github.com/dan-r/syncstorage-rs-docker/blob/main/app...
    Trotzdem ist es ein guter Ausgangspunkt, und wenn man eine Account-Migration in Kauf nimmt, kann man diese Teile später ergänzen. Es ist auch möglich, alle Komponenten vollständig selbst zu hosten, aber das ist etwas aufwendiger. Im Vergleich zu meiner letzten Einrichtung scheinen sich Dokumentation und Developer Experience verbessert zu haben
    https://github.com/mozilla/fxa
    https://mozilla.github.io/ecosystem-platform/tutorials/devel...
    https://mozilla-services.readthedocs.io/en/latest/howtos/run...

    • Früher konnte man Firefox iOS offenbar so konfigurieren, dass ein anderer FxA-/Sync-Server verwendet wird, aber wie es aussieht, ist diese Einstellung verschwunden
      Für Firefox for iOS 9.0 oder neuer hieß es: In die Einstellungen gehen, fünfmal auf die Versionsnummer tippen, unter „Advance Account Settings“ die content-server-URL eintragen und „Use Custom Account Service“ aktivieren
      https://mozilla-services.readthedocs.io/en/latest/howtos/run...
    • Irgendwann könnte der gesamte Stack vielleicht in einem einzigen Docker-Container samt Shell-Skript zur Einrichtung landen
    • Ich frage mich, warum E-Mail von Mozillas Infrastruktur abhängt
    • Man kann den Zwischenschritt auch weglassen und einfach direkt Google verwenden

  • Garuda Linux betreibt schon seit ziemlich langer Zeit einen eigenen Firefox-Sync-Server für den FireDragon-Browser
    defaultPref("identity.sync.tokenserver.uri", "https://ffsync.garudalinux.org/token/1.0/sync/1.5";); // --> FIREDRAGON CONFIG
    Allerdings scheint dort der alte Sync-Server zu laufen, nicht die Rust-Version
    [1] https://firedragon.garudalinux.org/
    [2] https://gitlab.com/garuda-linux/infra-nix/-/blob/main/docker...

  • Meine Erfahrungen mit Self-Hosting habe ich ebenfalls hier dokumentiert
    https://kyzer.me.uk/syncserver/
    Es ist möglich, aber wirklich eine langweilige und mühsame Arbeit. Die frühere Version wurde aufgegeben und war in Python 2 geschrieben, also völlig veraltet, war aber deutlich besser
    Man braucht weder Docker noch Python, derzeit aber MySQL. Ein Freiwilliger arbeitet daran, wie in der alten Version standardmäßig SQLite zu unterstützen; die Hauptbeitragenden scheinen jedoch eher damit beschäftigt zu sein, Firma zu spielen und Texte zu schreiben, die das Sammeln von Metriken und die Einführung neuer Metrik-Frameworks rechtfertigen, statt Self-Hosting einfacher zu machen

  • Es lohnt sich auch, https://github.com/canvas-ai/canvas-browser-extensions anzuschauen oder zu verfolgen
    Das ist ein Tool, das Chrome-/Firefox-Browser-Tabs in einen selbst gehosteten virtuellen Verzeichnisbaum synchronisieren soll, der von LMDB und Roaring-Bitmap-Indizes angetrieben wird. Rückblickend hätte ich von Anfang an rxdb oder pouchdb verwenden und nur die Bitmaps beibehalten sollen, aber dorthin wird es am Ende gehen
    Der Ablauf ist, passend zur aktuellen Aufgabe einen neuen Kontextpfad wie universe://travel/2024/03/barcelona anzulegen, je nach Konfiguration die aktuellen Tabs zu speichern und sie dann zu schließen; neue Arbeits-Tabs wie Airbnb-Suchen werden diesem Kontext hinzugefügt. Der Ehepartner kann denselben Kontext öffnen und gemeinsam daran arbeiten, und wenn automatische Synchronisierung aktiviert ist, kann das auch so funktionieren, dass man gegenseitig die Tabs schließt
    Die Serverkomponente wird derzeit neu geschrieben, und genau da zeigt sich mein Amateurismus. Auf einer Basis mit zwei Nutzern kann man sogar den dummen Fehler machen, gleichzeitig die gesamte API, das Backend und die Module neu zu schreiben und dabei bestehende Funktionen unwiederbringlich kaputtzumachen. Mit heutigen Tools wie Cursor und Claude 3.7 ist die größte Grenze für Ideen am Ende die Zeit

  • Ich habe das eine Zeit lang so genutzt und sogar die Authentifizierung selbst gehostet, bin aber letztlich zu dem Schluss gekommen, dass Mozilla eines der sehr wenigen Unternehmen ist, denen ich meine Daten anvertrauen würde. Vielleicht ist dieses Vertrauen fehl am Platz. Der Sync-Server ist relativ einfach einzurichten, der Authentifizierungsserver dagegen deutlich komplexer; verglichen mit einem öffentlich gehosteten Dienst sehe ich darin keinen großen Mehrwert

    • Mozilla hat mit dem „terms of use“-Wirbel fast den letzten Rest an Sympathie verspielt. Immerhin gibt es mit LibreWolf noch einen Fork, der die Privatsphäre respektiert
    • Wenn Mozilla sich selbst als Werbeunternehmen rebrandet und den Großteil der Finanzierung – und vermutlich auch der Ausrichtung – von Google erhält, sollte man dieses Vertrauen zumindest hinterfragen
    • Diese Einschätzung ist sehr schnell veraltet

  • Danke. Das war der einzige Punkt, der mich bisher davon abgehalten hat, zu LibreWolf zu wechseln.
    Derzeit scheinen nur MySQL und Spanner als Datenbank-Engines unterstützt zu werden, aber an Support für SQLite und Postgres wird ebenfalls gearbeitet[1]. Wenn das bald gemergt wird, dürfte es deutlich einfacher werden, den gesamten Sync-Speicher als eine einzige SQLite-Datei zu sichern. Bei einer Multi-User-Instanz wäre es allerdings wohl besser, in Postgres zu speichern, weil dort parallele Updates besser unterstützt werden.
    Nachtrag nach eigenem Ausprobieren: Wie genau kann man Firefox (LibreWolf) dazu zwingen, die selbst gehostete URL zu verwenden? Gibt es dafür eine about:config-Einstellung?
    1: https://github.com/mozilla-services/syncstorage-rs/issues/49...

  • Wenn Firefox Sync Ende-zu-Ende-verschlüsselt ist, frage ich mich, welchen Vorteil das aus Datenschutzsicht bringt.
    https://support.mozilla.org/en-US/kb/sync

    • Soweit ich weiß, werden die Login-Seite und der JavaScript-Code weiterhin über das Internet ausgeliefert, und der Verschlüsselungsschlüssel wird ausschließlich aus dem Passwort abgeleitet. Für etwas so Sensibles wie die gesamten Browserdaten ist das kein gutes Design.

  • Etwas Ähnliches wie Firefox Sync ist Floccus. Wenn man nur Lesezeichen und Tabs synchronisieren möchte, wirkt die Einrichtung recht einfach.
    https://floccus.org/

  • Es wäre gut, klarzustellen, dass LibreWolf und Waterfox den Kurs geändert haben und den Mozilla Sync Server verwenden, und das wie unten optional zu machen:
    Wählen Sie zum Synchronisieren eine der folgenden Optionen:
    [x] Custom Sync Server: ___________
    [ ] Mozilla Sync

    • Bei LibreWolf ist es optional, und wenn jemand ein Kontrollkästchen namens „Firefox Sync“ anklickt und dann denkt, das sei eine andere Synchronisierung als Firefox Sync, dürfte keine UI-Änderung wirklich helfen.
    • Sync ist im Grunde nur ein furchtbar überdesigntes Blob-Storage. Als 1.5 herauskam, habe ich einmal alternative Accounts+Sync-Server implementiert: https://gitlab.com/drdaeman/firesync/
      Das liegt lange brach, und der Code ist nur ein mieser Proof of Concept, aber es bedeutet immerhin, dass ich mir zu dem Thema ein halbwegs fundiertes Urteil erlauben kann.
      Für technische Nutzer wäre es meiner Ansicht nach am besten, wenn Firefox-Forks Sync durch etwas Standardisierteres wie S3 oder WebDAV ersetzen würden. Wenn ich mich richtig erinnere, gibt es in Sync keine Funktion, die diese Protokolle nicht genauso gut oder sogar besser abdecken könnten. Diese sind nämlich tatsächlich einigermaßen interoperable Standards.
      Es wäre schön, wenn Mozilla das ebenfalls täte, aber die Vorliebe für Eigenentwicklungen scheint dort zu stark zu sein, daher erwarte ich das kaum. Ich bin sehr froh, dass aus dieser Neigung Rust entstanden ist, aber Sync ist nahezu Müll, der gar nicht erst hätte gebaut werden sollen.
    • Der Vollständigkeit halber: Firefox Sync funktionierte ziemlich lange genau so.
      https://blog.mozilla.org/services/2011/03/22/get-syncing-wit...
      Eine der ersten Fragen war, ob man einen Custom Sync Server verwenden möchte, und dieser „Custom Sync Server“ konnte auch etwas so Einfaches wie ein WebDAV-Server sein. Wenn man einen öffentlichen HTTP-Server hatte, wurde das fast schon unterstützt oder erforderte nur sehr wenige zusätzliche Abhängigkeiten. Außerdem wurde zusätzlich zum Login-Schlüssel auch nach einem Ende-zu-Ende-Verschlüsselungsschlüssel gefragt.

  • Dass das Self-Hosting gelungen ist, ist erfreulich. Allerdings wirkt die Lösung unnötig komplex. Man sollte keinen Datenbankserver und Docker aufsetzen müssen, nur um eine sehr kleine Datenmenge zu synchronisieren. Ideal wäre SQLite und eine eigenständig ausführbare Sync-Server-Implementierung.

    • Theoretisch könnte man einen einfachen Sync-Server bauen, der nur die nötigen Endpunkte implementiert. Diese Anleitung betreibt den offiziell von Mozilla gepflegten Sync-Server, der natürlich nicht als Minimalimplementierung fürs Homelab gedacht ist, sondern darauf ausgelegt ist, Millionen von Nutzern zu bedienen.
      Jemand könnte https://github.com/mozilla-services/syncstorage-rs forken, den Zusatzballast entfernen und das Ganze ohne zusätzliche Datenbank und ohne Google-Cloud-basierte Architektur neu implementieren. Wie bei vielen Dingen müsste man dafür aber erst genug Leute mit Interesse und freier Zeit finden, um es zu entwickeln.
    • Stimmt, aber allein dass Self-Hosting möglich ist, ist schon etwas wert. Bei vielen Browsern geht nicht einmal das.
    • Es gibt einen offenen Merge Request.
      https://github.com/mozilla-services/syncstorage-rs/issues/49...