# Openrsync - OpenBSD 팀의 rsync 구현 > Clean Markdown view of GeekNews topic #30045. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=30045](https://news.hada.io/topic?id=30045) - GeekNews Markdown: [https://news.hada.io/topic/30045.md](https://news.hada.io/topic/30045.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-05-31T18:35:26+09:00 - Updated: 2026-05-31T18:35:26+09:00 - Original source: [github.com/kristapsdz](https://github.com/kristapsdz/openrsync) - Points: 1 - Comments: 1 ## Topic Body - **openrsync**는 [rsync](https://rsync.samba.org/)를 BSD(ISC) 라이선스로 구현한 시스템이며, 현재 OpenBSD base에 병합되어 있음 - 최신 rsync와 호환되며 테스트에는 **rsync 3.1.3**이 사용되지만, 프로토콜 27을 지원하면 동작 가능함 - rsync의 명령줄 인자 전체가 아니라 **일부 인자만** 받기 때문에, openrsync와 rsync를 함께 쓸 때는 양쪽에서 지원되는 플래그를 사용해야 함 - 공식 지원 운영체제는 **OpenBSD**이며, 다른 UNIX 시스템에서도 컴파일하고 실행할 수 있도록 이식성용 glue가 포함되어 있음 - 표준 문서는 매뉴얼 페이지이며, 프로토콜 세부사항은 [rsync(5)](https://github.com/kristapsdz/openrsync/blob/master/rsync.5)와 [rsyncd(5)](https://github.com/kristapsdz/openrsync/blob/master/rsyncd.5), 유틸리티 문서는 [openrsync(1)](https://github.com/kristapsdz/openrsync/blob/master/openrsync.1)에 있음 - 프로젝트는 OpenBSD용 [rpki-client(1)](https://medium.com/@jobsnijders/a-proposal-for-a-new-rpki-validator-openbsd-rpki-client-1-15b74e7a3f65)의 일부로 작성됐고, [NetNod](https://www.netnod.se), [IIS.SE](https://www.iis.se), [SUNET](https://www.sunet.se), [6connect](https://www.6connect.com)가 자금을 지원함 - 설치는 일반 UNIX 시스템에서 `./configure`, `make`, `make install`로 수행하며, 기존 rsync 설치와 충돌하지 않음 - rsync 알고리듬은 **sender**와 **receiver**로 나뉘며, sender가 소스 파일 목록과 메타데이터를 만들고 양쪽이 파일명을 사전순으로 정렬해 위치 기반으로 항목을 참조함 - 일반 파일 동기화는 파일 크기와 수정 시간이 같으면 건너뛰고, 다르면 고정 크기 블록마다 빠른 Adler-32형 4바이트 해시와 느린 MD4 16바이트 해시를 사용해 변경 데이터를 재구성함 - 블록 크기는 전체 파일 크기의 제곱근을 반올림한 값이 기본이며, 최소 크기는 **700 B**이고 제곱근 결과는 알 수 없는 이유로 8의 배수로 올림 처리됨 - 세션은 사용자가 실행하는 클라이언트와 원격에서 실행되는 서버 프로세스로 나뉘며, 서버는 [ssh(1)](https://man.openbsd.org/ssh.1)로 온디맨드 실행되거나 지속 실행 네트워크 데몬으로 동작함 - rsync의 generator가 별도 프로세스로 receiver 옆에서 동작하는 것과 달리, openrsync는 **generator와 receiver를 한 프로세스**로 합치고 이벤트 루프로 읽기·쓰기 요청에 대응함 - 보안 측면에서 OpenBSD의 [pledge(2)](https://man.openbsd.org/pledge.2)로 실행 모드별 시스템 작업을 제한하고, [unveil(2)](https://man.openbsd.org/unveil.2)로 목적지 디렉터리 이하의 파일시스템 접근만 허용함 - 서버 모드에서 MD4 해시 시드는 [time(3)](https://man.openbsd.org/time.3)이 아니라 [arc4random(3)](https://man.openbsd.org/arc4random.3)으로 생성됨 - Linux(glibc·musl), FreeBSD, NetBSD, Mac OS X, OmniOS에서 이식 가능하며 GitHub CI가 x86_64, aarch64, s390x 아키텍처 테스트를 수행하지만, OpenBSD의 pledge와 unveil에 해당하는 보안 기능을 맞추는 일이 이식의 핵심 제약임 ## Comments ### Comment 58667 - Author: neo - Created: 2026-05-31T18:35:27+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48334854) - 원격 서버가 원본이나 대상이면 클라이언트가 `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]() - Gokrazy 팀이라고 해도 사실상 Michael Stapelberg임 : ) [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 사용자만을 위한 건가? - 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` 같은 식임