BSD 사용자의 Alpine Linux 도전기

 (rubenerd.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • BSD 데스크톱과 chroot, jail을 자주 쓰는 사용자가 Alpine Linux를 시험하며, 보안·단순성·자원 효율 중심 설계가 BSD 사용자에게 익숙하게 다가온다고 봄
  • 작은 크기와 제한된 의존성 덕분에 Alpine은 컨테이너 베이스 이미지뿐 아니라 임베디드 시스템, 라우터, 모바일 기기, 서버, 데스크톱까지 폭넓게 쓰임
  • 설치는 라이브 환경에서 setup-alpine을 실행해 키맵, 네트워크, 타임존, SSH, NTP 같은 기본 설정을 순서대로 잡는 방식임
  • 첫 부팅 후에는 OpenRC, musl, busybox 조합이 드러나며, /etc/rc.conf와 crond(8) 같은 요소가 BSD식 rc 경험과 맞닿아 있음
  • apk 패키지 관리, 저장소 설정, ZFS 설치 가능성까지 확인한 뒤 테스트와 서버용 주 Linux 배포판 후보로 진지하게 고려할 만큼 좋은 인상을 받음

BSD 사용자에게 익숙한 Alpine의 성격

  • Alpine Linux는 보안, 단순성, 자원 효율을 중시하는 파워 유저를 위한 독립·비상업·범용 Linux 배포판임
  • 사용자 영역 바이너리는 PIE(Position Independent Executables) 와 stack smashing protection으로 컴파일되어 특정 제로데이와 취약점 악용을 줄이는 데 초점을 둠
  • Natanael Copa가 2005년에 프로젝트의 기원을 논의했을 만큼 Alpine은 예상보다 오래된 프로젝트임
  • BSD 계열처럼 임베디드 시스템, 라우터, 모바일 기기뿐 아니라 일반 서버와 데스크톱에서도 쓰임
  • 작은 크기와 제한된 의존성 때문에 Linux 컨테이너의 베이스 이미지로 널리 쓰이며, chroot(8)에서 쉽게 실행하기 위한 alpine-chroot-install 같은 도구도 있음
    • NetBSD chroot(8)와 FreeBSD jail을 테스트와 배포에 많이 쓰는 사용자에게 특히 흥미로운 지점임

설치 경험

  • Alpine은 ARM, PPC64, x86, x86_64 등 여러 빌드를 제공함
  • Xen ISO 이미지를 VM에서 부팅했지만, Dom0를 DomU로 잘못 읽은 선택이었음
    • Dom0는 Xen 하이퍼바이저를 뜻하며 게스트가 아님
    • 그래도 표준 ISO처럼 부팅과 설치는 진행됨
  • 설치는 라이브 환경에서 root와 빈 비밀번호로 로그인한 뒤 setup-alpine을 실행하는 방식임
  • 설치 중에는 키맵, 네트워킹, 타임존, root 인증 같은 기본 항목을 차례로 설정함
  • 시작 단계에서 SSH 키를 주입할 수 있음
    • 이후 오케스트레이션 도구로 VM이나 서버 묶음을 배포할 때 유용함
    • OOB 콘솔을 제공하지 않는 호스팅 환경에서도 도움이 됨
  • SSH 서버와 NTP 클라이언트를 선택할 수 있어 OpenSSH와 openntpd를 고를 수 있었음
  • 설치 과정은 Xen에서 동작 중임을 올바르게 감지함
  • LVM 설정도 가능하지만, 이번에는 Alpine이 sys 파티션이라고 부르는 표준 구성을 선택함
    • 이 구성은 ext4를 사용함

첫 부팅 후 보이는 시스템 구성

  • 첫 부팅 후 dmesg(1)에서 시스템이 OpenRC를 사용 중임을 확인할 수 있음
  • OpenRC는 이식성, 작은 크기, 빠름, 효율, 투명성, 보안을 갖춘 init 시스템임
  • BSD식 rc 스크립트 작성에 익숙한 사용자에게 OpenRC는 매우 친숙함
    • /etc/rc.conf와 crond(8) 같은 요소가 BSD 사용자 경험과 맞닿아 있음
  • Devuan, Gentoo, Alpine처럼 OpenRC를 쓰는 Linux 배포판이 있어 Linux가 다시 재미있게 느껴짐
  • Alpine은 OpenRC와 함께 musl을 포함하고 busybox를 사용함
    • musl과 busybox는 GCC 및 GNU coreutils보다 제한적이지만, 베이스 시스템의 작은 크기와 공격 표면 축소에 기여함
  • llvm도 사용할 수 있음
  • MirBSD Korn shell도 패키지로 제공되며, 선호하는 대화형 셸 중 하나임

패키지 관리와 저장소

  • Alpine의 기본 패키지 관리자는 apk임
  • Linux에서 일반적인 방식처럼 apk는 베이스 시스템과 패키지를 구분하지 않고 함께 업데이트함
  • BSD에서처럼 권한 없는 복사본으로 실행할 수 있는지는 아직 확인하지 않음
  • pkgsrc도 사용할 수 있어 대안이 남아 있음
  • 저장소 설정은 /etc/apk/repositories에 있음
    • 설치기가 제공한 두 번째 URL의 주석을 해제하면 community 저장소를 활성화할 수 있음
    • Alpine에는 testing 저장소도 있으며, 자체 저장소도 추가 가능함
  • 사용법은 단순하지만 기존 습관 때문에 apk add 대신 apt install을 잘못 입력하기도 함
  • 공식 패키지 웹 인터페이스는 pkgs.alpinelinux.org에 있음
  • Alpine 저장소는 pkgs.org에서도 확인할 수 있음

ZFS와 서버용 후보로서의 평가

  • 몇 가지 패키지를 설치한 뒤 콘솔 전용 노트북에서 쓰던 “필수 도구” 구성을 갖출 수 있었음
  • 가장 놀라웠던 패키지 중 하나는 ZFS였음
    • 설치와 커널 모듈 로드는 두 명령으로 가능했음
# apk add zfs zfs-lts


# modprobe zfs
  • root 파일시스템을 ZFS로 구성하는 일은 더 복잡할 수 있음
  • 업그레이드 후 ZFS 구성이 어떻게 동작할지는 아직 확인하지 않음
  • 지금까지의 경험만으로도 테스트와 서버용 주 Linux 배포판으로 전환을 진지하게 고려할 만큼 인상이 좋음
  • htop(1)과 lsof(1)에서 알아볼 수 있는 소수의 프로세스만 보이는 점, OpenRC 사용, 단순해 보이는 패키지 관리, 쉬운 설정이 장점으로 꼽힘
  • 현대적이고 기능적인 “Occam’s Linux”가 있다면 Alpine이 그 모습에 가깝다고 평가함
  • busybox보다 더 많은 기능이 필요할 경우 uutils를 실행해볼 수 있겠지만, 서버에서는 필요성이 낮아 보임

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 보안 관점에서 보자면, 요즘 Linux 바이너리는 대부분 PIE로 컴파일됨
    Ubuntu의 임의 바이너리에 checksec를 돌려 보면 그런 속성이 나오고, pip install pwntools로 checksec를 설치할 수 있음
    반면 GLIBC는 내가 알기로 가장 강화된 힙 구현을 갖고 있고, 이중 해제와 다른 힙 공격에 대한 완화책도 더 많음
    그래서 그 측면에서는 Alpine이 musl을 써서 덜 안전하다고 볼 수 있지만, 작고 이해하기 쉬운 시스템이라는 점은 보안에서 진짜 장점임

    • “작고 이해하기 쉬운 시스템”이 왜 glibc에 유리한 근거가 되는지 잘 모르겠음. 오히려 반대 아닌가 싶음
    • Alpine 노드들에서 항상 모든 것에 checksec를 돌려 보는데, 프로세스들이 전부 이런 식으로 나옴. 출력 전체는 길어서 생략하지만 Alpine이 빌드한 것 중 이 플래그들이 빠진 건 본 적 없음
      COMMAND PID RELRO STACK CANARY NX/PaX PIE
      init 1 Full RELRO Canary found NX enabled PIE enabled
      [snip...]
      crond 422838 Full RELRO Canary found NX enabled PIE enabled
    • OpenBSD libc도 확인해 볼 만함
    • Linux 보안 관점에서는 누군가 시스템에서 코드를 조금이라도 실행할 수 있으면 이미 끝난 거라고 봄. Linux는 구멍투성이이고, Windows만큼 악성코드가 넘치지 않는 이유는 데스크톱에서 Linux를 쓰는 사람이 적어서 악성코드 제작자들이 크게 노리지 않기 때문임
      솔직히 현대 Windows와 macOS가 둘 다 더 나은 보안 아키텍처를 갖고 있다고 봄

  • 나도 BSD 쪽 사람이고, 우연히 이번 주에 bhyve 위 VM으로 Alpine을 처음 돌려 봄
    핵심은 BusyBox임. /bin과 /sbin 유틸리티가 각각 독립 바이너리일 필요가 없다면 사용자 공간이 아주 작고 부팅도 빠름. Tmux, zsh 정도 설치하니 대부분의 Unix 용도에는 충분했음
    최종 환경까지 가려면 apk 설치를 꽤 많이 하게 됐지만, 전체적으로 오랜만에 겪은 최고의 Linux 경험이었음. ZFS가 기본으로 들어가 있고, bhyve의 ZFS 기반 실행에 맞춘 virtio 연결이 더 명시적이면 좋겠음

    • FreeBSD를 20년 넘게 쓰고 배포해 왔는데, GNU/Linux 박스에 접속하는 건 솔직히 꺼려짐. 변형과 불일치가 너무 많아서 시스템이 엉망처럼 느껴짐. Windows 서버에 접속하는 쪽이 오히려 더 “말이 된다”고 느껴질 정도임
      그래도 제정신인 Linux 배포판이 있을지도 모른다니 반갑고, Linux 박스가 필요해지면 한번 써 보겠음. 다만 그런 일이 꽤 드묾
    • ZFS가 어느 정도로 “기본 내장”되길 바라는지 궁금함. Alpine은 바이너리 ZFS 커널 모듈을 제공하는 몇 안 되는 배포판 중 하나라서 apk 명령 한 번이면 거의 설치됨
      Alpine 위키에는 루트 파일시스템을 ZFS로 설치하는 문서도 꽤 괜찮게 있음: https://wiki.alpinelinux.org/wiki/Root_on_ZFS_with_native_en...
    • ZFS는 Alpine에서 아주 잘 동작함. Alpine + ZFS가 몇 년째 내 기본 서버 구성임

  • BSD 사용자라면 Void Linux도 마음에 들 수 있음. NetBSD 개발자인 xtraeme가 만든 배포판이고, glibc와 musl 버전이 있으며 초기화 시스템으로 runit을 사용함
    xbps-src로 소스에서 패키지를 빌드할 수도 있음
    https://voidlinux.org/

    • Arch를 쓰다가 Arch와 느낌이 비슷한 비-SystemD 대안을 찾은 끝에 Void에 정착함. Alpine 대신 Void로 간 이유는 glibc 지원 덕분에 NVidia 드라이버를 쓸 수 있어서였음. 물론 “NVidia 야유”는 알고 있음
    • Void를 아주 마음에 들어 함. 큰 패키지 선택지와 systemd의 편의성 때문에 메인 시스템은 Arch지만, 친척과 내 장비 세 대에 Void를 설치해 봤고 훌륭했음
      다만 최소한의 수정만 한 xfce 설치만 써 봤다는 점은 주의해야 함. 복잡한 다중 사용자 구성은 runit이 systemd보다 기본 포함 기능이 적어서 조금 더 번거로울 수 있음
    • 몇 년 전에는 voidlinux+musl에서 Rust를 쓸 때 문제가 있었음. 다행히 Void는 glibc로 쉽게 재설치할 수 있음
    • Chimera도 괜찮을 수 있음. 핵심 도구 사용자 공간이 대부분 FreeBSD 계열이라 BSD 사용자에게 꽤 친숙할 듯함
    • CRUX도 있음. Archlinux의 원조 격인 배포판임

  • BSD들이 자랑하는 man 페이지가 Alpine에는 기본 포함되지 않는다는 얘기가 나올 줄 알았음. 그게 여행용 노트북에서 Alpine을 안 쓰게 된 이유 중 하나였고, 지금은 OpenBSD를 쓰고 있음
    Alpine에서 패키지를 받을 때 문서가 항상 설치되게 하는 설정 옵션을 내가 놓친 걸까? 아니면 매번 -doc 패키지를 수동 설치하는 수밖에 없는 건가?

    • 문서를 항상 원한다면 docs 메타 패키지를 설치하면 됨. 이후 설치하는 항목에 맞는 *-doc 패키지를 끌어와 줌
    • 노트북에서 OpenBSD를 쓰면 하드웨어 지원은 어떤가?

  • 사람들이 왜 OpenRC 같은 걸 매력적으로 느끼는지 솔직히 전혀 모르겠음. 감시 기반 방식이면 뭐든 PID를 흘리고, PID 파일에 저장한 뒤, 3주 뒤에도 그 값이 여전히 실행한 데몬을 가리키길 바라는 방식보다 낫다고 봄
    게다가 어떤 경우에는 특정 프로세스 이름을 pgrep해서 서비스 관리 작업을 처리하기도 함. 모든 걸 기본으로 자동 재시작하면 안 된다는 생각에는 어느 정도 공감하지만, 이런 부류가 내세울 수 있는 장점은 사실상 그것뿐임
    또 결국 이런 것들은 syslog에 크게 의존하는데, 이건 80년대 기술 그 자체임. multilog나 svlogd 같은 도구가 여러 도구의 사건 순서를 한눈에 보는 중앙 뷰를 더 쉽게 제공하도록 개선될 수는 있겠지만, 모호한 범주로 로그를 묶고 누구나 아무 이름으로 아무 데나 로그를 남길 수 있게 하는 기능은 이상하게 느껴짐

    • 참고로 Alpine은 몇 년째 OpenRC 대체를 시도해 왔지만 적합한 대안을 찾지 못했음. 초기화 시스템에 독립적인 배포판이 되려는 시도도 있음
      https://mastodon.social/@ariadne@treehouse.systems/112044942...
      https://mastodon.social/@ariadne@treehouse.systems/112214386...
    • 그렇긴 하지만 주요 대안은 systemd인데, 그건 보안적이지 않은 방식으로 설계되어 새롭고 흥미로운 CVE가 계속 생길 여지를 열어 둠
      PID1 안에 너무 많은 일이 들어 있고, 메모리 안전하지 않은 언어로 작성되어 있음. 최소한의 PID1과 몇 개의 setuid 프로그램으로 나눌 수 없는 기술적 이유는 보이지 않음
      Docker 컨테이너 안에서 systemd를 돌릴 수 있게 된다는 점 말고는 떠오르지 않는데, Red Hat/IBM은 systemd-nspawn 같은 자사 컨테이너화 도구를 쓰길 선호해서 그걸 강하게 원치 않을 것 같음. 지금 구조로는 보안 관점에서 절대 타당해지기 어렵다고 봄

  • Alpine에는 재미있는 장점이 있음. Nix 사용자가 선언적 패키지 관리를 뽐낼 때 /etc/apk/world를 바로 편집하고 apk fix를 실행해서 Nix 없이도 어떻게 하는지 보여 줄 수 있음

    • 보통은 Gentoo 방식이 더 좋음. 수동 설치 패키지는 /var/lib/portage/world, 선택한 집합은 /var/lib/portage/world_sets, 집합 정의는 /etc/portage/sets/에 둘 수 있음
      이렇게 하면 패키지를 범주별로 나누고, 필요한 시스템에만 일부를 설치하며, 파일에 주석도 원하는 대로 추가할 수 있음. apk fix에 해당하는 것은 emerge -uDU @world && emerge -c인데 좀 더 거추장스럽긴 함
      Alpine도 apk add -t setname pkg1 pkg2 pkg3로 집합 비슷한 것을 만들 수 있고, 이러면 선택한 패키지에 의존하는 더미 패키지가 만들어짐. 나는 보통 Gentoo 느낌을 흉내 내려고 /etc/apk/sets/에 셸 스크립트를 만들지만 항상 같지는 않음
    • Nix가 내 시스템 flake를 평가하는 데 걸리는 시간 정도면 Alpine을 처음부터 다시 설치할 수 있음
    • 멋지긴 하지만 Nix/OS는 선언적 패키지 설치보다 훨씬 많은 일을 함

  • 예전에 Docker에서 Alpine을 돌릴 때 성능 관련 글들이 있었고, Debian/Ubuntu를 쓰라고 권하던 기억이 있음
    느린 Alpine 관련 글:
    https://pythonspeed.com/articles/alpine-docker-python/
    https://superuser.com/questions/1219609/why-is-the-alpine-do...
    Alpine에 우호적인 글:
    https://nickjanetakis.com/blog/benchmarking-debian-vs-alpine...
    이 얘기가 지금도 유효한지 궁금함

    • 구체적인 불만 중 상당 부분은 적어도 해결됐음. 첫 링크 맨 아래에서도 인정하듯 Alpine 호환 Python wheel이 이제 있고, DNS 문제도 꽤 전에 고쳐졌음
      그래도 성능 측면에서 벤치마크를 돌려 실제 숫자를 보는 건 흥미로울 듯함

  • musl은 아직도 pthread_attr_setaffinity_np를 지원하지 않지 않나? 그러면 어떤 소프트웨어는 실행할 수 없고, 가장 큰 예가 PyTorch임

    • 성능에 민감한 작업 부하가 그 성능 때문에 glibc에 의존한다면, 그 애플리케이션만 컨테이너에서 “그냥” 돌리면 될 것 같음
      많은 상황에서는 성능보다 단순성이나 보안이 더 중요한 관심사임

  • BSD와 Linux 사이에서 내가 찾은 적당한 중간 지점은 Slackware임. 당당하게 Unix스럽고 복잡하지 않으며, Slackbuilds를 통한 풍부한 자체 ports 트리도 있음

    • Slackware는 데스크톱 배포판과 경쟁하려고 했지만 제대로 전념하지 않으면서 방향을 잃었음
      예전에는 방해하지 않는 최소 배포판이라 좋아했고, 약간 더 기술적인 사람들을 지향한다고 봤음
      그런데 문제를 파고들 때 전체 설치를 하지 않았다는 이유로 커뮤니티가 적대적으로 굴곤 했음. 전체 설치가 권장 방식이라는 이유였고, 그렇게 하지 않으면 samba가 없어서 mplayer가 안 되는 식의 멍청한 의존성 문제도 생겼음
      Alpine은 모든 면에서 Slackware보다 개선됐다고 봄
    • Slackware를 쓰는 사람은 존중하지만, 의존성 관리 부재는 번거로워 보임

  • Alpine Linux는 사실 GNU/Linux가 아니었구나. 몰랐음
    그러면 BusyBox/Linux인가?

    • 그냥 Alpine Linux라고 부르면 됨. 내가 알기로 BusyBox는 RMS에게서 가끔 새어 나오는 자기 과시적 행태와는 관련이 없으니까 괜찮음
답변달기