Firefox Sync 서버 셀프 호스팅

 (blog.diego.dev)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 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 비밀번호에는 "/|%" 같은 특수문자를 피하는 편이 좋음
    • 설정 과정에서 문제가 생길 수 있었음
  • 테스트 중 빌드 시간을 줄이기 위해 BUILDKIT_INLINE_CACHE 인자를 Docker Compose에 추가함
  • 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시간이 걸렸음

함께 보면 좋은 글 β

GN⁺   [-]
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 컨테이너 하나로 들어갈 수도 있겠음
    • 이메일이 왜 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가 내 데이터를 맡길 만한 거의 몇 안 되는 회사라고 생각하게 됨. 그 신뢰가 잘못된 것일 수도 있지만. 동기화 서버 설정은 비교적 단순한 반면 인증 서버는 훨씬 복잡해서, 공개 호스팅 서비스를 쓰는 것과 비교하면 그만한 가치가 크지 않다고 봄

    • Mozilla는 “terms of use” 소동으로 남아 있던 호감까지 거의 다 태워버렸음. 그래도 개인정보를 존중하는 포크로 LibreWolf가 남아 있음
    • Mozilla가 스스로를 광고 회사로 리브랜딩하고, 자금 대부분과 아마 방향성까지 Google에서 받는다면 그 신뢰를 적어도 의심해 봐야 함
    • 그 판단은 아주 빠르게 낡아버린 말이 됐음

  • 고마움. 이게 LibreWolf로 옮기는 걸 막고 있던 유일한 부분이었음
    현재 지원되는 데이터베이스 엔진은 MySQL과 Spanner뿐인 듯하지만, SQLite와 Postgres 지원 작업도 진행 중임[1]. 빨리 병합되면 동기화 저장소 전체를 SQLite 파일 하나로 백업하기 훨씬 쉬워질 것 같음. 다만 다중 사용자 인스턴스라면 병렬 업데이트 지원이 더 나은 Postgres에 저장하는 편이 나을 듯함
    직접 해본 뒤 추가: Firefox(LibreWolf)가 셀프호스팅 URL을 쓰도록 정확히 어떻게 강제할 수 있음? about:config 설정이 있나?
    1: https://github.com/mozilla-services/syncstorage-rs/issues/49...

  • 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는 사실 끔찍하게 과설계된 블롭 저장소일 뿐임. 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...
      처음 질문 중 하나가 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...
답변달기