Openrsync - Bản triển khai rsync của nhóm OpenBSD

• openrsync là một hệ thống triển khai rsync theo giấy phép BSD (ISC), hiện đã được hợp nhất vào base của OpenBSD
• Tương thích với rsync mới nhất và rsync 3.1.3 được dùng để kiểm thử, nhưng có thể hoạt động nếu hỗ trợ giao thức 27
• Vì chỉ chấp nhận một phần tham số dòng lệnh của rsync chứ không phải toàn bộ, nên khi dùng openrsync cùng với rsync cần sử dụng các cờ được cả hai bên hỗ trợ
• Hệ điều hành được hỗ trợ chính thức là OpenBSD, và có kèm glue phục vụ tính di động để có thể biên dịch và chạy trên các hệ UNIX khác
• Tài liệu chuẩn là các trang manual; chi tiết giao thức có trong rsync(5) và rsyncd(5), còn tài liệu tiện ích nằm ở openrsync(1)
• Dự án được viết như một phần của rpki-client(1) cho OpenBSD, với kinh phí từ NetNod, IIS.SE, SUNET, 6connect
• Việc cài đặt trên các hệ UNIX thông thường được thực hiện bằng ./configure, make, make install, và không xung đột với bản cài rsync hiện có
• Thuật toán rsync được chia thành sender và receiver; sender tạo danh sách tệp nguồn và metadata, sau đó hai bên sắp xếp tên tệp theo thứ tự từ điển để tham chiếu các mục dựa trên vị trí
• Với đồng bộ tệp thông thường, nếu kích thước tệp và thời gian sửa đổi giống nhau thì sẽ bỏ qua; nếu khác, dữ liệu thay đổi sẽ được tái dựng bằng cách dùng hash nhanh kiểu Adler-32 4 byte và hash MD4 chậm 16 byte cho từng khối có kích thước cố định
• Kích thước khối mặc định là giá trị làm tròn của căn bậc hai tổng kích thước tệp; kích thước tối thiểu là 700 B, và kết quả căn bậc hai vì lý do chưa rõ sẽ được làm tròn lên thành bội số của 8
• Phiên làm việc được chia thành client do người dùng chạy và tiến trình server chạy từ xa; server có thể được khởi chạy theo nhu cầu bằng ssh(1) hoặc chạy như một network daemon thường trú
• Khác với generator của rsync chạy như một tiến trình riêng bên cạnh receiver, openrsync gộp generator và receiver vào một tiến trình và phản hồi các yêu cầu đọc/ghi bằng event loop
• Về bảo mật, nó dùng pledge(2) của OpenBSD để giới hạn các thao tác hệ thống theo từng chế độ chạy, và dùng unveil(2) để chỉ cho phép truy cập hệ thống tệp bên dưới thư mục đích
• Ở chế độ server, seed cho hash MD4 được tạo bằng arc4random(3) thay vì time(3)
• Có thể port sang Linux (glibc·musl), FreeBSD, NetBSD, Mac OS X, OmniOS, và GitHub CI thực hiện kiểm thử trên các kiến trúc x86_64, aarch64, s390x; tuy nhiên việc tái tạo các tính năng bảo mật tương ứng với pledge và unveil của OpenBSD là ràng buộc cốt lõi khi port

[GN⁺]

Ý kiến trên Hacker News

• Phần mô tả rằng nếu máy chủ từ xa là nguồn hoặc đích thì client sẽ tạo tiến trình con bằng fork(2), khởi chạy server openrsync trên host từ xa qua ssh(1), rồi client và server giao tiếp bằng pipe socketpair(2) khá mơ hồ về việc thực sự vận hành như thế nào
  Có lẽ ý là tiến trình con sau khi fork sẽ chuyển tiếp kết nối cho tiến trình cha qua cặp socket, hoặc nối stdin/stdout vào “pipe” cặp socket rồi exec ssh
  Nhưng điều này giống như nói bạn lái xe ra sân bay rồi bảo là đi Úc bằng ô tô

• Tôi đã dùng openrsync ở nhiều nơi kể từ khi nó được công bố, và theo thời gian nó rõ ràng đã tốt hơn. Tôi đang chờ đến lúc có thể dùng hoàn toàn nó
  Tuy vậy, với kiểu sử dụng của tôi có một điểm nó không khớp với Samba rsync: openrsync --rsync-path=openrsync -av -e ssh /etc/services example.com:/tmp/services
  Hành vi tôi mong đợi là tạo file /tmp/services ở máy từ xa, nhưng thực tế nó lại tạo /tmp/services/services
  Các trường hợp mirror thư mục thông thường như -av -e ssh /path/to/src/ example.com:/path/to/dst/ thì hoạt động giống Samba rsync

  • Có vẻ hành vi này cũng khớp với rsync “thông thường”. Nếu chỉ muốn đồng bộ nội dung thì có lẽ cần dấu gạch chéo ở cuối sau services
    Sửa: thật ra rsync “thông thường” của tôi cũng là openrsync trên macOS
  • Điểm mấu chốt là ở đích đã có sẵn thư mục /tmp/services hay chưa
    Đây là một trong những phần dễ gây nhầm nhất của rsync: cách xử lý thư mục và dấu gạch chéo cuối
  • Nếu thêm dấu gạch chéo cuối ở nguồn thì nó sao chép phần bên trong thư mục, còn nếu bỏ đi thì sao chép cả chính thư mục đó. Theo tôi biết thì đây là hành vi khá tiêu chuẩn trong nhiều công cụ POSIX
  • Với tư cách là người đã bị rsync hành hạ suốt vô số năm, tôi hiểu xung động đó, nhưng việc tạo services thứ hai hợp lý hơn nhiều và là mặc định an toàn hơn
    Nếu có cơ hội chỉnh mặc định của rsync theo hướng bớt điên hơn, thì nên cứu các thế hệ tương lai khỏi sự rối rắm này

• Nhìn vào việc gần đây codebase rsync đột nhiên có thêm rất nhiều commit vibe coding, thậm chí còn gây ra regression, thì đây là tin rất tốt

  • rsync vốn luôn vững chắc nên ban đầu tôi định bỏ ngoài tai, nhưng thực tế sau khi nâng cấp thì script backup của tôi đã hỏng
    Các issue mới nhất trên GitHub tổng hợp khá nhiều bug lọt vào trong 2 bản vá gần đây, kể cả một commit quái vật khoảng 9 nghìn dòng có lẽ cũng chẳng mang nhiều ý nghĩa
    LLM khiến việc viết code nhanh hơn và dễ hơn, nhưng điều quan trọng luôn là suy nghĩ. Tôi không hiểu vì sao lại phá hỏng một phần mềm lâu đời và đáng tin cậy như thế này

• Nói cho những ai cần bối cảnh phát triển của gói này: dự án hiện đang được phát triển như một phần của trình xác thực RPKI
  https://medium.com/@jobsnijders/a-proposal-for-a-new-rpki-va...

• Cũng có bản triển khai bằng Go của Michael Stapelberg / nhóm Gokrazy: https://github.com/gokrazy/rsync

  • Nói là nhóm Gokrazy nhưng thực ra về cơ bản là Michael Stapelberg : )
    https://github.com/gokrazy/rsync/graphs/contributors

• Trọng tâm thật sự của công việc port là tái hiện các tính năng bảo mật mà pledge(2) và unveil(2) của OpenBSD cung cấp. Chúng là yếu tố mang tính quyết định của hệ thống
  Nếu không có những tính năng này thì hệ thống sẽ chấp nhận dữ liệu tùy ý từ mạng công khai
  https://justine.lol/pledge/
  Trên Alpine Linux edge tôi không thấy pledge. Có ai đã thử pledge trên Linux chưa? Có phải tôi đang hiểu sai rủi ro của việc dùng openrsync không có pledge, hay bài viết này chỉ dành cho người dùng OpenBSD?

  • Linux không có các tính năng như pledge, unveil hay Capsicum. Nó có cgroups, namespace, và đủ thứ lặt vặt phải ghép lại nếu muốn làm điều tương tự
    Linux được xây theo kiểu nhiều hệ thống được thêm dần lặp đi lặp lại rồi kết hợp với nhau để tạo thành sandboxing hoặc giới hạn tính năng, thay vì một khả năng cô lập cung cấp toàn bộ khái niệm thông qua các system call và đường dẫn kernel cụ thể
    Dạo này phía Linux hình như còn có các tính năng mới như Landlock, nhưng có lẽ vẫn là cách xây chồng lên các thành phần nền sẵn có của Linux chứ không phải làm lại hoàn toàn
    Từ “lộn xộn” ở đây có lẽ chỉ có nghĩa là mọi thứ nằm rải rác khắp nơi. Có quá nhiều cách để khóa lại, và để chọn cách tốt nhất thì phải đào sâu vào từng subsystem, trái ngược với việc chỉ dùng 1–2 system call đơn giản
  • Ở phía trên đoạn được trích có viết: “Hệ điều hành được hỗ trợ chính thức chỉ có OpenBSD, vì nó có các tính năng bảo mật đáng kể”
    Và bên dưới có viết: “Có vẻ có thể làm được với Capsicum của FreeBSD, nhưng các cơ chế bảo mật của Linux thì lộn xộn và cần bàn tay của chuyên gia để gia cố đúng cách”
    Tức là portable ở đây chỉ có nghĩa là biên dịch và chạy được, chứ không có nghĩa là có cùng mức tính năng bảo mật
    Sẽ tốt nếu pledge/unveil có mặt ở upstream Linux, nhưng tôi không kỳ vọng điều đó
  • Câu trích đó bị đơn giản hóa quá mức đến mức gần như hoàn toàn sai
    Không giống câu “nếu không có các tính năng này thì hệ thống sẽ chấp nhận dữ liệu tùy ý từ mạng công khai”, pledge hay unveil không thay đổi việc có nhận dữ liệu tùy ý hay không. Chúng giới hạn những gì một tiến trình đã bị khai thác lỗ hổng có thể làm
    Phần Security giải thích đúng hơn, nên tôi không rõ cách diễn đạt kia từ đâu ra

• Đây là phiên bản đã được dùng từ macOS 15.0

  • 15.0 à? Tôi nhớ là nó xuất hiện ở một bản phát hành phụ nào đó trong nhánh 15.x, và tôi cũng nhớ có vài script bị hỏng một cách khó hiểu
    Sửa: buồn cười là đúng là họ có đưa vào từ 15.0, nhưng có vẻ giữ lại thay đổi phá vỡ khả năng tương thích ngược đến tận 15.4. https://apple.stackexchange.com/a/479297

• Gần đây nó không hỗ trợ giao thức rsync, nên không có hỗ trợ timestamp 64-bit, vì thế trên các filesystem mới nó không thể thực sự đồng bộ metadata

• Tôi thắc mắc vì sao lại có tên đó. Openrsync nghe như một bản thay thế mã nguồn mở cho một chương trình mã nguồn đóng
  Nhưng Rsync gốc chẳng phải cũng là GPL sao? Hay chỉ là theo nghĩa “mở hơn” vì giấy phép dễ dùng hơn?

  • Những người phía OpenBSD có lẽ sẽ cho rằng GPL kém mở hơn vì nó yêu cầu áp GPL cho cả các tác phẩm phái sinh
  • Trong các dự án gắn chặt với OpenBSD có khá nhiều cái bắt đầu bằng open, như openssh, openbgpd, openntpd, opensmtpd