Openrsync - OpenBSDチームによるrsync実装
(github.com/kristapsdz)- openrsync は、rsync を BSD(ISC) ライセンスで実装したシステムで、現在は OpenBSD base に統合されている
- 最新の rsync と互換性があり、テストには rsync 3.1.3 が使われているが、プロトコル 27 をサポートしていれば動作可能
- rsync のコマンドライン引数すべてではなく、一部の引数のみを受け付けるため、openrsync と rsync を併用する場合は双方でサポートされるフラグを使う必要がある
- 公式サポート OS は OpenBSD であり、他の UNIX システムでもコンパイルして実行できるよう移植性のための glue が含まれている
- 標準ドキュメントはマニュアルページであり、プロトコルの詳細は rsync(5) と rsyncd(5)、ユーティリティのドキュメントは openrsync(1) にある
- プロジェクトは OpenBSD 向け rpki-client(1) の一部として書かれ、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) でオンデマンド起動されるか、常駐するネットワークデーモンとして動作する
- rsync では generator が receiver の横で別プロセスとして動作するのに対し、openrsync は generator と receiver を 1 つのプロセスに統合し、イベントループで読み書き要求に応答する
- セキュリティ面では OpenBSD の pledge(2) により実行モードごとのシステム操作を制限し、unveil(2) により宛先ディレクトリ以下のファイルシステムアクセスのみを許可する
- サーバーモードでは MD4 ハッシュシードは time(3) ではなく arc4random(3) によって生成される
- Linux(glibc・musl)、FreeBSD、NetBSD、Mac OS X、OmniOS へ移植可能で、GitHub CI が x86_64、aarch64、s390x アーキテクチャのテストを実施しているが、OpenBSD の pledge と unveil に相当するセキュリティ機能をどう合わせるかが移植の主要な制約となっている
1件のコメント
Hacker Newsのコメント
リモートサーバーが送信元または送信先である場合、クライアントが
fork(2)で子プロセスを作成し、ssh(1)を通じてリモートホスト上でサーバーopenrsyncを起動したあと、クライアントとサーバーがsocketpair(2)パイプで通信する、という説明は、どう動くのか曖昧に感じるおそらく fork された子がソケットペアで親に接続を渡すか、標準入出力をソケットペアの「パイプ」に接続してから
sshをexecする、という意味なのだと思うでもこれは、空港までは車で行くという話なのに、オーストラリアまで車で行くと言っているようなものだ
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も macOS のopenrsyncだった/tmp/servicesディレクトリがあったかどうかが重要だrsyncで最も紛らわしい点の一つが、ディレクトリと末尾スラッシュ の扱いだrsyncに苦しめられてきた身としてその衝動はわかるが、2つ目のservicesを作るほうがずっと筋が通っていて、より安全なデフォルト だと思うrsyncのデフォルトを少しでも狂っていない方向に変える機会があるなら、未来の世代をこの混乱から救うべきだ最近の
rsyncコードベースでは バイブコーディングのコミット が急に増え、それによるリグレッションまで起きているのを見ると、これはとても良いニュースだrsyncはずっと堅牢だったのでこの手の話は聞き流そうとしていたが、実際にアップグレード後、自分のバックアップスクリプトが壊れたGitHub の最新の issue には、直近2つのパッチで入ったバグが大量に整理されており、たぶん大した意味もなかったであろう怪物級の 約9000行コミット も含まれている
LLM はコードを書くことをより速く簡単にするが、いつだって重要なのは考えることだった。なぜこんなに古くて信頼されてきたソフトウェアを壊すのか理解できない
このパッケージの開発背景が必要な人のために言うと、このプロジェクトは現在 RPKI バリデータ の一部として開発されている
https://medium.com/@jobsnijders/a-proposal-for-a-new-rpki-va...
Michael Stapelberg / Gokrazy チームによる Go 実装もある: https://github.com/gokrazy/rsync
https://github.com/gokrazy/rsync/graphs/contributors
実際の移植作業の核心は、OpenBSD の
pledge(2)とunveil(2)が提供する セキュリティ機能 をどう再現するかにある。これらはシステム機能の決定的な要素だこれらの機能がなければ、システムは公開ネットワークから任意のデータを受け入れることになる
https://justine.lol/pledge/
Alpine Linux edge では
pledgeが見当たらない。Linux で Pledge を試してきた人はいるのだろうか？pledgeなしでopenrsyncを使う危険性について自分が誤解しているのか、それともこの記事は OpenBSD ユーザー向けにしか書かれていないのか？pledgeやunveil、Capsicum のような機能はない。cgroups、名前空間、そして同じようなことをするために組み合わせる雑多な仕組みがあるLinux は、特定のシステムコールとカーネルパスで概念全体を提供する隔離機能というより、複数の仕組みが繰り返し追加されて相互に組み合わされ、サンドボックス化 や機能制限を構成する方式で作られてきた
最近の Linux 側には Landlock のような新機能もあるようだが、おそらく完全に新しく作るのではなく、既存の Linux の基本要素の上に積み上げる形だろう
「ぐちゃぐちゃ」というのは、おそらくあちこちに散らばっているという意味だ。閉じる方法が多すぎて、どれが最善か選ぶには各サブシステムを深く掘る必要がある。単純な1〜2個のシステムコールだけを使うのとは対照的だ
そして下にはこうある: 「FreeBSD の Capsicum なら可能かもしれないが、Linux のセキュリティ設備はぐちゃぐちゃで、適切に安全化するには専門家の手が必要だ」
つまり ポータブル というのはコンパイルして実行できるという意味であって、同じセキュリティ機能を持つという意味ではない
Linux upstream に
pledge/unveilが入るとよいのだが、期待はしていない「これらの機能がなければ、システムが公開ネットワークから任意のデータを受け入れる」という言い方とは違って、
pledgeやunveilは任意データを受け入れるかどうかを変えるものではない。これらは 侵害されたプロセスができること を制限するSecurityセクションでは正しく説明されているので、あの表現がどこから来たのかわからないこのバージョンは macOS 15.0 から使われているものだ
訂正: 面白いことに 15.0 には含めていたものの、下位互換性を壊す変更は 15.4 まで温存していたようだ。 https://apple.stackexchange.com/a/479297
最近の
rsyncプロトコルをサポートしていないため、64ビットタイムスタンプ のサポートがなく、その結果、新しいファイルシステムではメタデータを実際には同期できないなぜそんな名前なのか気になる。
Openrsyncというと、クローズドソースのプログラムに対するオープンソース代替のように聞こえるでも元の
Rsyncも GPL ではなかったか？ 単にもっと扱いやすいライセンスだから「よりオープン」という意味なのか？openで始まるものが多い。openssh、openbgpd、openntpd、opensmtpdのような具合だ