Auto-héberger un serveur Firefox Sync

 (blog.diego.dev)
1 points par GN⁺ 2025-03-03 | 1 commentaires | Partager sur WhatsApp
  • Après être passé de Firefox à LibreWolf, l’auteur a voulu exploiter lui-même les données de synchronisation du navigateur et, après avoir examiné plusieurs dépôts et configurations Docker, a fini par créer un serveur fonctionnel
  • L’ancien syncserver de Mozilla est une solution tout-en-un, mais comme il affiche un avertissement de fin de maintenance, syncstorage-rs, basé sur Rust, devient une option plus réaliste
  • La procédure Docker officielle était difficile à suivre en raison de la complexité des étapes liées à grpcio, protobuf et à la copie de mozilla-rust-sdk, et la configuration communautaire syncstorage-rs-docker a servi de base au déploiement réel
  • La configuration finale consiste à lancer MariaDB 10.6.13 et firefox_syncserver avec docker-compose.yaml, Caddy faisant office de reverse proxy vers firefox_syncserver:8000
  • Les principaux obstacles ont été les données persistantes de la base de données, le manque d’espace de stockage et les expérimentations autour de la procédure Docker ; si l’on n’est pas familier avec l’exploitation de Docker ou d’une base de données, la configuration est difficile

Pourquoi passer de syncserver à syncstorage-rs

  • Après être passé de Firefox à LibreWolf, l’auteur a commencé à auto-héberger un serveur Firefox Sync
  • La première solution trouvée, Mozilla syncserver, était un package tout-en-un pour l’auto-hébergement
    • Il inclut à la fois tokenserver pour l’authentification et syncstorage pour le stockage
    • L’historique de build contenait un tag « failed »
    • Le dépôt affiche un avertissement indiquant qu’il n’est plus maintenu et qu’il faut passer au nouveau projet basé sur Rust
  • L’auteur a ensuite choisi syncstorage-rs
    • Il s’agit d’une version moderne, basée sur Rust, du projet existant
    • Aucune image Docker prête à l’emploi n’était disponible
    • La documentation décrivait une méthode d’exécution avec Docker, mais le flux de configuration était complexe
  • Plusieurs points de la documentation Docker officielle ont posé problème
    • Elle indiquait d’aligner les versions de grpcio et protobuf sur celles utilisées par google-cloud-rust-raw
    • Le contenu de mozilla-rust-sdk devait être copié manuellement dans le répertoire racine de plus haut niveau
    • Même après avoir vérifié le dépôt, le Dockerfile, le Makefile et le workflow CircleCI, la suite de la procédure n’était pas claire
  • syncstorage-rs-docker fournit une configuration Docker plus simple
    • Le projet expliquait avoir créé un conteneur Docker pour sa propre infrastructure après avoir rencontré des problèmes avec la documentation d’origine
    • Cette configuration a servi de base à la mise en place du serveur réel

Configuration de déploiement finalisée avec Docker Compose et Caddy

  • Le fichier docker-compose.yaml ajoute des services MariaDB et Firefox Sync Server
    • firefox_mariadb utilise l’image linuxserver/mariadb:10.6.13
    • Le volume de données de la base est configuré avec /data/ffsync/dbdata:/config
    • firefox_syncserver construit le Dockerfile situé dans /root/ffsync et expose le port 8000:8000
    • Les principales variables d’environnement incluent SYNC_URL, SYNC_CAPACITY, SYNC_MASTER_SECRET, METRICS_HASH_SECRET, SYNC_SYNCSTORAGE_DATABASE_URL et SYNC_TOKENSERVER_DATABASE_URL
  • Il vaut mieux éviter les caractères spéciaux comme "/|%" dans le mot de passe de la base de données
    • Ils peuvent provoquer des problèmes lors de la configuration
  • Pour réduire le temps de build pendant les tests, l’argument BUILDKIT_INLINE_CACHE a été ajouté à Docker Compose
  • L’initialisation de la base de données a été effectuée après avoir cloné le dépôt, copié le Dockerfile et initdb.sh sur le serveur, puis modifié certains éléments
    • Lancement du conteneur MariaDB : docker-compose up -d firefox_mariadb
    • Exécution du script d’initialisation : chmod +x initdb.sh ./initdb.sh
    • Lancement de toute la stack : docker-compose up -d
  • Le reverse proxy Caddy a été configuré pour pointer vers le nouveau serveur Sync
    • L’exemple de configuration relie mydomain:443 à reverse_proxy firefox_syncserver:8000
    • Après mise à jour de l’entrée DNS puis redémarrage de Caddy, le serveur Sync fonctionne

Obstacles rencontrés pendant la configuration et temps nécessaire

  • Le principal problème concernait les données persistantes MariaDB ; au redémarrage du conteneur, il fallait supprimer les anciennes données si nécessaire
  • Les images Docker et les fichiers intermédiaires ayant grossi, l’espace de stockage du serveur est devenu insuffisant
  • Il a fallu expérimenter plusieurs fois la configuration Docker avant de trouver la bonne procédure
  • Un serveur Firefox Sync auto-hébergé n’est pas facile à mettre en place si l’on n’est pas habitué à gérer Docker ou des bases de données, mais des travaux communautaires comme syncstorage-rs-docker ont rendu la configuration possible
  • L’ensemble de la configuration a pris environ 2 heures

À lire aussi

1 commentaires

 
GN⁺ 2025-03-03
Avis de Hacker News

  • Même cette configuration dépend encore de quelques services périphériques de l’infrastructure de Mozilla, comme l’authentification, l’e-mail et les métadonnées de compte
    https://github.com/dan-r/syncstorage-rs-docker/blob/main/app...
    Cela reste un bon point de départ, et si vous acceptez une migration de compte, vous pourrez ajouter ces éléments plus tard. Il est aussi possible de self-hoster entièrement tous les composants, mais cela demande un peu plus de travail. Par rapport à la dernière fois où je l’avais configuré, la documentation et l’expérience développeur semblent s’être améliorées
    https://github.com/mozilla/fxa
    https://mozilla.github.io/ecosystem-platform/tutorials/devel...
    https://mozilla-services.readthedocs.io/en/latest/howtos/run...

    • Il me semble qu’avant, Firefox iOS permettait de le configurer pour utiliser un autre serveur FxA/Sync, mais en cherchant, ce réglage semble avoir disparu
      Pour Firefox for iOS 9.0 et versions ultérieures, il était indiqué d’aller dans les réglages, de toucher 5 fois le numéro de version, de saisir l’URL du content-server dans “Advance Account Settings”, puis d’activer “Use Custom Account Service”
      https://mozilla-services.readthedocs.io/en/latest/howtos/run...
    • Un jour, toute la stack pourrait finir dans un seul conteneur Docker avec un script shell de configuration
    • Je me demande pourquoi l’e-mail dépend de l’infrastructure de Mozilla
    • Autant supprimer l’intermédiaire et utiliser directement Google

  • Garuda Linux exploite depuis assez longtemps son propre serveur Firefox Sync pour le navigateur FireDragon
    defaultPref("identity.sync.tokenserver.uri", "https://ffsync.garudalinux.org/token/1.0/sync/1.5";); // --> FIREDRAGON CONFIG
    Il semble toutefois qu’ils fassent tourner l’ancien serveur de synchronisation, pas la version Rust
    [1] https://firedragon.garudalinux.org/
    [2] https://gitlab.com/garuda-linux/infra-nix/-/blob/main/docker...

  • J’ai aussi documenté mon expérience de self-hosting ici
    https://kyzer.me.uk/syncserver/
    C’est possible, mais c’est vraiment une tâche ennuyeuse et pénible. L’ancienne version est abandonnée et écrite en Python 2, donc complètement obsolète, mais elle était bien meilleure
    Pas besoin de Docker ni de Python, mais MySQL est désormais requis. Un bénévole travaille à rétablir la prise en charge de SQLite par défaut, comme dans l’ancienne version, mais les principaux contributeurs semblent davantage occupés à imiter une entreprise et à rédiger des textes justifiant la collecte de métriques et l’introduction d’un nouveau framework de métriques qu’à faciliter le self-hosting

  • Vous pouvez aussi jeter un œil à https://github.com/canvas-ai/canvas-browser-extensions, ou le suivre
    C’est un outil qui vise à synchroniser les onglets des navigateurs Chrome/Firefox dans une arborescence de répertoires virtuelle self-hostée, alimentée par LMDB et des index bitmap Roaring. Avec le recul, j’aurais dû utiliser rxdb ou pouchdb dès le départ et ne conserver que les bitmaps, mais c’est finalement vers cela que je vais
    Le flux consiste à créer un nouveau chemin de contexte comme universe://travel/2024/03/barcelona en fonction de ce sur quoi vous travaillez, puis, selon la configuration, à enregistrer les onglets actuels et les fermer, afin que de nouveaux onglets de travail, comme une recherche Airbnb, soient ajoutés à ce contexte. Votre conjoint peut aussi ouvrir le même contexte pour travailler avec vous, et si la synchronisation automatique est activée, cela peut même fonctionner en fermant les onglets de l’autre
    Le composant serveur est actuellement en cours de réécriture, et c’est là que mon amateurisme se voit. Sur une base de 2 utilisateurs, on peut aussi faire la bêtise de lancer en même temps une réécriture complète de l’API, du backend et des modules, au point de casser irrémédiablement les fonctionnalités existantes. Avec les outils actuels, par exemple Cursor et Claude 3.7, la principale limite aux idées reste finalement le temps

  • Je l’ai utilisé ainsi pendant un moment, en hébergeant même moi-même l’authentification, mais j’en suis finalement venu à penser que Mozilla fait partie des très rares entreprises auxquelles je peux confier mes données. Cette confiance est peut-être mal placée. La configuration du serveur de synchronisation est relativement simple, alors que le serveur d’authentification est beaucoup plus complexe, et je ne pense pas que cela en vaille vraiment la peine par rapport à l’utilisation d’un service d’hébergement public

    • Mozilla a presque entièrement brûlé le peu de sympathie qui lui restait avec le tollé autour des “terms of use”. Il reste tout de même LibreWolf, un fork respectueux de la vie privée
    • Si Mozilla se rebrand en entreprise publicitaire, et reçoit la majeure partie de son financement, et probablement même de son orientation, de Google, cette confiance mérite au minimum d’être remise en question
    • Ce jugement est devenu obsolète très rapidement

  • Merci. C’était le seul point qui m’empêchait de passer à LibreWolf
    Les seuls moteurs de base de données actuellement pris en charge semblent être MySQL et Spanner, mais la prise en charge de SQLite et de Postgres est aussi en cours[1]. Si c’est fusionné rapidement, il devrait être beaucoup plus facile de sauvegarder tout le stockage de synchronisation dans un seul fichier SQLite. Cela dit, pour une instance multi-utilisateur, il vaudrait sans doute mieux stocker ça dans Postgres, qui gère mieux les mises à jour parallèles
    Ajout après avoir essayé moi-même : comment peut-on exactement forcer Firefox (LibreWolf) à utiliser l’URL auto-hébergée ? Y a-t-il un réglage about:config ?
    1 : https://github.com/mozilla-services/syncstorage-rs/issues/49...

    • D’après la documentation (https://github.com/mozilla-services/syncstorage-rs?tab=readm...), il semble suffire de modifier une variable about:config
      Dans Firefox, il est indiqué d’aller dans about:config et de changer identity.sync.tokenserver.uri en http://localhost:5000/1.0/sync/1.5. Bien sûr, il faut adapter l’URL à son propre environnement
    • LibreWolf peut aussi utiliser les serveurs de synchronisation de Mozilla. Il n’est pas nécessaire de l’auto-héberger pour utiliser la synchronisation

  • Si Firefox Sync est chiffré de bout en bout, je me demande quel est l’avantage en matière de confidentialité
    https://support.mozilla.org/en-US/kb/sync

    • À ma connaissance, la page de connexion et le code JavaScript sont toujours servis via Internet, et la clé de chiffrement est uniquement dérivée du mot de passe. Ce n’est pas une bonne conception pour quelque chose d’aussi sensible que l’ensemble des données du navigateur

  • Il existe Floccus, qui ressemble à Firefox Sync. Si vous n’avez besoin que de synchroniser les favoris et les onglets, la configuration semble simple
    https://floccus.org/

  • Ce serait bien de préciser que LibreWolf et Waterfox ont changé de direction et utilisent Mozilla Sync Server, et de rendre cela optionnel comme ci-dessous
    Pour synchroniser, choisissez l’une des options suivantes :
    [x] Custom Sync Server: ___________
    [ ] Mozilla Sync

    • LibreWolf propose déjà ce choix, et si quelqu’un coche une case intitulée « Firefox Sync » en pensant qu’il s’agit d’une autre synchronisation que Firefox Sync, aucun changement d’UI ne pourra vraiment l’aider
    • Sync n’est en réalité qu’un stockage de blobs horriblement surconçu. Quand la version 1.5 est sortie, j’avais implémenté un serveur Accounts+Sync alternatif : https://gitlab.com/drdaeman/firesync/
      Il est abandonné depuis longtemps et le code n’est qu’une preuve de concept médiocre, mais cela signifie tout de même que je peux porter un jugement un minimum étayé sur le sujet
      Pour les utilisateurs techniques, je pense que le mieux serait que les forks de Firefox remplacent Sync par quelque chose de plus standard comme S3 ou WebDAV. Si ma mémoire est bonne, Sync n’offre aucune fonctionnalité que ces protocoles ne pourraient pas gérer aussi bien, voire mieux. Eux, au moins, reposent sur des standards réellement assez interopérables
      J’aimerais que Mozilla fasse pareil, mais leur préférence pour le fait maison semble trop forte pour que ce soit réaliste. Je suis très heureux que cette tendance nous ait donné Rust, mais Sync est presque une cochonnerie qui n’aurait jamais dû être créée
    • Pour mémoire, Firefox Sync a fonctionné exactement de cette manière pendant assez longtemps
      https://blog.mozilla.org/services/2011/03/22/get-syncing-wit...
      L’une des premières questions était de savoir si l’on voulait utiliser un Custom Sync Server, et ce « Custom Sync Server » pouvait être quelque chose d’aussi simple qu’un serveur WebDAV. Si vous aviez un serveur HTTP public, il le prenait presque déjà en charge, ou il suffisait d’ajouter très peu de dépendances. Et il demandait aussi une clé de chiffrement de bout en bout, distincte de la clé de connexion

  • Réussir à l’auto-héberger est une bonne nouvelle. Mais la solution semble plus compliquée que nécessaire. On ne devrait pas avoir besoin de monter un serveur de base de données et Docker pour synchroniser une toute petite quantité de données. Idéalement, il faudrait utiliser SQLite et disposer d’une implémentation de serveur de synchronisation exécutable de façon autonome

    • En théorie, on pourrait créer un serveur de synchronisation simple qui n’implémente que les endpoints nécessaires. Ce type de guide fait tourner le serveur de synchronisation maintenu officiellement par Mozilla, qui est évidemment conçu pour servir des millions d’utilisateurs, pas comme une implémentation minimale pour un homelab
      Quelqu’un pourrait forker https://github.com/mozilla-services/syncstorage-rs, retirer les accessoires et le réimplémenter sans base de données auxiliaire ni architecture basée sur Google Cloud. Mais comme souvent, il faudrait d’abord réunir des personnes ayant assez d’intérêt et de temps libre pour le développer
    • C’est vrai, mais le simple fait que l’auto-hébergement soit possible a déjà de la valeur. Beaucoup de navigateurs ne permettent même pas ça
    • Il existe une demande de fusion ouverte
      https://github.com/mozilla-services/syncstorage-rs/issues/49...