▲

Openrsync - OpenBSD 팀의 rsync 구현

 (github.com/kristapsdz)
1P by GN⁺ | ★ favorite | 댓글 1개
  • openrsync는 rsync를 BSD(ISC) 라이선스로 구현한 시스템이며, 현재 OpenBSD base에 병합되어 있음
  • 최신 rsync와 호환되며 테스트에는 rsync 3.1.3이 사용되지만, 프로토콜 27을 지원하면 동작 가능함
  • rsync의 명령줄 인자 전체가 아니라 일부 인자만 받기 때문에, openrsync와 rsync를 함께 쓸 때는 양쪽에서 지원되는 플래그를 사용해야 함
  • 공식 지원 운영체제는 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를 한 프로세스로 합치고 이벤트 루프로 읽기·쓰기 요청에 대응함
  • 보안 측면에서 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에 해당하는 보안 기능을 맞추는 일이 이식의 핵심 제약임

함께 보면 좋은 글 β

▲
GN⁺   [-]
Hacker News 의견들

  • 원격 서버가 원본이나 대상이면 클라이언트가 fork(2)로 자식을 만들고 ssh(1)를 통해 원격 호스트에서 서버 openrsync를 시작한 뒤, 클라이언트와 서버가 socketpair(2) 파이프로 통신한다는 설명은 어떻게 동작한다는 건지 애매함
    아마 포크된 자식이 소켓 쌍으로 부모에게 연결을 전달하거나, 표준입출력을 소켓 쌍 “파이프”에 연결한 뒤 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에서 가장 헷갈리는 부분 중 하나가 디렉터리와 후행 슬래시 처리 방식임
    • 원본에 후행 슬래시를 붙이면 디렉터리 안에서 복사하고, 생략하면 디렉터리 자체를 복사함. 알기로는 이건 POSIX 도구 전반에서 꽤 표준적인 동작임
    • rsync에게 셀 수 없이 오랜 세월 괴롭힘을 당한 입장이라 그 충동은 이해하지만, 두 번째 services를 만드는 편이 훨씬 말이 되고 더 안전한 기본값이라고 봄
      rsync 기본값을 덜 미친 방향으로 바꿀 기회가 있다면, 미래 세대를 이 혼란에서 구해야 함

  • 최근 rsync 코드베이스에 바이브 코딩 커밋이 갑자기 늘고, 그로 인한 회귀까지 생긴 걸 보면 이건 아주 좋은 소식임

    • rsync는 늘 견고했으니 이 말을 흘려들으려 했는데, 실제로 업그레이드 후 내 백업 스크립트가 깨졌음
      GitHub의 최신 이슈에는 최근 2개 패치에서 들어간 버그가 많이 정리되어 있고, 아마 별 의미도 없었을 괴물 같은 약 9천 줄 커밋도 포함되어 있음
      LLM은 코드 작성을 더 빠르고 쉽게 만들지만, 늘 중요한 건 생각하는 일이었음. 이렇게 오래되고 신뢰받던 소프트웨어를 왜 망가뜨리는지 모르겠음

  • 이 패키지 개발 배경이 필요한 사람을 위해 말하면, 이 프로젝트는 현재 RPKI 검증기의 일부로 개발 중임
    https://medium.com/@jobsnijders/a-proposal-for-a-new-rpki-va...

  • Michael Stapelberg / Gokrazy 팀의 Go 구현도 있음: https://github.com/gokrazy/rsync

  • 실제 포팅 작업의 핵심은 OpenBSD의 pledge(2)와 unveil(2)이 제공하는 보안 기능을 맞추는 것임. 이들은 시스템 기능에 결정적인 요소임
    이 기능들이 없으면 시스템은 공개 네트워크에서 임의 데이터를 받아들이게 됨
    https://justine.lol/pledge/
    Alpine Linux edge에서는 pledge가 보이지 않음. Linux에서 Pledge를 테스트해 온 사람이 있나? pledge 없이 openrsync를 쓰는 위험을 내가 잘못 이해한 건가, 아니면 이 글은 OpenBSD 사용자만을 위한 건가?

    • Linux에는 pledge나 unveil, Capsicum 같은 기능이 없음. cgroups, 네임스페이스, 그리고 비슷한 일을 하려면 조합해야 하는 잡다한 것들이 있음
      Linux는 특정 시스템 호출과 커널 경로로 전체 개념을 제공하는 격리 기능이라기보다, 여러 시스템이 반복적으로 추가되고 서로 결합되면서 샌드박싱이나 기능 제한을 구성하는 방식으로 만들어졌음
      요즘 Linux 쪽에는 Landlock 같은 새 기능도 있는 듯하지만, 아마 완전히 새로 만들기보다는 기존 Linux 기본 요소 위에 쌓는 방식일 것 같음
      “엉망”이라는 말은 아마 여기저기 흩어져 있다는 뜻일 가능성이 큼. 잠그는 방법이 너무 많고, 어떤 게 최선인지 고르려면 각 하위 시스템을 깊이 파야 함. 단순한 시스템 호출 1~2개만 쓰는 것과 대비됨
    • 인용한 부분 위에는 이렇게 되어 있음: “공식 지원 운영체제는 OpenBSD뿐이며, 상당한 보안 기능을 갖고 있기 때문이다”
      그리고 아래에는 이렇게 되어 있음: “FreeBSD의 Capsicum으로는 가능할 것 같지만, Linux의 보안 시설은 엉망이고 제대로 보안화하려면 전문가의 손길이 필요하다”
      즉 포터블하다는 건 컴파일되고 실행된다는 의미이지, 같은 보안 기능을 가진다는 뜻은 아님
      Linux 업스트림에 pledge/unveil이 들어오면 좋겠지만 기대는 안 함
    • 그 인용문은 지나치게 단순화되어 거의 완전히 틀린 말처럼 보임
      “이 기능들이 없으면 시스템이 공개 네트워크에서 임의 데이터를 받아들인다”는 말과 달리, pledge나 unveil은 임의 데이터를 받아들이는지 여부를 바꾸지 않음. 이들은 취약점이 뚫린 프로세스가 할 수 있는 일을 제한함
      Security 섹션에서는 제대로 설명되어 있는데, 저 표현이 어디서 나온 건지 모르겠음

  • 이 버전은 macOS 15.0부터 사용된 버전임

    • 15.0이었나? 15.x 계열의 마이너 릴리스 중 하나에서 들어왔던 걸로 기억하고, 몇몇 스크립트가 알 수 없이 깨졌던 기억이 있음
      수정: 재미있게도 15.0에 포함하긴 했지만, 하위 호환성을 제거한 깨지는 변경은 15.4까지 아껴 둔 듯함. https://apple.stackexchange.com/a/479297

  • 최근 rsync 프로토콜을 지원하지 않아서 64비트 타임스탬프 지원이 없고, 그래서 새 파일시스템에서는 메타데이터를 실제로 동기화할 수 없음

  • 이름이 왜 그런지 궁금함. Openrsync라고 하면 닫힌 소스 프로그램의 오픈소스 대안처럼 느껴짐
    그런데 원래 Rsync도 GPL 아닌가? 단지 더 만만한 라이선스라서 “더 열려 있다”는 뜻인가?

    • OpenBSD 쪽 사람들은 파생 저작물에도 GPL을 적용해야 한다는 요구 때문에 GPL이 덜 열려 있다고 볼 것임
    • OpenBSD와 밀접한 프로젝트 중에는 open으로 시작하는 게 많음. openssh, openbgpd, openntpd, opensmtpd 같은 식임
답변달기