Firefox Syncサーバーのセルフホスティング

 (blog.diego.dev)
1 ポイント 投稿者 GN⁺ 2025-03-03 | 1件のコメント | WhatsAppで共有
  • FirefoxからLibreWolfへ移行した後、ブラウザー同期データを自分で運用しようとし、複数のリポジトリとDocker構成を検討した末に動作するサーバーを構築した
  • Mozillaの従来のsyncserverはオールインワン構成だが、メンテナンス終了の警告があり、Rustベースのsyncstorage-rsのほうが現実的な選択肢になった
  • 公式Docker手順はgrpcio、protobuf、mozilla-rust-sdkのコピー手順が複雑で追いにくく、コミュニティのsyncstorage-rs-docker構成が実際のデプロイ基盤になった
  • 最終構成はdocker-compose.yamlでMariaDB 10.6.13とfirefox_syncserverを起動し、Caddyがfirefox_syncserver:8000へリバースプロキシする方式
  • DBの永続データ、ストレージ不足、Docker手順の試行錯誤が主な障害で、DockerやDB運用に慣れていない場合は設定難度が高い

syncserverからsyncstorage-rsへ移行した理由

  • FirefoxからLibreWolfへ移行した後、Firefox Syncサーバーを自分でセルフホスティングする作業を始めた
  • 最初に見つけたMozilla syncserverは、セルフホスティング向けのオールインワンパッケージだった
    • 認証用のtokenserverとストレージ用のsyncstorageを一緒に含んでいる
    • ビルド履歴に「failed」タグがあった
    • リポジトリには、すでにメンテナンスされておらず、Rustベースの新プロジェクトへ移行するよう警告が表示されていた
  • その後、syncstorage-rsを選択した
    • 既存プロジェクトのモダンなRustベース版
    • すぐに使えるDockerイメージはなかった
    • ドキュメントにはDockerでの実行方法があったが、設定の流れが複雑だった
  • 公式Dockerドキュメントでつまずいた点が複数あった
    • grpcioとprotobufのバージョンを、google-cloud-rust-rawが使うバージョンに合わせるよう案内されていた
    • mozilla-rust-sdkの内容を最上位のルートディレクトリへ手動でコピーする必要があった
    • リポジトリ、Dockerfile、Makefile、CircleCIワークフローを確認しても、次の手順が明確ではなかった
  • syncstorage-rs-dockerは、よりシンプルなDocker構成を提供している
    • 元のドキュメントで問題に遭遇した後、自身のインフラ向けにDockerコンテナを作ったという説明があった
    • この構成をベースに実際のサーバー設定を進めた

Docker ComposeとCaddyで完成させたデプロイ構成

  • docker-compose.yamlにはMariaDBとFirefox Syncサーバーサービスを追加した
    • firefox_mariadbはlinuxserver/mariadb:10.6.13イメージを使用
    • DBデータボリュームは/data/ffsync/dbdata:/configに設定
    • firefox_syncserverは/root/ffsyncのDockerfileをビルドし、8000:8000ポートを公開する
    • 主な環境変数にはSYNC_URL、SYNC_CAPACITY、SYNC_MASTER_SECRET、METRICS_HASH_SECRET、SYNC_SYNCSTORAGE_DATABASE_URL、SYNC_TOKENSERVER_DATABASE_URLが含まれる
  • DBパスワードでは"/|%"のような特殊文字を避けたほうがよい
    • 設定過程で問題が起きる可能性があった
  • テスト中のビルド時間を短縮するため、Docker ComposeにBUILDKIT_INLINE_CACHE引数を追加した
  • DB初期化は、リポジトリをクローンした後、Dockerfileとinitdb.shをサーバーへコピーし、一部修正して進めた
    • MariaDBコンテナの実行: docker-compose up -d firefox_mariadb
    • 初期化スクリプトの実行: chmod +x initdb.sh ./initdb.sh
    • スタック全体の実行: docker-compose up -d
  • Caddyのリバースプロキシは、新しいSyncサーバーを指すよう設定した
    • 設定例ではmydomain:443からreverse_proxy firefox_syncserver:8000へ接続する
    • DNSエントリーを更新した後、Caddyを再起動し、Syncサーバーが動作した

設定中に遭遇した障害と所要時間

  • 最大の問題はMariaDBの永続データで、コンテナ再起動時に必要であれば古いデータを削除する必要があった
  • Dockerイメージと中間ファイルが大きくなり、サーバーのストレージが不足した
  • 正しい手順を見つけるまで、Docker設定を何度も試す必要があった
  • 自前のFirefox Syncサーバーは、DockerやDB管理に慣れていないと簡単には終わらないが、syncstorage-rs-dockerのようなコミュニティの成果のおかげで設定できた
  • 設定全体には約2時間かかった

関連記事

1件のコメント

 
GN⁺ 2025-03-03
Hacker News の意見

  • この構成でも、認証、メール、アカウントのメタデータといった周辺サービスの一部は依然として Mozilla のインフラに依存しています。
    https://github.com/dan-r/syncstorage-rs-docker/blob/main/app...
    それでもよい出発点ですし、アカウント移行を受け入れられるなら、あとからそれらの部分を追加できます。すべての構成要素を完全にセルフホストすることも可能ですが、もう少し手間がかかります。以前最後に設定したときと比べると、ドキュメントと開発者体験は改善されているようです。
    https://github.com/mozilla/fxa
    https://mozilla.github.io/ecosystem-platform/tutorials/devel...
    https://mozilla-services.readthedocs.io/en/latest/howtos/run...

    • 以前は Firefox iOS で別の FxA/Sync サーバーを使うよう設定できた気がしますが、探してみるとその設定はなくなったようです。
      Firefox for iOS 9.0 以降では、設定に移動してバージョン番号を5回タップし、「Advance Account Settings」で content-server URL を入力してから「Use Custom Account Service」を有効にする、とされていました。
      https://mozilla-services.readthedocs.io/en/latest/howtos/run...
    • いつかはスタック全体が、設定用シェルスクリプト付きで Docker コンテナ1つに収まるかもしれません。
    • メールがなぜ Mozilla のインフラに依存するのか気になります。
    • 中間段階をなくして、ただ Google を直接使えばよいのでは。

  • Garuda Linux は FireDragon ブラウザ向けに独自の Firefox Sync サーバーをかなり以前から運用してきました。
    defaultPref("identity.sync.tokenserver.uri", "https://ffsync.garudalinux.org/token/1.0/sync/1.5";); // --> FIREDRAGON CONFIG
    ただし Rust 版ではなく、旧同期サーバーを動かしているようです。
    [1] https://firedragon.garudalinux.org/
    [2] https://gitlab.com/garuda-linux/infra-nix/-/blob/main/docker...

  • 私のセルフホスティング体験もここにまとめてあります。
    https://kyzer.me.uk/syncserver/
    可能ではありますが、本当に退屈で骨の折れる作業です。以前のバージョンは放棄され、Python 2 で書かれていて完全に時代遅れですが、はるかに良いものでした。
    Docker も Python も不要ですが、現状では MySQL が必要です。以前のバージョンのようにデフォルトで SQLite をサポートするよう、あるボランティアが作業していますが、主要なコントリビューターたちはセルフホスティングを簡単にするよりも、会社ごっこをしながら指標収集や新しい指標フレームワークの導入を正当化する文章を書くほうに近いように見えます。

  • https://github.com/canvas-ai/canvas-browser-extensions も見てみるか、フォローするとよいでしょう。
    Chrome/Firefox のブラウザタブを、LMDB と Roaring ビットマップインデックスで駆動するセルフホスト型の仮想ディレクトリツリーに同期しようとするツールです。振り返ると、最初から rxdb か pouchdb を使い、ビットマップだけを維持すべきでしたが、最終的にはその方向に進む予定です。
    取り組んでいる作業に合わせて universe://travel/2024/03/barcelona のような新しいコンテキストパスを作り、設定に応じて現在のタブを保存して閉じると、Airbnb 検索のような新しい作業タブがそのコンテキストに追加される、という流れです。配偶者も同じコンテキストを開いて一緒に作業でき、自動同期が有効なら互いのタブを閉じるような動きもできます。
    サーバー構成要素は現在書き直し中で、私の素人っぽさが露呈している部分です。ユーザー2人規模の基盤では、API 全体、バックエンド、モジュールの書き直しを同時に始めて、既存機能を復旧不能に壊すような愚かなことも可能です。最近のツール、たとえば Cursor と Claude 3.7 があれば、アイデアに対する最大の制約は結局のところ時間です。

  • 認証まで自前でホストしながらしばらくそうして使ってみましたが、結局 Mozilla は自分のデータを預けるに値する、ほぼ数少ない会社の1つだと思うようになりました。その信頼が間違っている可能性もありますが。同期サーバーの設定は比較的単純な一方で、認証サーバーははるかに複雑なので、公開ホスティングサービスを使う場合と比べると、それだけの価値は大きくないと思います。

    • Mozilla は「terms of use」騒動で、残っていた好感までほとんど燃やし尽くしました。それでもプライバシーを尊重するフォークとして LibreWolf が残っています。
    • Mozilla が自らを広告会社としてリブランディングし、資金の大半と、おそらく方向性まで Google から受けているなら、その信頼は少なくとも疑ってみるべきです。
    • その判断は、あっという間に時代遅れの発言になりました。

  • ありがとう。これがLibreWolfへ移行するのを妨げていた唯一の部分だった
    現在サポートされているデータベースエンジンはMySQLとSpannerだけのようだが、SQLiteとPostgres対応の作業も進行中[1]。早くマージされれば、同期ストレージ全体を1つのSQLiteファイルとしてバックアップするのがずっと簡単になりそう。ただしマルチユーザーのインスタンスなら、並列更新のサポートがより優れているPostgresに保存するほうがよさそう
    実際に試した後の追記: Firefox（LibreWolf）にセルフホストURLを使わせるには、正確にはどう強制できる？ about:configの設定がある？
    1: https://github.com/mozilla-services/syncstorage-rs/issues/49...

    • ドキュメント（https://github.com/mozilla-services/syncstorage-rs?tab=readm...）を見ると、about:configの変数を変えるだけで十分そう
      Firefoxでabout:configへ行き、identity.sync.tokenserver.uriをhttp://localhost:5000/1.0/sync/1.5に変更すればよい、と書かれている。もちろんURLは自分の環境に合わせて変える必要がある
    • LibreWolfでもMozillaの同期サーバーを使える。同期を使うために必ずセルフホストする必要はない

  • Firefox Syncがエンドツーエンド暗号化されているなら、プライバシー保護の面でどんな利点があるのか気になる
    https://support.mozilla.org/en-US/kb/sync

    • 私の理解では、ログインページとJavaScriptコードは依然としてインターネット経由で提供され、暗号化キーはパスワードだけから導出される。ブラウザデータ全体のような機微なものには良い設計ではない

  • Firefox Syncに似たものとしてFloccusがある。ブックマークとタブの同期だけが必要なら、設定は簡単そう
    https://floccus.org/

  • LibreWolfとWaterfoxが方針を変えてMozilla Sync Serverを使っている点を明確にし、以下のように選択式にするとよさそう
    同期するには以下のオプションのいずれかを選択してください:
    [x] Custom Sync Server: ___________
    [ ] Mozilla Sync

    • LibreWolfは選択式だし、「Firefox Sync」というチェックボックスを押しておいて、それがFirefox Syncではない別の同期だと思うなら、どんなUI変更でも助けるのは難しい
    • Syncは実のところ、ひどく過剰設計されたBlobストレージにすぎない。1.5が出たとき、代替のAccounts+Syncサーバーを実装したことがある: https://gitlab.com/drdaeman/firesync/
      長らく放置されていて、コードはひどい概念実証にすぎないが、それでもこの話題について多少は根拠のある判断ができるということではある
      技術系ユーザー向けには、FirefoxのフォークがSyncの代わりにS3やWebDAVのような、より標準的なものへ切り替えるのが最善だと思う。記憶が正しければ、Syncにはそれらのプロトコルが同じように、あるいはそれ以上にうまく扱えない機能は何もない。そちらは実際、ある程度相互運用可能な標準だからだ
      Mozillaにもそうしてほしいが、独自開発志向が強すぎるようなので期待しにくい。その傾向のおかげでRustが生まれたのはとても喜ばしいが、Syncはそもそも作るべきではなかった、ゴミに近いものだ
    • 記録のために言うと、Firefox Syncはかなり長い間、まさにその方式だった
      https://blog.mozilla.org/services/2011/03/22/get-syncing-wit...
      最初の質問の1つがCustom Sync Serverを使うかどうかで、この「Custom Sync Server」はWebDAVサーバーのような単純なものでも可能だった。公開HTTPサーバーがあれば、ほぼすでに対応しているか、ごく少ない依存関係を追加するだけで済んだ。そしてログインキーとは別にエンドツーエンド暗号化キーも尋ねられた

  • セルフホストに成功したのは祝うべきことだ。ただ、解決策は必要以上に複雑に見える。ごく少量のデータを同期するために、データベースサーバーやDockerまで立てる必要はないはず。理想的にはSQLiteを使い、単体実行可能な同期サーバー実装があるとよい

    • 理論上は、必要なエンドポイントだけを実装するシンプルな同期サーバーを作れる。この手のガイドは公式のMozilla保守の同期サーバーを動かすものだが、これは当然ホームラボ向けの最小実装ではなく、数百万ユーザーにサービスする基準で作られている
      誰かがhttps://github.com/mozilla-services/syncstorage-rsをフォークして付属物を取り除き、補助データベースやGoogle Cloudベースのアーキテクチャなしで再実装することもできるだろう。ただし多くのことと同じく、まず十分な関心と余裕時間のある人たちを集めて開発する必要がある
    • その通りだが、それでもセルフホストできるというだけで意味がある。多くのブラウザはそれすらできない
    • オープンなマージリクエストがある
      https://github.com/mozilla-services/syncstorage-rs/issues/49...