Self-hosting do servidor Firefox Sync

 (blog.diego.dev)
1 pontos por GN⁺ 2025-03-03 | 1 comentários | Compartilhar no WhatsApp
  • Depois de migrar do Firefox para o LibreWolf, surgiu a intenção de operar diretamente os dados de sincronização do navegador; após analisar vários repositórios e configurações de Docker, foi montado um servidor funcional
  • O antigo syncserver da Mozilla é uma configuração tudo-em-um, mas há um aviso de descontinuação de manutenção, então o syncstorage-rs, baseado em Rust, acabou sendo a opção mais realista
  • O procedimento oficial em Docker era difícil de seguir por causa da complexidade de copiar grpcio, protobuf e mozilla-rust-sdk, e a configuração comunitária syncstorage-rs-docker acabou servindo como base para a implantação real
  • A configuração final usa docker-compose.yaml para subir o MariaDB 10.6.13 e o firefox_syncserver, enquanto o Caddy faz proxy reverso para firefox_syncserver:8000
  • Os principais obstáculos foram dados persistentes do banco, falta de espaço de armazenamento e experimentação com o fluxo em Docker; se você não tem familiaridade com Docker ou operação de banco de dados, o nível de dificuldade de configuração é alto

Motivos para migrar de syncserver para syncstorage-rs

  • Depois de trocar o Firefox pelo LibreWolf, começou o trabalho de hospedar por conta própria um servidor Firefox Sync
  • O primeiro projeto encontrado foi o Mozilla syncserver, um pacote tudo-em-um para self-hosting
    • Inclui juntos o tokenserver para autenticação e o syncstorage para armazenamento
    • Havia uma tag “failed” no histórico de builds
    • O repositório exibia um aviso dizendo que ele não é mais mantido e recomendando migrar para um novo projeto baseado em Rust
  • Depois disso, a escolha foi o syncstorage-rs
    • É uma versão moderna baseada em Rust do projeto anterior
    • Não havia uma imagem Docker pronta para uso imediato
    • A documentação mostrava como executar com Docker, mas o fluxo de configuração era complexo
  • Houve vários pontos de bloqueio na documentação oficial de Docker
    • Havia orientação para alinhar as versões de grpcio e protobuf com as usadas por google-cloud-rust-raw
    • Era preciso copiar manualmente o conteúdo de mozilla-rust-sdk para o diretório raiz de nível superior
    • Mesmo verificando o repositório, o Dockerfile, o Makefile e o workflow do CircleCI, o procedimento seguinte não ficava claro
  • O syncstorage-rs-docker oferece uma configuração Docker mais simples
    • A explicação dizia que, após enfrentar problemas com a documentação original, foi criado um contêiner Docker para a própria infraestrutura
    • A configuração real do servidor foi feita com base nessa estrutura

Implantação final com Docker Compose e Caddy

  • No docker-compose.yaml, foram adicionados o MariaDB e o serviço do servidor Firefox Sync
    • firefox_mariadb usa a imagem linuxserver/mariadb:10.6.13
    • O volume de dados do banco foi configurado como /data/ffsync/dbdata:/config
    • firefox_syncserver faz build do Dockerfile em /root/ffsync e expõe a porta 8000:8000
    • As principais variáveis de ambiente incluem SYNC_URL, SYNC_CAPACITY, SYNC_MASTER_SECRET, METRICS_HASH_SECRET, SYNC_SYNCSTORAGE_DATABASE_URL e SYNC_TOKENSERVER_DATABASE_URL
  • É melhor evitar caracteres especiais como "/|%" na senha do banco
    • Eles podem causar problemas durante a configuração
  • Para reduzir o tempo de build durante os testes, foi adicionado o argumento BUILDKIT_INLINE_CACHE ao Docker Compose
  • A inicialização do banco foi feita clonando o repositório, copiando o Dockerfile e o initdb.sh para o servidor e fazendo alguns ajustes
    • Executar o contêiner do MariaDB: docker-compose up -d firefox_mariadb
    • Executar o script de inicialização: chmod +x initdb.sh ./initdb.sh
    • Subir toda a stack: docker-compose up -d
  • O proxy reverso do Caddy foi configurado para apontar para o novo servidor Sync
    • O exemplo de configuração conecta mydomain:443 a reverse_proxy firefox_syncserver:8000
    • Depois de atualizar a entrada DNS, o Caddy foi reiniciado e o servidor Sync passou a funcionar

Problemas encontrados na configuração e tempo gasto

  • O maior problema foram os dados persistentes do MariaDB, e às vezes era necessário apagar dados antigos ao reiniciar o contêiner
  • Com o crescimento das imagens Docker e dos arquivos intermediários, o servidor ficou sem espaço de armazenamento
  • Foi preciso experimentar várias vezes a configuração em Docker até encontrar o procedimento correto
  • Um servidor Firefox Sync próprio não é algo que se resolve facilmente sem familiaridade com Docker ou administração de banco de dados, mas trabalhos da comunidade como o syncstorage-rs-docker tornam a configuração viável
  • A configuração completa levou cerca de 2 horas

Leituras relacionadas

1 comentários

 
GN⁺ 2025-03-03
Opiniões no Hacker News

  • Esta configuração ainda depende da infraestrutura da Mozilla para alguns serviços periféricos, como autenticação, e-mail e metadados de conta
    https://github.com/dan-r/syncstorage-rs-docker/blob/main/app...
    Ainda assim, é um bom ponto de partida e, se você estiver disposto a lidar com a migração de contas, pode adicionar essas partes depois. Também é possível fazer self-hosting completo de todos os componentes, mas dá um pouco mais de trabalho. Em comparação com a última vez que configurei isso, parece que a documentação e a experiência para desenvolvedores melhoraram
    https://github.com/mozilla/fxa
    https://mozilla.github.io/ecosystem-platform/tutorials/devel...
    https://mozilla-services.readthedocs.io/en/latest/howtos/run...

    • Antigamente, acho que era possível configurar o Firefox para iOS para usar outro servidor FxA/Sync, mas, pelo que encontrei, essa configuração parece ter desaparecido
      No Firefox for iOS 9.0 ou superior, as instruções diziam para ir às configurações, tocar 5 vezes no número da versão, inserir a URL do content-server em “Advance Account Settings” e ativar “Use Custom Account Service”
      https://mozilla-services.readthedocs.io/en/latest/howtos/run...
    • Um dia, talvez a stack inteira possa caber em um único contêiner Docker com um script shell de configuração
    • Fico curioso para saber por que o e-mail depende da infraestrutura da Mozilla
    • Melhor eliminar o intermediário e usar o Google diretamente

  • O Garuda Linux mantém seu próprio servidor Firefox Sync para o navegador FireDragon há bastante tempo
    defaultPref("identity.sync.tokenserver.uri", "https://ffsync.garudalinux.org/token/1.0/sync/1.5";); // --> FIREDRAGON CONFIG
    Mas parece que eles rodam o servidor de sincronização antigo, não a versão em Rust
    [1] https://firedragon.garudalinux.org/
    [2] https://gitlab.com/garuda-linux/infra-nix/-/blob/main/docker...

  • Também deixei registrado aqui minha experiência com self-hosting
    https://kyzer.me.uk/syncserver/
    É possível, mas é um trabalho realmente tedioso e pesado. A versão anterior foi abandonada e, escrita em Python 2, estava completamente obsoleta, mas era muito melhor
    Não precisa de Docker nem de Python, mas atualmente exige MySQL. Um voluntário está trabalhando para oferecer suporte padrão a SQLite, como na versão antiga, mas os principais contribuidores parecem mais interessados em imitar uma empresa, coletar métricas e escrever textos justificando a adoção de novos frameworks de métricas do que em facilitar o self-hosting

  • Vale a pena também dar uma olhada ou acompanhar https://github.com/canvas-ai/canvas-browser-extensions
    É uma ferramenta que tenta sincronizar abas dos navegadores Chrome/Firefox para uma árvore de diretórios virtual self-hosted, baseada em LMDB e índices de bitmap Roaring. Em retrospectiva, eu deveria ter usado rxdb ou pouchdb desde o início e apenas mantido os bitmaps, mas é para onde vou acabar indo
    A ideia é criar um novo caminho de contexto como universe://travel/2024/03/barcelona conforme o trabalho em andamento; dependendo da configuração, ao salvar e fechar as abas atuais, novas abas de tarefas, como buscas no Airbnb, são adicionadas a esse contexto. Seu cônjuge também pode abrir o mesmo contexto e colaborar; se a sincronização automática estiver ativada, pode até funcionar fechando as abas um do outro
    O componente do servidor está sendo reescrito no momento, e é aí que meu amadorismo aparece. Numa base de 2 usuários, dá para fazer a besteira de começar ao mesmo tempo uma reescrita completa da API, do backend e dos módulos, quebrando as funcionalidades existentes de forma irrecuperável. Com as ferramentas atuais, como Cursor e Claude 3.7, a maior limitação para as ideias acaba sendo o tempo

  • Usei isso por um tempo hospedando até a autenticação por conta própria, mas acabei concluindo que a Mozilla é uma das poucas empresas às quais eu confiaria meus dados. Talvez essa confiança esteja errada. A configuração do servidor de sincronização é relativamente simples, enquanto o servidor de autenticação é muito mais complexo; comparado a usar um serviço hospedado publicamente, não acho que valha tanto a pena

    • A Mozilla queimou quase toda a boa vontade que ainda restava com a confusão dos “terms of use”. Ainda assim, resta o LibreWolf como um fork que respeita a privacidade
    • Se a Mozilla se reposiciona como uma empresa de publicidade e recebe a maior parte do financiamento — e provavelmente até da direção — do Google, no mínimo essa confiança deveria ser questionada
    • Essa avaliação envelheceu muito rapidamente

  • Obrigado. Essa era a única coisa que estava me impedindo de migrar para o LibreWolf
    Por enquanto, parece que os únicos mecanismos de banco de dados compatíveis são MySQL e Spanner, mas o suporte a SQLite e Postgres também está em andamento[1]. Se isso for mesclado logo, acho que vai ficar muito mais fácil fazer backup de todo o armazenamento de sincronização em um único arquivo SQLite. Dito isso, se for uma instância multiusuário, talvez seja melhor armazenar no Postgres, que tem melhor suporte a atualizações paralelas
    Adição depois de testar: como exatamente posso forçar o Firefox (LibreWolf) a usar a URL auto-hospedada? Existe alguma configuração em about:config?
    1: https://github.com/mozilla-services/syncstorage-rs/issues/49...

  • Se o Firefox Sync tem criptografia de ponta a ponta, fico curioso sobre qual é o benefício em termos de privacidade
    https://support.mozilla.org/en-US/kb/sync

    • Até onde sei, a página de login e o código JavaScript ainda são servidos pela internet, e a chave de criptografia é derivada apenas da senha. Não é um bom desenho para algo sensível como todos os dados do navegador

  • Algo parecido com o Firefox Sync é o Floccus. Se você só precisa sincronizar favoritos e abas, a configuração parece simples
    https://floccus.org/

  • Seria bom deixar claro que LibreWolf e Waterfox mudaram o fluxo e estão usando o Mozilla Sync Server, e tornar isso opcional, como abaixo
    Para sincronizar, escolha uma das opções abaixo:
    [x] Custom Sync Server: ___________
    [ ] Mozilla Sync

    • No LibreWolf isso é opcional, e se alguém marca a caixa “Firefox Sync” e acha que aquilo é outra sincronização que não o Firefox Sync, é difícil qualquer mudança de UI ajudar
    • O Sync, na verdade, é só um armazenamento de blobs terrivelmente superprojetado. Quando a versão 1.5 saiu, implementei servidores alternativos de Accounts+Sync: https://gitlab.com/drdaeman/firesync/
      Está abandonado há muito tempo e o código é apenas uma prova de conceito horrível, mas ainda assim isso significa que posso fazer um julgamento um pouco embasado sobre o assunto
      Para usuários técnicos, acho que o melhor seria os forks do Firefox trocarem o Sync por algo mais padrão, como S3 ou WebDAV. Se minha memória não falha, não há nada no Sync que esses protocolos não consigam lidar da mesma forma, ou até melhor. Isso porque eles são padrões realmente interoperáveis até certo ponto
      Eu gostaria que a Mozilla fizesse isso também, mas parece haver uma preferência forte demais por desenvolver tudo internamente, então é difícil ter esperança. Fico muito feliz que essa tendência tenha dado origem ao Rust, mas o Sync é quase um lixo que nunca deveria ter sido criado
    • Para registro, por bastante tempo o Firefox Sync foi exatamente assim
      https://blog.mozilla.org/services/2011/03/22/get-syncing-wit...
      Uma das primeiras perguntas era se você queria usar um Custom Sync Server, e esse “Custom Sync Server” podia ser algo tão simples quanto um servidor WebDAV. Se você tivesse um servidor HTTP público, quase certamente ele já tinha suporte ou só exigia adicionar pouquíssimas dependências. E ele também perguntava por uma chave de criptografia de ponta a ponta separada da chave de login

  • Parabéns por conseguir auto-hospedar. Dito isso, a solução parece mais complexa do que o necessário. Não deveria ser preciso subir um servidor de banco de dados e Docker para sincronizar uma quantidade muito pequena de dados. Idealmente, seria bom usar SQLite e ter uma implementação de servidor de sincronização que rodasse como um executável independente

    • Em teoria, dá para criar um servidor de sincronização simples que implemente apenas os endpoints necessários. Esse guia roda o servidor de sincronização mantido oficialmente pela Mozilla, que obviamente foi feito para atender milhões de usuários, não como uma implementação mínima para um homelab
      Alguém poderia fazer um fork de https://github.com/mozilla-services/syncstorage-rs, remover os acessórios e reimplementá-lo sem o banco de dados auxiliar e sem a arquitetura baseada no Google Cloud. Mas, como em muitas coisas, primeiro seria preciso reunir pessoas com interesse e tempo livre suficientes para desenvolver isso
    • Sim, mas ainda assim o simples fato de ser possível auto-hospedar já tem valor. Muitos navegadores nem isso permitem
    • Há uma solicitação de merge aberta
      https://github.com/mozilla-services/syncstorage-rs/issues/49...