Openrsync - OpenBSD ekibinin rsync uygulaması

 (github.com/kristapsdz)
1 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • openrsync, rsync'in BSD (ISC) lisanslı bir uygulamasıdır ve şu anda OpenBSD base'e birleştirilmiştir
  • Güncel rsync ile uyumludur ve testlerde rsync 3.1.3 kullanılır, ancak protokol 27'yi destekliyorsa çalışabilir
  • rsync'in tüm komut satırı argümanlarını değil, yalnızca bazı argümanlarını kabul ettiği için openrsync ve rsync birlikte kullanılırken her iki tarafın da desteklediği bayraklar kullanılmalıdır
  • Resmî olarak desteklenen işletim sistemi OpenBSD'dir; ayrıca diğer UNIX sistemlerinde de derlenip çalıştırılabilmesi için taşınabilirlik amaçlı glue kodu içerir
  • Standart belgeler kılavuz sayfalarıdır; protokol ayrıntıları rsync(5) ve rsyncd(5), yardımcı program belgeleri ise openrsync(1) içinde yer alır
  • Proje, OpenBSD için rpki-client(1)'ın bir parçası olarak yazıldı ve NetNod, IIS.SE, SUNET, 6connect tarafından finanse edildi
  • Kurulum, genel UNIX sistemlerinde ./configure, make, make install ile yapılır ve mevcut rsync kurulumu ile çakışmaz
  • rsync algoritması sender ve receiver olarak ikiye ayrılır; sender kaynak dosya listesini ve meta verileri oluşturur, her iki taraf da dosya adlarını alfabetik olarak sıralayarak girdilere konuma göre başvurur
  • Genel dosya senkronizasyonunda dosya boyutu ve değiştirilme zamanı aynıysa atlanır; farklıysa sabit boyutlu bloklar için hızlı Adler-32 benzeri 4 baytlık hash ve yavaş MD4 16 baytlık hash kullanılarak değişen veri yeniden oluşturulur
  • Blok boyutu varsayılan olarak toplam dosya boyutunun karekökünün yuvarlanmış hâlidir; asgari boyut 700 B'dir ve karekök sonucu bilinmeyen bir nedenle 8'in katına yuvarlanır
  • Oturum, kullanıcının çalıştırdığı istemci ile uzakta çalışan sunucu sürecine ayrılır; sunucu ssh(1) üzerinden ihtiyaç halinde başlatılabilir veya sürekli çalışan bir ağ daemon'u olarak işleyebilir
  • rsync'te generator receiver'ın yanında ayrı bir süreç olarak çalışırken, openrsync generator ile receiver'ı tek bir süreçte birleştirir ve okuma-yazma isteklerine bir event loop ile yanıt verir
  • Güvenlik açısından OpenBSD'nin pledge(2) özelliğiyle çalışma moduna göre sistem işlemleri sınırlandırılır ve unveil(2) ile yalnızca hedef dizin altındaki dosya sistemi erişimine izin verilir
  • Sunucu modunda MD4 hash seed'i time(3) yerine arc4random(3) ile üretilir
  • Linux (glibc·musl), FreeBSD, NetBSD, Mac OS X ve OmniOS üzerinde taşınabilir durumdadır; GitHub CI, x86_64, aarch64, s390x mimarilerinde test yapar, ancak OpenBSD'nin pledge ve unveil özelliklerine denk güvenlik işlevlerini sağlamak taşınabilirliğin temel kısıtıdır

İlgili okumalar

1 yorum

 
GN⁺ 4 시간 전
Hacker News yorumları

  • Uzak sunucu kaynak ya da hedef olduğunda istemcinin fork(2) ile bir alt süreç oluşturup ssh(1) üzerinden uzak hostta sunucu openrsync'i başlattığı, ardından istemci ile sunucunun socketpair(2) borusu üzerinden iletişim kurduğu açıklaması kulağa muğlak geliyor
    Muhtemelen çatallanan alt süreç ya soket çiftini ebeveyne devrediyor ya da standart giriş/çıkışı soket çifti “borusuna” bağlayıp ardından sshyi exec ediyor demek istiyor
    Ama bu, havaalanına arabayla gittiğini söylemek yerine Avustralya'ya arabayla gidiyorum demeye benziyor

  • openrsync duyurulduğundan beri onu orada burada kullanıyorum ve zamanla kesinlikle daha iyi hale geldi. Tamamen kullanabilir duruma gelmesini sabırsızlıkla bekliyorum
    Yine de benim kullanım düzenimde Samba rsync ile uyuşmayan bir nokta var: openrsync --rsync-path=openrsync -av -e ssh /etc/services example.com:/tmp/services
    Beklediğim davranış uzakta /tmp/services dosyasının oluşmasıydı, ama gerçekte /tmp/services/services oluşturuyor
    -av -e ssh /path/to/src/ example.com:/path/to/dst/ gibi tipik dizin yansılama işleri Samba rsync ile aynı çalışıyor

    • Bu davranış “normal” rsync ile de uyumlu görünüyor. Yalnızca içeriği eşitlemek için services sonuna bir sondaki eğik çizgi gerekebilir
      Düzeltme: Aslında benim “normal” rsyncim de macOS'taki openrsyncmiş
    • Belirleyici olan, hedefte zaten /tmp/services dizininin var olup olmadığıdır
      rsyncin en kafa karıştırıcı yanlarından biri dizinler ve sondaki eğik çizgiyi ele alış biçimi
    • Kaynağa sondaki eğik çizgiyi eklersen dizinin içinden kopyalar, koymazsan dizinin kendisini kopyalar. Bildiğim kadarıyla bu, genel olarak POSIX araçlarında oldukça standart bir davranış
    • rsync tarafından sayısız yıl boyunca canı yakılmış biri olarak bu dürtüyü anlıyorum, ama ikinci servicesi oluşturmak çok daha mantıklı ve daha güvenli bir varsayılan gibi geliyor
      rsyncin varsayılanlarını daha az çılgın bir yöne çevirme fırsatı varsa, gelecek nesilleri bu kafa karışıklığından kurtarmalıyız

  • Son dönemde rsync kod tabanında vibe coding commitlerinin birden artması ve bunun getirdiği gerilemeler düşünülünce bu çok iyi haber

    • rsync her zaman sağlamdı, o yüzden bu sözü önce görmezden gelmek istedim, ama yükseltmeden sonra yedekleme betiklerim gerçekten bozuldu
      GitHub'daki güncel issue'larda son 2 yamada giren birçok bug listelenmiş; buna muhtemelen pek de anlamlı olmayan canavar gibi bir yaklaşık 9 bin satırlık commit de dahil
      LLM'ler kod yazmayı daha hızlı ve kolay hale getiriyor, ama asıl önemli olan her zaman düşünmekti. Bu kadar eski ve güvenilir bir yazılımı neden bozduklarını anlamıyorum

  • Bu paketin neden geliştirildiğine dair arka plana ihtiyaç duyanlar için: bu proje şu anda RPKI doğrulayıcısının bir parçası olarak geliştiriliyor
    https://medium.com/@jobsnijders/a-proposal-for-a-new-rpki-va...

  • Michael Stapelberg / Gokrazy ekibinin bir Go uygulaması da var: https://github.com/gokrazy/rsync

  • Asıl portlama işinin püf noktası, OpenBSD'nin pledge(2) ve unveil(2) ile sunduğu güvenlik özelliklerini karşılayabilmek. Bunlar sistemin işlevinde kritik öneme sahip
    Bu özellikler olmadan sistem herkese açık ağdan rastgele verileri kabul eder
    https://justine.lol/pledge/
    Alpine Linux edge'de pledge görünmüyor. Linux'ta Pledge'i test eden oldu mu? pledge olmadan openrsync kullanmanın riskini ben mi yanlış anlıyorum, yoksa bu yazı yalnızca OpenBSD kullanıcıları için mi?

    • Linux'ta pledge, unveil ya da Capsicum benzeri bir şey yok. Bunun yerine cgroups, namespace'ler ve benzer işleri yapmak için bir araya getirmeniz gereken çeşitli parçalar var
      Linux, belirli sistem çağrıları ve kernel yolları üzerinden bütünlüklü bir yalıtım özelliği sunmaktan çok, tekrar tekrar eklenen ve birleştirilen farklı sistemlerle sandboxing ya da yetenek kısıtlaması kurulan bir yapıda gelişti
      Bu günlerde Linux tarafında Landlock gibi yeni özellikler de var gibi görünüyor, ama muhtemelen tamamen sıfırdan tasarlanmaktan ziyade mevcut Linux yapıtaşlarının üzerine kuruludur
      “Dağınık” denmesinin nedeni muhtemelen her şeyin oraya buraya dağılmış olması. Kilitlemenin çok fazla yolu var ve hangisinin en iyisi olduğuna karar vermek için her alt sistemi derinlemesine incelemek gerekiyor. Bu da sadece 1-2 basit sistem çağrısı kullanmaya kıyasla büyük fark yaratıyor
    • Alıntıladığın kısmın üstünde şöyle yazıyor: “Tek resmi olarak desteklenen işletim sistemi OpenBSD'dir, çünkü önemli güvenlik özelliklerine sahiptir”
      Altında da şöyle deniyor: “FreeBSD'nin Capsicum'u ile mümkün olabilir, ancak Linux'un güvenlik tesisatı dağınık ve düzgünce güvenli hale getirmek için bir uzmanın eli gerekir”
      Yani taşınabilir olması, aynı güvenlik özelliklerine sahip olduğu değil, derlenip çalıştığı anlamına geliyor
      Linux ana akışına pledge/unveil gelmesi güzel olurdu ama pek umut etmiyorum
    • O alıntı o kadar aşırı basitleştirilmiş ki neredeyse tamamen yanlış görünüyor
      “Bu özellikler olmadan sistem herkese açık ağdan rastgele verileri kabul eder” ifadesinin aksine, pledge ya da unveil rastgele veri kabul edilip edilmediğini değiştirmez. Bunlar güvenlik açığı istismar edilmiş bir sürecin neler yapabileceğini sınırlar
      Security bölümünde bu düzgünce açıklanmış; o ifadenin nereden geldiğini bilmiyorum

  • Bu sürüm macOS 15.0'dan beri kullanılan sürüm

    • 15.0 muydu? 15.x serisinin küçük sürümlerinden birinde geldiğini hatırlıyorum ve bazı betiklerin nedensizce bozulduğunu da anımsıyorum
      Düzeltme: Komik olan şu ki 15.0'a dahil etmişler ama geriye uyumluluğu bozan kırıcı değişikliği 15.4'e kadar saklamış gibiler. https://apple.stackexchange.com/a/479297

  • Son rsync protokolünü desteklemediği için 64 bit zaman damgası desteği yok; bu yüzden yeni dosya sistemlerinde meta verileri fiilen eşitleyemiyor

  • Adının neden böyle olduğunu merak ediyorum. Openrsync kulağa kapalı kaynak bir programın açık kaynak alternatifi gibi geliyor
    Ama orijinal Rsync de GPL değil mi? Yoksa sadece daha rahat bir lisansa sahip olduğu için mi “daha açık” deniyor?

    • OpenBSD tarafındaki insanlar, türev çalışmalara da GPL uygulama zorunluluğu yüzünden GPL'nin daha az açık olduğunu düşünecektir
    • OpenBSD ile yakın ilişkili projeler arasında open ile başlayan çok şey var. openssh, openbgpd, openntpd, opensmtpd gibi