Openrsync - OpenBSD टीम का rsync इम्प्लीमेंटेशन

• openrsync rsync का BSD(ISC) लाइसेंस के तहत बनाया गया इम्प्लीमेंटेशन है, और यह फिलहाल OpenBSD base में मर्ज किया जा चुका है
• यह नवीनतम rsync के साथ संगत है और परीक्षण में rsync 3.1.3 का उपयोग किया गया है, लेकिन यदि protocol 27 समर्थित हो तो यह काम कर सकता है
• यह rsync के पूरे command-line arguments नहीं बल्कि केवल कुछ arguments ही स्वीकार करता है, इसलिए openrsync और rsync को साथ इस्तेमाल करते समय दोनों तरफ समर्थित flags का उपयोग करना चाहिए
• आधिकारिक रूप से समर्थित operating system OpenBSD है, और अन्य UNIX systems पर compile और run किया जा सके इसके लिए portability glue शामिल है
• मानक documentation manual pages हैं, और protocol की विस्तृत जानकारी rsync(5) और rsyncd(5) में, जबकि utility documentation openrsync(1) में है
• यह प्रोजेक्ट OpenBSD के लिए rpki-client(1) के एक हिस्से के रूप में लिखा गया था, और NetNod, IIS.SE, SUNET, 6connect ने फंडिंग दी
• इंस्टॉलेशन सामान्य UNIX systems पर ./configure, make, make install से किया जाता है, और यह मौजूदा rsync installation से टकराव नहीं करता
• rsync algorithm sender और receiver में विभाजित होता है, जहाँ sender source files की सूची और metadata बनाता है और दोनों पक्ष filenames को dictionary order में sort करके position-based तरीके से entries को refer करते हैं
• सामान्य file synchronization में यदि file size और modification time समान हों तो उसे skip कर दिया जाता है, और यदि वे अलग हों तो fixed-size blocks के लिए तेज Adler-32 प्रकार का 4-byte hash और धीमा MD4 16-byte hash इस्तेमाल कर changed data को reconstruct किया जाता है
• block size का default मान पूरी file size के square root को round करके तय किया जाता है, न्यूनतम आकार 700 B है, और square root का परिणाम किसी अज्ञात कारण से 8 के multiple तक round up किया जाता है
• session उपयोगकर्ता द्वारा चलाए गए client और remote पर चलने वाली server process में विभाजित होता है, और server को ssh(1) के जरिए on-demand चलाया जा सकता है या यह लगातार चलने वाले network daemon की तरह काम कर सकता है
• rsync में जहाँ generator अलग process के रूप में receiver के पास चलता है, वहीं openrsync generator और receiver को एक ही process में जोड़ता है और event loop के जरिए read/write requests को संभालता है
• सुरक्षा के लिहाज़ से, OpenBSD का pledge(2) अलग-अलग execution modes के अनुसार system operations को सीमित करता है, और unveil(2) destination directory के नीचे ही filesystem access की अनुमति देता है
• server mode में MD4 hash seed time(3) से नहीं बल्कि arc4random(3) से बनाई जाती है
• Linux(glibc·musl), FreeBSD, NetBSD, Mac OS X, OmniOS पर इसे पोर्ट किया जा सकता है, और GitHub CI x86_64, aarch64, s390x architectures पर tests चलाता है, लेकिन OpenBSD के pledge और unveil जैसी security features के समकक्ष व्यवस्था करना porting की मुख्य सीमा है

[GN⁺]

Hacker News टिप्पणियाँ

• अगर रिमोट सर्वर source या target है, तो client fork(2) से child बनाता है, ssh(1) के जरिए remote host पर server openrsync शुरू करता है, और फिर client तथा server socketpair(2) pipe से communicate करते हैं — यह विवरण असल में कैसे काम करता है, यह थोड़ा अस्पष्ट है
  शायद मतलब यह है कि fork किया गया child socket pair के जरिए parent को connection सौंप देता है, या standard input/output को socket pair “pipe” से जोड़कर फिर ssh को exec करता है
  लेकिन यह कुछ ऐसा है जैसे यह कहना कि आप airport तक कार से जाते हैं, और फिर कहना कि आप ऑस्ट्रेलिया कार से जाते हैं

• openrsync की घोषणा के बाद से मैं इसे इधर-उधर इस्तेमाल करता आ रहा हूँ, और समय के साथ यह निश्चित रूप से बेहतर हुआ है। जिस दिन इसे पूरी तरह इस्तेमाल कर सकूँगा, उसका इंतज़ार है
  हालांकि, मेरे usage pattern में एक जगह यह Samba rsync से मेल नहीं खाता: openrsync --rsync-path=openrsync -av -e ssh /etc/services example.com:/tmp/services
  मेरी अपेक्षा थी कि remote पर /tmp/services file बनेगी, लेकिन वास्तव में यह /tmp/services/services बनाता है
  -av -e ssh /path/to/src/ example.com:/path/to/dst/ जैसी सामान्य directory mirroring Samba rsync की तरह ही काम करती है

  • यह व्यवहार “सामान्य” rsync से भी मेल खाता दिखता है। केवल contents sync करने के लिए शायद services के बाद trailing slash चाहिए
    सुधार: असल में मेरा “सामान्य” rsync भी macOS का openrsync ही था
  • असली सवाल यह है कि target पर /tmp/services directory पहले से मौजूद थी या नहीं
    rsync की सबसे उलझाऊ चीज़ों में से एक directories और trailing slash का व्यवहार है
  • source पर trailing slash लगाने का मतलब directory के अंदर की चीज़ें copy करना है, और उसे छोड़ने का मतलब directory को ही copy करना। मेरी जानकारी में यह POSIX tools में काफ़ी standard व्यवहार है
  • rsync से अनगिनत सालों तक परेशान रहने के नाते मैं उस impulse को समझता हूँ, लेकिन दूसरा services बनाना काफ़ी ज़्यादा समझदारी भरा लगता है और ज़्यादा सुरक्षित default भी है
    अगर rsync के default को कम पागलपन वाली दिशा में बदलने का मौका है, तो भविष्य की पीढ़ियों को इस भ्रम से बचाना चाहिए

• हाल में rsync codebase में vibe coding commits अचानक बढ़े हैं, और उनसे regressions भी आए हैं, तो यह बहुत अच्छी ख़बर है

  • rsync हमेशा मज़बूत रहा है, इसलिए मैं इस बात को नज़रअंदाज़ करना चाहता था, लेकिन upgrade के बाद मेरी backup scripts सचमुच टूट गईं
    GitHub के ताज़ा issues में हाल के 2 patches में आए कई bugs दर्ज हैं, और उसमें शायद बिना मतलब का एक राक्षसी लगभग 9 हज़ार lines का commit भी शामिल है
    LLM code लिखना तेज़ और आसान बना देते हैं, लेकिन असली अहम बात हमेशा सोचना ही रही है। समझ नहीं आता कि इतने पुराने और भरोसेमंद software को क्यों बिगाड़ा जा रहा है

• जिन्हें इस package की development background चाहिए, उनके लिए: यह project अभी RPKI validator के हिस्से के रूप में विकसित हो रहा है
  https://medium.com/@jobsnijders/a-proposal-for-a-new-rpki-va...

• Michael Stapelberg / Gokrazy टीम का एक Go implementation भी है: https://github.com/gokrazy/rsync

  • Gokrazy टीम कहना भी लगभग Michael Stapelberg ही कहना है : )
    https://github.com/gokrazy/rsync/graphs/contributors

• असली porting work का केंद्र OpenBSD के pledge(2) और unveil(2) से मिलने वाली security features को match करना है। ये system functionality के निर्णायक हिस्से हैं
  इनके बिना system public network से arbitrary data स्वीकार करेगा
  https://justine.lol/pledge/
  Alpine Linux edge में pledge दिखाई नहीं देता। क्या किसी ने Linux पर Pledge को test किया है? क्या मैं pledge के बिना openrsync इस्तेमाल करने के जोखिम को ग़लत समझ रहा हूँ, या यह लेख सिर्फ OpenBSD users के लिए है?

  • Linux में pledge, unveil या Capsicum जैसी functionality नहीं है। वहाँ cgroups, namespaces, और ऐसे बहुत से बिखरे हुए हिस्से हैं जिन्हें मिलाकर वैसा कुछ करना पड़ता है
    Linux एक-दो खास system calls और kernel paths के ज़रिए पूरा concept देने वाली isolation facility की तरह नहीं बना, बल्कि कई systems को बार-बार जोड़कर और उन्हें एक-दूसरे के साथ compose करके sandboxing या capability restriction तैयार करने की शैली में विकसित हुआ है
    आजकल Linux तरफ़ Landlock जैसी नई functionality भी दिखती है, लेकिन शायद वह भी बिल्कुल नया बनाने के बजाय Linux के मौजूदा building blocks पर ही टिकी होगी
    “गड़बड़” से शायद मतलब यह है कि चीज़ें जगह-जगह बिखरी हैं। Lock down करने के बहुत तरीके हैं, और कौन-सा सबसे अच्छा है यह चुनने के लिए हर subsystem में गहराई से उतरना पड़ता है। यह 1–2 simple system calls के इस्तेमाल से काफ़ी अलग है
  • जिस हिस्से को quote किया गया है, उसके ऊपर लिखा है: “officially supported operating system सिर्फ OpenBSD है, क्योंकि इसमें काफ़ी security features हैं”
    और नीचे लिखा है: “FreeBSD के Capsicum से शायद यह संभव हो, लेकिन Linux की security facilities बिखरी हुई हैं और उसे सही तरह secure करने के लिए विशेषज्ञ की ज़रूरत होगी”
    यानी portable होने का मतलब यह है कि यह compile होकर run हो जाता है, न कि यह कि इसमें वही security features भी हों
    अच्छा होता अगर pledge/unveil Linux upstream में आ जाते, लेकिन ऐसी उम्मीद नहीं है
  • वह quote इतना ज़्यादा सरलीकृत है कि लगभग पूरी तरह ग़लत लगता है
    “इन features के बिना system public network से arbitrary data स्वीकार करेगा” — इसके उलट pledge और unveil यह तय नहीं करते कि arbitrary data लिया जाएगा या नहीं। वे यह सीमित करते हैं कि किसी vulnerability से compromise हुए process क्या-क्या कर सकते हैं
    Security section में यह बात ठीक से समझाई गई है, इसलिए पता नहीं वह wording कहाँ से आई

• यह वही version है जो macOS 15.0 से इस्तेमाल हो रहा है

  • क्या यह 15.0 था? मुझे याद है कि यह 15.x series की किसी minor release में आया था, और तब कुछ scripts बिना स्पष्ट वजह के टूट गई थीं
    सुधार: मज़ेदार बात यह है कि इसे 15.0 में शामिल तो किया गया था, लेकिन backward compatibility हटाने वाला breaking change शायद 15.4 तक रोके रखा गया। https://apple.stackexchange.com/a/479297

• चूँकि यह हाल का rsync protocol support नहीं करता, इसमें 64-bit timestamps का support नहीं है, और इसलिए नए filesystems पर metadata को वास्तव में sync नहीं किया जा सकता

• नाम ऐसा क्यों है, यह सोच रहा हूँ। Openrsync सुनने में किसी closed-source program के open-source alternative जैसा लगता है
  लेकिन मूल Rsync भी GPL के तहत नहीं है क्या? क्या सिर्फ़ ज़्यादा आसान license होने की वजह से इसे “ज़्यादा open” कहा जा रहा है?

  • OpenBSD वाले लोग शायद यह मानेंगे कि derived works पर भी GPL लागू करने की शर्त के कारण GPL कम open है
  • OpenBSD से जुड़े कई projects open से शुरू होते हैं, जैसे openssh, openbgpd, openntpd, opensmtpd