Self-hosting de un servidor Firefox Sync

 (blog.diego.dev)
1 puntos por GN⁺ 2025-03-03 | 1 comentarios | Compartir por WhatsApp
  • Después de pasar de Firefox a LibreWolf, quise operar por mi cuenta los datos de sincronización del navegador y, tras revisar varios repositorios y configuraciones de Docker, logré crear un servidor funcional
  • El syncserver existente de Mozilla es una configuración todo en uno, pero como tiene una advertencia de mantenimiento discontinuado, syncstorage-rs, basado en Rust, se volvió una opción más realista
  • El procedimiento oficial con Docker era difícil de seguir por la complejidad del proceso de copiar grpcio, protobuf y mozilla-rust-sdk, y la configuración comunitaria syncstorage-rs-docker terminó siendo la base del despliegue real
  • La configuración final levanta MariaDB 10.6.13 y firefox_syncserver con docker-compose.yaml, mientras Caddy actúa como reverse proxy hacia firefox_syncserver:8000
  • Los principales obstáculos fueron los datos persistentes de la DB, la falta de espacio de almacenamiento y la experimentación con el procedimiento de Docker; si no estás familiarizado con operar Docker o DB, la configuración tiene una dificultad alta

Por qué pasé de syncserver a syncstorage-rs

  • Después de cambiar de Firefox a LibreWolf, empecé a self-hostear un servidor de Firefox Sync
  • Lo primero que encontré fue Mozilla syncserver, un paquete todo en uno para self-hosting
    • Incluye tanto tokenserver para autenticación como syncstorage para almacenamiento
    • En el historial de builds aparecía una etiqueta de “failed”
    • El repositorio muestra una advertencia de que ya no recibe mantenimiento y recomienda migrar al nuevo proyecto basado en Rust
  • Luego elegí syncstorage-rs
    • Es la versión moderna basada en Rust del proyecto anterior
    • No había una imagen de Docker lista para usar
    • La documentación incluía cómo ejecutarlo con Docker, pero el flujo de configuración era complejo
  • Hubo varios puntos donde me trabé con la documentación oficial de Docker
    • Indicaba que había que alinear las versiones de grpcio y protobuf con las que usa google-cloud-rust-raw
    • Había que copiar manualmente el contenido de mozilla-rust-sdk al directorio raíz de nivel superior
    • Incluso revisando el repositorio, el Dockerfile, el Makefile y el workflow de CircleCI, el siguiente paso no quedaba claro
  • syncstorage-rs-docker ofrece una configuración de Docker más simple
    • Explicaba que, tras tener problemas con la documentación original, su autor creó un contenedor Docker para su propia infraestructura
    • Usé esa configuración como base para preparar el servidor real

Configuración de despliegue completada con Docker Compose y Caddy

  • En docker-compose.yaml agregué los servicios de MariaDB y del servidor Firefox Sync
    • firefox_mariadb usa la imagen linuxserver/mariadb:10.6.13
    • El volumen de datos de la DB se configuró como /data/ffsync/dbdata:/config
    • firefox_syncserver compila el Dockerfile ubicado en /root/ffsync y expone el puerto 8000:8000
    • Entre las principales variables de entorno se incluyen SYNC_URL, SYNC_CAPACITY, SYNC_MASTER_SECRET, METRICS_HASH_SECRET, SYNC_SYNCSTORAGE_DATABASE_URL y SYNC_TOKENSERVER_DATABASE_URL
  • Conviene evitar caracteres especiales como "/|%" en la contraseña de la DB
    • Podían causar problemas durante la configuración
  • Para reducir el tiempo de build durante las pruebas, agregué el argumento BUILDKIT_INLINE_CACHE a Docker Compose
  • La inicialización de la DB se hizo clonando el repositorio, copiando el Dockerfile y initdb.sh al servidor, y aplicando algunas modificaciones
    • Ejecutar el contenedor de MariaDB: docker-compose up -d firefox_mariadb
    • Ejecutar el script de inicialización: chmod +x initdb.sh ./initdb.sh
    • Ejecutar todo el stack: docker-compose up -d
  • El reverse proxy de Caddy se configuró para apuntar al nuevo servidor Sync
    • El ejemplo de configuración conecta mydomain:443 con reverse_proxy firefox_syncserver:8000
    • Después de actualizar la entrada DNS y reiniciar Caddy, el servidor Sync empezó a funcionar

Obstáculos encontrados y tiempo requerido durante la configuración

  • El mayor problema fueron los datos persistentes de MariaDB, y al reiniciar el contenedor, si era necesario había que borrar datos antiguos
  • A medida que crecían la imagen de Docker y los archivos intermedios, el servidor se quedó sin espacio de almacenamiento
  • Hubo que experimentar varias veces con la configuración de Docker hasta encontrar el procedimiento correcto
  • Un servidor Firefox Sync propio no se configura fácilmente si no tienes experiencia administrando Docker o DB, pero fue posible gracias a trabajos de la comunidad como syncstorage-rs-docker
  • Toda la configuración tomó alrededor de 2 horas

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-03-03
Opiniones de Hacker News

  • Esta configuración todavía depende de la infraestructura de Mozilla para algunos servicios periféricos como autenticación, correo electrónico y metadatos de cuentas
    https://github.com/dan-r/syncstorage-rs-docker/blob/main/app...
    Aun así, es un buen punto de partida, y si puedes asumir una migración de cuentas, más adelante se le pueden agregar esas partes. También es posible hacer self-hosting completo de todos los componentes, pero requiere un poco más de trabajo. Comparado con la última vez que lo configuré hace tiempo, parece que la documentación y la experiencia para desarrolladores mejoraron
    https://github.com/mozilla/fxa
    https://mozilla.github.io/ecosystem-platform/tutorials/devel...
    https://mozilla-services.readthedocs.io/en/latest/howtos/run...

    • Antes creo que en Firefox iOS se podía configurar el uso de otro servidor FxA/Sync, pero al buscarlo parece que esa opción desapareció
      Para Firefox for iOS 9.0 o superior, decía que había que ir a Configuración, tocar 5 veces el número de versión, ingresar la URL del content-server en “Advance Account Settings” y activar “Use Custom Account Service”
      https://mozilla-services.readthedocs.io/en/latest/howtos/run...
    • Algún día quizá toda la pila pueda meterse en un solo contenedor Docker junto con un shell script de configuración
    • Me pregunto por qué el correo electrónico depende de la infraestructura de Mozilla
    • Se puede eliminar el intermediario y usar Google directamente

  • Garuda Linux lleva bastante tiempo operando su propio servidor Firefox Sync para el navegador FireDragon
    defaultPref("identity.sync.tokenserver.uri", "https://ffsync.garudalinux.org/token/1.0/sync/1.5";); // --> FIREDRAGON CONFIG
    Aunque parece que ejecutan el servidor de sincronización antiguo, no la versión en Rust
    [1] https://firedragon.garudalinux.org/
    [2] https://gitlab.com/garuda-linux/infra-nix/-/blob/main/docker...

  • También dejé documentada aquí mi experiencia haciendo self-hosting
    https://kyzer.me.uk/syncserver/
    Es posible, pero es un trabajo realmente tedioso y pesado. La versión anterior fue abandonada y estaba escrita en Python 2, por lo que quedó totalmente obsoleta, pero era mucho mejor
    No se necesita Docker ni Python, pero actualmente sí se necesita MySQL. Hay una persona voluntaria trabajando para que vuelva a soportar SQLite por defecto como la versión anterior, pero los principales contribuidores parecen más dedicados a imitar a una empresa y escribir textos que justifican la recolección de métricas y la adopción de un nuevo framework de métricas que a facilitar el self-hosting

  • También conviene mirar o seguir https://github.com/canvas-ai/canvas-browser-extensions
    Es una herramienta que intenta sincronizar pestañas de Chrome/Firefox con un árbol de directorios virtual self-hosted, impulsado por LMDB e índices de bitmaps Roaring. En retrospectiva, debí haber usado rxdb o pouchdb desde el inicio y mantener solo los bitmaps, pero al final iremos en esa dirección
    La idea es crear una nueva ruta de contexto como universe://travel/2024/03/barcelona según lo que estés haciendo y, de acuerdo con la configuración, guardar y cerrar las pestañas actuales para luego agregar al contexto nuevas pestañas de trabajo, como búsquedas en Airbnb. Tu pareja también puede abrir el mismo contexto y trabajar contigo, y si la sincronización automática está activada, incluso podría funcionar cerrando las pestañas del otro
    El componente del servidor se está reescribiendo actualmente, y ahí se nota mi amateurismo. Con una base de 2 usuarios, uno puede cometer la tontería de empezar a reescribir toda la API, el backend y los módulos al mismo tiempo, rompiendo de forma irrecuperable la funcionalidad existente. Con herramientas actuales como Cursor y Claude 3.7, la mayor limitación para una idea termina siendo el tiempo

  • Lo usé así durante un tiempo, incluso hosteando yo mismo la autenticación, pero al final llegué a pensar que Mozilla es una de las poquísimas empresas a las que podría confiar mis datos. Aunque puede que esa confianza esté equivocada. Configurar el servidor de sincronización es relativamente simple, mientras que el servidor de autenticación es mucho más complejo, así que no creo que valga tanto la pena comparado con usar un servicio público alojado

    • Mozilla quemó casi toda la buena voluntad que le quedaba con el escándalo de los “terms of use”. Aun así, queda LibreWolf como un fork que respeta la privacidad
    • Si Mozilla se rebautiza a sí misma como una empresa de publicidad y recibe la mayor parte de su financiamiento, y probablemente hasta su rumbo, de Google, entonces como mínimo habría que poner esa confianza en duda
    • Esa opinión quedó obsoleta muy rápido

  • Gracias. Esto era lo único que me estaba impidiendo pasarme a LibreWolf.
    Por ahora parece que los únicos motores de base de datos soportados son MySQL y Spanner, pero también está en curso el trabajo para soportar SQLite y Postgres[1]. Si lo fusionan pronto, creo que será mucho más fácil respaldar todo el almacenamiento de sincronización en un solo archivo SQLite. Aunque, si es una instancia multiusuario, probablemente convenga más guardarlo en Postgres, que soporta mejor las actualizaciones en paralelo.
    Agrego después de probarlo: ¿cómo se puede forzar exactamente a Firefox (LibreWolf) a usar una URL autoalojada? ¿Hay alguna configuración en about:config?
    1: https://github.com/mozilla-services/syncstorage-rs/issues/49...

  • Me pregunto cuál es el beneficio para la privacidad si Firefox Sync tiene cifrado de extremo a extremo.
    https://support.mozilla.org/en-US/kb/sync

    • Hasta donde sé, la página de inicio de sesión y el código JavaScript se siguen entregando por Internet, y la clave de cifrado se deriva únicamente de la contraseña. No es un buen diseño para algo tan sensible como todos los datos del navegador.

  • Algo parecido a Firefox Sync es Floccus. Si solo necesitas sincronizar marcadores y pestañas, parece fácil de configurar.
    https://floccus.org/

  • Sería bueno dejar claro que LibreWolf y Waterfox cambiaron de rumbo y están usando Mozilla Sync Server, y hacerlo opcional, algo así:
    Para sincronizar, elige una de las siguientes opciones:
    [x] Custom Sync Server: ___________
    [ ] Mozilla Sync

    • En LibreWolf es opcional, y si alguien marca una casilla que dice “Firefox Sync” y cree que se trata de otra sincronización distinta de Firefox Sync, es difícil que algún cambio de UI ayude.
    • Sync en realidad no es más que un almacén de blobs terriblemente sobrediseñado. Cuando salió la versión 1.5 implementé servidores alternativos de Accounts+Sync: https://gitlab.com/drdaeman/firesync/
      Lleva mucho tiempo abandonado y el código no es más que una prueba de concepto bastante mala, pero aun así significa que puedo opinar sobre este tema con algo de fundamento.
      Para usuarios técnicos, creo que lo mejor sería que los forks de Firefox reemplazaran Sync por algo más estándar, como S3 o WebDAV. Si no recuerdo mal, Sync no tiene ninguna función que esos protocolos no puedan manejar igual, o incluso mejor. Esas alternativas sí son estándares realmente interoperables hasta cierto punto.
      Me gustaría que Mozilla también hiciera eso, pero parece tener una preferencia demasiado fuerte por desarrollar todo en casa, así que es difícil esperarlo. Me alegra mucho que esa tendencia nos haya dado Rust, pero Sync es casi basura que no deberían haber creado desde el principio.
    • Para que quede constancia, Firefox Sync funcionó exactamente así durante bastante tiempo.
      https://blog.mozilla.org/services/2011/03/22/get-syncing-wit...
      Una de las primeras preguntas era si querías usar un Custom Sync Server, y ese “Custom Sync Server” podía ser algo tan simple como un servidor WebDAV. Si tenías un servidor HTTP público, casi seguro ya lo soportaba o solo necesitaba agregar muy pocas dependencias. Además, también preguntaba por una clave de cifrado de extremo a extremo separada de la clave de inicio de sesión.

  • Felicitaciones por haber logrado autoalojarlo. Dicho eso, la solución parece más compleja de lo necesario. No debería hacer falta levantar un servidor de base de datos y Docker para sincronizar una cantidad muy pequeña de datos. Lo ideal sería usar SQLite y tener una implementación de servidor de sincronización ejecutable de forma independiente.

    • En teoría se podría crear un servidor de sincronización simple que implemente solo los endpoints necesarios. Esta guía ejecuta el servidor de sincronización mantenido oficialmente por Mozilla, que obviamente está pensado para atender a millones de usuarios, no como una implementación mínima para un homelab.
      Alguien podría hacer un fork de https://github.com/mozilla-services/syncstorage-rs, quitarle los accesorios y reimplementarlo sin bases de datos auxiliares ni una arquitectura basada en Google Cloud. Pero, como muchas cosas, primero habría que reunir a personas con suficiente interés y tiempo libre para desarrollarlo.
    • Es cierto, pero aun así el solo hecho de que se pueda autoalojar ya tiene valor. Muchos navegadores ni siquiera permiten eso.
    • Hay una solicitud de merge abierta.
      https://github.com/mozilla-services/syncstorage-rs/issues/49...