โฮสต์เซิร์ฟเวอร์ Firefox Sync ด้วยตนเอง

 (blog.diego.dev)
1 คะแนน โดย GN⁺ 2025-03-03 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • หลังย้ายจาก Firefox ไปใช้ LibreWolf จึงพยายามดูแลข้อมูลซิงก์ของเบราว์เซอร์ด้วยตนเอง และหลังจากตรวจสอบหลายรีโพซิทอรีกับการตั้งค่า Docker ก็สร้างเซิร์ฟเวอร์ที่ใช้งานได้สำเร็จ
  • syncserver เดิมของ Mozilla เป็นชุดแบบ all-in-one แต่มีคำเตือนว่าเลิกบำรุงรักษาแล้ว ทำให้ syncstorage-rs ที่พัฒนาด้วย Rust กลายเป็นตัวเลือกที่ใช้งานได้จริงกว่า
  • ขั้นตอน Docker อย่างเป็นทางการทำตามได้ยาก เพราะกระบวนการคัดลอก grpcio, protobuf, mozilla-rust-sdk ซับซ้อน จึงหันมาใช้การตั้งค่า syncstorage-rs-docker ของชุมชนเป็นฐานสำหรับการติดตั้งจริง
  • การตั้งค่าสุดท้ายใช้ docker-compose.yaml เพื่อรัน MariaDB 10.6.13 และ firefox_syncserver โดยให้ Caddy ทำ reverse proxy ไปยัง firefox_syncserver:8000
  • อุปสรรคหลักคือข้อมูลถาวรของ DB พื้นที่เก็บข้อมูลไม่พอ และการทดลองขั้นตอน Docker หลายรอบ ดังนั้นหากไม่คุ้นเคยกับ Docker หรือการดูแล DB ระดับความยากของการตั้งค่าจะค่อนข้างสูง

เหตุผลที่ย้ายจาก syncserver ไปใช้ syncstorage-rs

  • หลังเปลี่ยนจาก Firefox ไปใช้ LibreWolf ก็เริ่มลงมือโฮสต์ Firefox Sync server ด้วยตนเอง
  • Mozilla syncserver ที่พบในตอนแรกเป็นแพ็กเกจแบบ all-in-one สำหรับ self-hosting
    • รวม tokenserver สำหรับการยืนยันตัวตนและ syncstorage สำหรับพื้นที่เก็บข้อมูลไว้ด้วยกัน
    • มีแท็ก “failed” อยู่ในประวัติการบิลด์
    • ในรีโพซิทอรีมีคำเตือนว่าไม่ได้รับการบำรุงรักษาอีกต่อไป และให้ย้ายไปใช้โปรเจ็กต์ใหม่ที่พัฒนาด้วย Rust
  • จากนั้นจึงเลือก syncstorage-rs
    • เป็นเวอร์ชัน Rust-based ที่ทันสมัยของโปรเจ็กต์เดิม
    • ไม่มี Docker image แบบพร้อมใช้งานทันที
    • เอกสารมีวิธีรันด้วย Docker แต่ลำดับการตั้งค่าค่อนข้างซับซ้อน
  • มีหลายจุดที่ติดขัดในเอกสาร Docker อย่างเป็นทางการ
    • มีคำแนะนำให้ปรับเวอร์ชันของ grpcio และ protobuf ให้ตรงกับเวอร์ชันที่ google-cloud-rust-raw ใช้อยู่
    • ต้องคัดลอกเนื้อหาของ mozilla-rust-sdk มายังไดเรกทอรีรากระดับบนสุดด้วยตนเอง
    • ต่อให้ตรวจดูรีโพซิทอรี, Dockerfile, Makefile และ CircleCI workflow แล้ว ขั้นตอนถัดไปก็ยังไม่ชัดเจน
  • syncstorage-rs-docker ให้การตั้งค่า Docker ที่เรียบง่ายกว่า
    • มีคำอธิบายว่าผู้จัดทำสร้าง Docker container สำหรับโครงสร้างพื้นฐานของตนเองขึ้นหลังจากเจอปัญหากับเอกสารเดิม
    • จึงนำการตั้งค่านี้มาเป็นฐานสำหรับคอนฟิกเซิร์ฟเวอร์จริง

การติดตั้งใช้งานจริงด้วย Docker Compose และ Caddy

  • ใน docker-compose.yaml ได้เพิ่มบริการ MariaDB และบริการ Firefox Sync server
    • firefox_mariadb ใช้ image linuxserver/mariadb:10.6.13
    • ตั้งค่า DB data volume เป็น /data/ffsync/dbdata:/config
    • firefox_syncserver บิลด์ Dockerfile จาก /root/ffsync และเปิดพอร์ต 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 reverse proxy ให้ชี้ไปยัง Sync server ตัวใหม่
    • ตัวอย่างคอนฟิกคือเชื่อมต่อจาก mydomain:443 ไปยัง reverse_proxy firefox_syncserver:8000
    • หลังอัปเดต DNS entry แล้วรีสตาร์ต Caddy ก็สามารถใช้งาน Sync server ได้

ปัญหาที่พบระหว่างการตั้งค่าและเวลาที่ใช้

  • ปัญหาใหญ่ที่สุดคือ ข้อมูลถาวรของ MariaDB และเมื่อรีสตาร์ตคอนเทนเนอร์ บางครั้งจำเป็นต้องลบข้อมูลเก่าออก
  • Docker image และไฟล์ชั่วคราวมีขนาดใหญ่ขึ้นจนพื้นที่เก็บข้อมูลบนเซิร์ฟเวอร์ไม่พอ
  • ต้องทดลองการตั้งค่า Docker หลายครั้งกว่าจะเจอขั้นตอนที่ถูกต้อง
  • การมี Firefox Sync server ของตัวเองไม่ใช่งานที่จบได้ง่ายหากไม่คุ้นกับ 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 ครั้ง ใส่ URL ของ content-server ใน “Advance Account Settings” แล้วเปิด “Use Custom Account Service”
      https://mozilla-services.readthedocs.io/en/latest/howtos/run...
    • สักวันหนึ่งทั้งสแตกอาจถูกรวมอยู่ใน Docker container เดียว พร้อมเชลล์สคริปต์สำหรับการตั้งค่า
    • สงสัยว่าทำไมอีเมลถึงต้องพึ่งพาโครงสร้างพื้นฐานของ Mozilla
    • ตัดคนกลางออกไป แล้วใช้ Google โดยตรงไปเลยก็ได้

  • Garuda Linux เปิดเซิร์ฟเวอร์ Firefox Sync ของตัวเองสำหรับเบราว์เซอร์ FireDragon มานานพอสมควรแล้ว
    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 เป็นค่าเริ่มต้นเหมือนเวอร์ชันเก่า แต่ผู้มีส่วนร่วมหลักดูเหมือนจะเอนเอียงไปทางการเลียนแบบบริษัท เขียนบทความเพื่อให้การเก็บ metric และการนำเฟรมเวิร์ก metric ใหม่มาใช้ดูสมเหตุสมผล มากกว่าจะทำให้การโฮสต์เองทำได้ง่ายขึ้น

  • ลองดูหรือกดติดตาม 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] ถ้ารวมเข้าเร็ว ๆ น่าจะทำให้การแบ็กอัป storage สำหรับ sync ทั้งหมดเป็นไฟล์ 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 มีการเข้ารหัสแบบ end-to-end อยู่แล้ว ก็สงสัยว่าข้อดีด้านความเป็นส่วนตัวคืออะไร
    https://support.mozilla.org/en-US/kb/sync

    • เท่าที่ผมรู้ หน้าเข้าสู่ระบบกับโค้ด JavaScript ก็ยังถูกส่งผ่านอินเทอร์เน็ตอยู่ดี และคีย์เข้ารหัสก็ได้มาจากรหัสผ่านเท่านั้น นี่ไม่ใช่ดีไซน์ที่ดีสำหรับข้อมูลที่อ่อนไหวอย่างข้อมูลเบราว์เซอร์ทั้งหมด

  • มี Floccus ที่คล้ายกับ Firefox Sync ถ้าต้องการซิงก์แค่บุ๊กมาร์กกับแท็บ การตั้งค่าดูจะง่ายกว่า
    https://floccus.org/

  • อยากให้ LibreWolf กับ Waterfox เปลี่ยนแนวทางให้ชัดเจนว่ากำลังใช้ Mozilla Sync Server และทำให้เป็นตัวเลือกประมาณนี้
    หากต้องการซิงก์ โปรดเลือกหนึ่งในตัวเลือกด้านล่าง:
    [x] Custom Sync Server: ___________
    [ ] Mozilla Sync

    • LibreWolf เป็นแบบเลือกได้อยู่แล้ว และถ้าคนกดช่องทำเครื่องหมายที่เขียนว่า “Firefox Sync” แล้วคิดว่ามันเป็นการซิงก์อย่างอื่นที่ไม่ใช่ Firefox Sync ก็คงไม่มีการเปลี่ยน UI แบบไหนช่วยได้มากนัก
    • จริง ๆ แล้ว Sync ก็เป็นแค่ blob storage ที่ออกแบบเกินจำเป็นอย่างน่ากลัว ผมเคยทำเซิร์ฟเวอร์ Accounts+Sync ทางเลือกตอน 1.5 ออกมา: https://gitlab.com/drdaeman/firesync/
      มันทิ้งร้างมานานแล้ว และโค้ดก็เป็นแค่ proof of concept ที่แย่มาก แต่ก็หมายความว่าผมพอจะมีพื้นฐานในการตัดสินเรื่องนี้อยู่บ้าง
      สำหรับผู้ใช้สายเทคนิค ผมคิดว่าทางที่ดีที่สุดคือให้ Firefox forks เปลี่ยนจาก 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 สาธารณะอยู่แล้ว ก็แทบจะรองรับอยู่แล้วหรือเพิ่ม dependency อีกน้อยมากก็พอ และยังถามถึง คีย์เข้ารหัสแบบ end-to-end ที่แยกจากคีย์ล็อกอินด้วย

  • การโฮสต์เองสำเร็จเป็นเรื่องน่ายินดี แต่อย่างไรก็ดี วิธีแก้ดูซับซ้อนเกินจำเป็น ไม่น่าต้องตั้งทั้งเซิร์ฟเวอร์ฐานข้อมูลและ Docker เพียงเพื่อซิงก์ข้อมูลจำนวนน้อยมาก ตามอุดมคติคืออยากให้ใช้ SQLite และมี implementation ของเซิร์ฟเวอร์ซิงก์ที่รันเดี่ยวได้

    • ในทางทฤษฎีสามารถทำเซิร์ฟเวอร์ซิงก์แบบง่ายที่ implement เฉพาะ endpoint ที่จำเป็นได้ ไกด์แบบนี้รันเซิร์ฟเวอร์ซิงก์ที่ Mozilla ดูแลอย่างเป็นทางการ ซึ่งแน่นอนว่าถูกสร้างตามมาตรฐานสำหรับให้บริการผู้ใช้หลายล้านคน ไม่ใช่ implementation ขั้นต่ำสำหรับ homelab
      อาจมีใครสักคน fork https://github.com/mozilla-services/syncstorage-rs แล้วตัดส่วนประกอบเสริมออก และ implement ใหม่โดยไม่ต้องมีฐานข้อมูลรองกับสถาปัตยกรรมบน Google Cloud ก็ได้ แต่ก็เหมือนงานหลาย ๆ อย่าง ต้องรวบรวมคนที่สนใจและมีเวลาว่างพอเพื่อพัฒนาก่อน
    • ใช่ แต่แค่โฮสต์เองได้ก็มีความหมายแล้ว เบราว์เซอร์จำนวนมากทำได้ไม่ถึงขั้นนั้นด้วยซ้ำ
    • มี merge request ที่เปิดอยู่
      https://github.com/mozilla-services/syncstorage-rs/issues/49...