Openrsync - อิมพลีเมนต์ rsync ของทีม OpenBSD

• openrsync เป็นระบบที่อิมพลีเมนต์ rsync ภายใต้ไลเซนส์ BSD (ISC) และปัจจุบันถูกรวมเข้าใน OpenBSD base แล้ว
• เข้ากันได้กับ rsync รุ่นใหม่ โดยใช้ rsync 3.1.3 ในการทดสอบ แต่สามารถทำงานได้หากรองรับโปรโตคอล 27
• เนื่องจากไม่ได้รับอาร์กิวเมนต์บรรทัดคำสั่งของ rsync ครบทั้งหมด แต่รับได้เพียง บางอาร์กิวเมนต์เท่านั้น ดังนั้นเมื่อใช้ openrsync ร่วมกับ rsync ต้องใช้แฟลกที่ทั้งสองฝั่งรองรับ
• ระบบปฏิบัติการที่รองรับอย่างเป็นทางการคือ OpenBSD และมี glue สำหรับพกพาข้ามระบบรวมอยู่ด้วย เพื่อให้คอมไพล์และรันบนระบบ UNIX อื่น ๆ ได้
• เอกสารมาตรฐานคือหน้าคู่มือ โดยรายละเอียดโปรโตคอลอยู่ใน rsync(5) และ rsyncd(5) ส่วนเอกสารยูทิลิตีอยู่ใน openrsync(1)
• โครงการนี้ถูกเขียนขึ้นเป็นส่วนหนึ่งของ rpki-client(1) สำหรับ OpenBSD และได้รับเงินสนับสนุนจาก NetNod, IIS.SE, SUNET, 6connect
• การติดตั้งบนระบบ UNIX ทั่วไปทำได้ด้วย ./configure, make, make install และไม่ชนกับการติดตั้ง rsync เดิม
• อัลกอริทึมของ rsync แบ่งเป็น sender และ receiver โดย sender จะสร้างรายการไฟล์ต้นทางและเมทาดาทา และทั้งสองฝั่งจะเรียงชื่อไฟล์ตามลำดับพจนานุกรมเพื่ออ้างอิงรายการตามตำแหน่ง
• การซิงก์ไฟล์ทั่วไปจะข้ามไปหากขนาดไฟล์และเวลาที่แก้ไขตรงกัน แต่ถ้าต่างกันจะใช้แฮชแบบ Adler-32 ชนิดเร็วขนาด 4 ไบต์ และแฮช MD4 ชนิดช้าขนาด 16 ไบต์ในแต่ละบล็อกขนาดคงที่ เพื่อสร้างข้อมูลที่เปลี่ยนแปลงขึ้นใหม่
• ขนาดบล็อกเริ่มต้นคือค่าที่ได้จากการปัดค่ารากที่สองของขนาดไฟล์ทั้งหมด โดยมีขนาดต่ำสุด 700 B และผลลัพธ์จากรากที่สองจะถูกปัดขึ้นเป็นจำนวนที่หารด้วย 8 ลงตัวด้วยเหตุผลที่ไม่ทราบแน่ชัด
• เซสชันแบ่งเป็นไคลเอนต์ที่ผู้ใช้รัน และโพรเซสเซิร์ฟเวอร์ที่รันจากระยะไกล โดยเซิร์ฟเวอร์สามารถถูกรันตามต้องการผ่าน ssh(1) หรือทำงานเป็น network daemon ที่รันต่อเนื่อง
• ต่างจาก generator ของ rsync ที่ทำงานเป็นอีกโพรเซสหนึ่งข้าง receiver, openrsync รวม generator และ receiver ไว้ในโพรเซสเดียว และตอบสนองต่อคำขออ่าน·เขียนด้วย event loop
• ในด้านความปลอดภัย มีการใช้ pledge(2) ของ OpenBSD เพื่อจำกัดงานของระบบตามโหมดการทำงาน และใช้ unveil(2) เพื่ออนุญาตการเข้าถึงไฟล์ซิสเต็มเฉพาะใต้ไดเรกทอรีปลายทางเท่านั้น
• ในโหมดเซิร์ฟเวอร์ ค่า seed ของแฮช MD4 ถูกสร้างด้วย arc4random(3) ไม่ใช่ time(3)
• สามารถพอร์ตไปยัง Linux (glibc·musl), FreeBSD, NetBSD, Mac OS X, OmniOS ได้ และ GitHub CI จะทดสอบบนสถาปัตยกรรม x86_64, aarch64, s390x แต่ข้อจำกัดสำคัญของการพอร์ตคือการทำให้ได้ฟีเจอร์ความปลอดภัยที่เทียบเท่า pledge และ unveil ของ OpenBSD

[GN⁺]

ความเห็นจาก Hacker News

• คำอธิบายที่บอกว่าถ้าเซิร์ฟเวอร์ระยะไกลเป็นต้นทางหรือปลายทาง ไคลเอนต์จะสร้างโปรเซสลูกด้วย fork(2) แล้วสตาร์ตเซิร์ฟเวอร์ openrsync บนโฮสต์ระยะไกลผ่าน ssh(1) จากนั้นไคลเอนต์กับเซิร์ฟเวอร์จะสื่อสารกันผ่านไพป์ socketpair(2) นั้นฟังดูคลุมเครือว่าใช้งานจริงอย่างไร
  เดาว่าหมายถึงโปรเซสลูกที่ถูก fork จะส่งต่อการเชื่อมต่อให้โปรเซสแม่ผ่านคู่ซ็อกเก็ต หรือไม่ก็เชื่อม standard input/output เข้ากับ “ไพป์” แบบคู่ซ็อกเก็ตแล้ว exec ไปเป็น ssh
  แต่นี่ก็เหมือนพูดว่าไปสนามบินด้วยรถ แล้วบอกว่า ขับรถไปออสเตรเลีย

• ผมใช้ openrsync มาตั้งแต่มีประกาศออกมา และมันก็ดีขึ้นอย่างเห็นได้ชัดเรื่อย ๆ ตามเวลา รอวันที่จะใช้แทนได้ทั้งหมดอยู่
  แต่ในรูปแบบการใช้งานของผม มีอยู่จุดหนึ่งที่มันไม่ตรงกับ Samba rsync: openrsync --rsync-path=openrsync -av -e ssh /etc/services example.com:/tmp/services
  สิ่งที่คาดหวังคือให้สร้างไฟล์ /tmp/services บนเครื่องปลายทาง แต่ผลจริงกลับสร้าง /tmp/services/services
  การมิเรอร์ไดเรกทอรีทั่วไปอย่าง -av -e ssh /path/to/src/ example.com:/path/to/dst/ ทำงานเหมือน Samba rsync

  • พฤติกรรมนี้ดูเหมือนจะตรงกับ rsync “ปกติ” ด้วย ถ้าจะซิงก์เฉพาะเนื้อหา ก็น่าจะต้องมี เครื่องหมายทับท้าย หลัง services
    แก้ไข: จริง ๆ แล้ว rsync “ปกติ” ของผมก็คือ openrsync บน macOS นี่เอง
  • ประเด็นสำคัญคือตอนนั้นปลายทางมีไดเรกทอรี /tmp/services อยู่แล้วหรือไม่
    นี่เป็นหนึ่งในส่วนที่ทำให้ rsync สับสนที่สุด คือการจัดการ ไดเรกทอรีกับเครื่องหมายทับท้าย
  • ถ้าใส่เครื่องหมายทับท้ายที่ต้นทาง จะคัดลอกสิ่งที่อยู่ข้างในไดเรกทอรี แต่ถ้าไม่ใส่ จะคัดลอกทั้งไดเรกทอรีเอง เท่าที่ผมรู้ นี่เป็นพฤติกรรมที่ค่อนข้างมาตรฐานในเครื่องมือแบบ POSIX โดยรวม
  • ในฐานะคนที่โดน rsync ทรมานมานับครั้งไม่ถ้วนและนานมาก ผมเข้าใจแรงกระตุ้นนั้น แต่การสร้าง services ตัวที่สองกลับดูสมเหตุสมผลกว่าและเป็น ค่าเริ่มต้นที่ปลอดภัยกว่า มาก
    ถ้ามีโอกาสปรับค่าเริ่มต้นของ rsync ให้บ้าคลั่งน้อยลง ก็ควรช่วยคนรุ่นหลังออกจากความสับสนนี้

• พอเห็นว่าช่วงหลังในโค้ดเบส rsync มี คอมมิต vibe coding โผล่มาเพิ่มขึ้นแบบกะทันหัน และยังทำให้เกิด regression ตามมา นี่ถือเป็นข่าวดีมาก

  • ปกติ rsync แข็งแกร่งมาโดยตลอด ผมเลยพยายามไม่ใส่ใจคำพูดแบบนี้ แต่หลังอัปเกรดจริง ๆ สคริปต์แบ็กอัปของผมพังไปเลย
    ใน issue ล่าสุดบน GitHub มีการรวบรวมบั๊กจำนวนมากที่หลุดเข้ามาใน 2 แพตช์ล่าสุด รวมถึง คอมมิตยักษ์ราว 9,000 บรรทัด ที่อาจแทบไม่มีประโยชน์อะไร
    LLM ทำให้การเขียนโค้ดเร็วและง่ายขึ้นก็จริง แต่สิ่งสำคัญมาตลอดคือการคิด ผมไม่เข้าใจว่าทำไมต้องทำซอฟต์แวร์เก่าแก่ที่เชื่อถือได้แบบนี้พังลงด้วย

• สำหรับคนที่อยากรู้ที่มาของการพัฒนาแพ็กเกจนี้ โปรเจกต์นี้กำลังพัฒนาอยู่ในฐานะส่วนหนึ่งของ ตัวตรวจสอบ RPKI ในปัจจุบัน
  https://medium.com/@jobsnijders/a-proposal-for-a-new-rpki-va...

• ยังมีเวอร์ชันที่เขียนด้วย Go โดย Michael Stapelberg / ทีม Gokrazy ด้วย: https://github.com/gokrazy/rsync

  • ถึงจะบอกว่าเป็นทีม Gokrazy แต่จริง ๆ แล้วแทบจะเป็น Michael Stapelberg คนเดียวเลย : )
    https://github.com/gokrazy/rsync/graphs/contributors

• แก่นของงานพอร์ตจริง ๆ คือการทำให้เทียบเท่ากับ ฟีเจอร์ด้านความปลอดภัย ที่ pledge(2) และ unveil(2) ของ OpenBSD มีให้ ซึ่งเป็นองค์ประกอบสำคัญของระบบ
  ถ้าไม่มีฟีเจอร์เหล่านี้ ระบบก็จะรับข้อมูลตามอำเภอใจจากเครือข่ายสาธารณะ
  https://justine.lol/pledge/
  บน Alpine Linux edge ดูเหมือนจะไม่มี pledge มีใครเคยทดสอบ Pledge บน Linux บ้างไหม? ผมเข้าใจความเสี่ยงของการใช้ openrsync โดยไม่มี pledge ผิดไปหรือเปล่า หรือบทความนี้ตั้งใจพูดกับผู้ใช้ OpenBSD เท่านั้น?

  • บน Linux ไม่มีอะไรอย่าง pledge, unveil หรือ Capsicum มีแต่ cgroups, namespace และของจุกจิกอีกสารพัดที่ต้องประกอบกันถ้าจะให้ทำงานคล้ายกัน
    Linux ไม่ได้ถูกออกแบบเป็นฟีเจอร์แยกส่วนแบบที่ให้แนวคิดครบทั้งชุดผ่าน system call และเส้นทางในเคอร์เนลเฉพาะ แต่เป็นการค่อย ๆ เพิ่มระบบหลายชุดที่นำมาประกอบกันเพื่อทำ sandboxing หรือจำกัดความสามารถ
    ทุกวันนี้ฝั่ง Linux ก็ดูเหมือนจะมีของใหม่อย่าง Landlock แต่ก็น่าจะเป็นการวางทับบนองค์ประกอบพื้นฐานเดิมของ Linux มากกว่าการสร้างใหม่หมด
    คำว่า “เละเทะ” ในที่นี้น่าจะหมายถึงมันกระจัดกระจายไปทั่ว มีวิธีล็อกดาวน์มากเกินไป และถ้าจะเลือกว่าวิธีไหนดีที่สุดก็ต้องเจาะลึกแต่ละซับซิสเต็ม เทียบกับการใช้ system call ง่าย ๆ แค่ 1-2 ตัว
  • เหนือข้อความที่อ้างมามีประโยคนี้: “ระบบปฏิบัติการที่รองรับอย่างเป็นทางการมีเพียง OpenBSD เพราะมีฟีเจอร์ด้านความปลอดภัยในระดับสูง”
    และด้านล่างก็มีอีกประโยคว่า: “บน FreeBSD น่าจะทำได้ด้วย Capsicum แต่โครงสร้างด้านความปลอดภัยของ Linux เละเทะและต้องอาศัยผู้เชี่ยวชาญเพื่อทำให้ปลอดภัยอย่างเหมาะสม”
    ดังนั้นคำว่า portable ในที่นี้หมายถึงคอมไพล์และรันได้ ไม่ได้หมายความว่าจะมีฟีเจอร์ความปลอดภัยเหมือนกัน
    คงจะดีถ้า pledge/unveil เข้า upstream ของ Linux แต่ผมไม่ได้คาดหวังหรอก
  • ข้อความที่ยกมานั้นเรียบง่ายเกินไปจนแทบจะผิดเกือบทั้งหมด
    ต่างจากประโยคที่ว่า “ถ้าไม่มีฟีเจอร์เหล่านี้ ระบบจะรับข้อมูลตามอำเภอใจจากเครือข่ายสาธารณะ” จริง ๆ แล้ว pledge หรือ unveil ไม่ได้เปลี่ยนว่าระบบจะรับข้อมูลตามอำเภอใจหรือไม่ สิ่งที่มันทำคือจำกัด สิ่งที่โปรเซสซึ่งถูกเจาะช่องโหว่แล้วจะทำได้
    ในส่วน Security มีการอธิบายไว้อย่างถูกต้องอยู่แล้ว เลยไม่รู้ว่าถ้อยคำแบบนั้นมาจากไหน

• เวอร์ชันนี้คือเวอร์ชันที่เริ่มถูกใช้ตั้งแต่ macOS 15.0

  • 15.0 เหรอ? ผมจำได้ลาง ๆ ว่ามันเข้ามาในหนึ่งในไมเนอร์รีลีสของสาย 15.x และจำได้ว่าสคริปต์บางตัวพังแบบอธิบายไม่ได้
    แก้ไข: ตลกดีที่มันถูกรวมมากับ 15.0 ก็จริง แต่ดูเหมือนจะเก็บการเปลี่ยนแปลงแบบพังความเข้ากันได้ย้อนหลังไว้จนถึง 15.4 https://apple.stackexchange.com/a/479297

• ช่วงหลังมันไม่รองรับโปรโตคอล rsync เลยไม่มีการรองรับ timestamp แบบ 64 บิต และทำให้ไม่สามารถซิงก์เมทาดาทาบนไฟล์ซิสเต็มรุ่นใหม่ได้จริง

• สงสัยว่าทำไมถึงตั้งชื่อนี้ Openrsync ฟังดูเหมือนเป็นโอเพนซอร์สทางเลือกของโปรแกรมปิดซอร์ส
  แต่ Rsync ต้นฉบับก็เป็น GPL ไม่ใช่เหรอ? หรือคำว่า “เปิดกว่า” หมายถึงใช้ไลเซนส์ที่ผ่อนปรนกว่า?

  • คนฝั่ง OpenBSD น่าจะมองว่า GPL เปิดน้อยกว่า เพราะมีข้อกำหนดให้ต้องใช้ GPL กับงานดัดแปลงด้วย
  • ในบรรดาโปรเจกต์ที่ใกล้ชิดกับ OpenBSD มีหลายตัวที่ขึ้นต้นด้วย open เช่น openssh, openbgpd, openntpd, opensmtpd