3P by GN⁺ | ★ favorite | 댓글 3개
  • 실제 Nintendo Wii가 NetBSD 10.1과 lighttpd로 정적 Hugo 블로그를 서비스하며, 실험이 이어지는 동안 독자는 Wii에서 직접 제공된 페이지를 보고 있음
  • Wii용 NetBSD 포트는 오래된 취미성 포트와 달리 최신 안정 릴리스와 daily HEAD 빌드가 제공되어, 실제 운영 워크로드를 올려볼 만큼 유지보수 상태가 좋았음
  • 설치는 Wii 소프트모딩으로 Homebrew Channel을 띄우고, wii.img.gz를 SD 카드에 기록한 뒤 SSH, 정적 네트워크, pkgin, lighttpd를 구성하는 흐름임
  • Wii의 PowerPC 750 계열 단일 코어 CPU는 정적 HTTP를 처리할 수 있지만, 현대적 TLS 암호화 요청을 병렬로 많이 처리하기 어려워 Caddy가 앞단에서 TLS 종료와 ACME 인증서 관리를 맡음
  • 재부팅 후 Wiimote와 센서바가 필요해지는 제약이 있었지만, 유휴 전력 약 18W, 월 전력 사용량 약 13.2kWh 수준이라 장난감 같은 실험이 실제 인프라 학습 환경이 됨

Wii에서 실제 블로그를 서비스하는 실험

  • 실험이 진행되는 동안 실제 Nintendo Wii가 이 블로그를 제공함
  • Wii의 시스템 부하는 live(-ish) status page에서 확인할 수 있음
  • 출발점은 범용 운영체제를 범용 목적이 아닌 하드웨어에서 실행해 보는 데 대한 관심임
  • 과거에도 PS3의 Yellow Dog Linux, PS2 Linux, Dreamcast Linux, PSPLinux 같은 사례가 있었음
  • 다만 PSP Linux 커널 이미지는 2008년에 마지막으로 빌드됐고, Dreamcast Linux는 2001년에 빌드된 2.4.5 커널을 사용해 장기 운영 워크로드에는 맞지 않았음

NetBSD Wii 포트가 실험을 가능하게 함

  • NetBSD 웹사이트의 설치 미디어 섹션에는 Wii가 Raspberry Pi, 일반 x86 머신 같은 1급 대상과 함께 표시됨
  • Wii용 NetBSD 포트는 2024년 12월의 NetBSD 10.1 최신 안정 릴리스로 연결됨
  • daily HEAD builds도 Wii용으로 구성됨
  • 유지보수 상태가 살아 있었기 때문에 실제 운영 워크로드를 Wii에 배포하는 실험이 가능했고, 그 워크로드가 이 블로그임

하드웨어와 성능 조건

  • 실험용 Wii는 EMF Camp 2024 Swap Shop에서 구한 기기임
  • Wii의 단일 코어 Broadway CPU는 IBM PowerPC 750 계열의 연장선에 있음
    • 이 계열은 1998년 Apple Bondi Blue iMac까지 거슬러 올라감
    • 상용 동급 칩인 PowerPC 750CL은 최대 TDP가 9.8W이며, Wii에 들어간 버전보다 클럭이 약 33% 높음
  • 단일 코어, 1990년대 후반 아키텍처 기반, 10W 미만 TDP라는 조건 때문에 계산 성능은 제한적임
  • PowerPC 750 계열은 우주·위성 분야에서도 쓰이며, 방사선 강화 버전인 RAD750이 존재함
    • NASA 자료에서 PowerPC 750 사용 사례를 확인할 수 있음
    • Mars Curiosity)와 Perseverance) 로버에도 관련 칩 사용 사례가 있음

Wii 소프트모딩과 NetBSD 설치

  • Wii에서 서명되지 않은 코드를 실행하기 위해 Wilbrand exploit을 사용함
  • Wilbrand는 SD 카드로 Wii Message Board의 메시지를 저장·불러오는 기능을 이용해 서명되지 않은 코드 실행을 가능하게 함
  • 이 과정을 통해 HackMii를 부팅하고 Homebrew Channel을 설치함
  • 작업에는 콘솔의 MAC 주소와 SD 카드에 올릴 파일 생성이 필요하며, 브라우저 기반 도구가 이 과정을 처리함
  • 큰 SDHC 카드로 Wilbrand를 실행할 때는 문제가 있었고, 1GB non-SDHC 카드에서 가장 잘 동작함
  • NetBSD용 SD 카드는 NetBSD 사이트에서 wii.img.gz 이미지를 내려받아 준비함
    • Wii는 SDXC 이상을 지원하지 않아 32GB로 제한됨
    • NetBSD는 Wilbrand보다 큰 카드에서 덜 민감하게 동작해, 빠르고 품질 좋은 32GB SDHC 카드가 선택됨
  • Raspberry Pi Imager를 사용하면 이미지 압축 해제, 기록, 검증을 함께 처리할 수 있음
  • NetBSD Wii 이미지는 Homebrew Channel에서 일반 홈브루 앱처럼 직접 부팅할 수 있는 메타데이터와 구조를 갖고 있음
  • Wii 포트의 주요 작성자로 보이는 NetBSD developer Jared McNeill에게 공로가 있음

초기 시스템 구성

  • NetBSD 부팅 후 USB 키보드는 정상 동작하지만, 원격 관리를 위해 SSH를 설정함
  • SSH 데몬은 기본으로 실행 중이며, root 비밀번호 설정과 sshd_configPermitRootLogin yes 추가가 필요함
  • 정적 네트워크 설정은 /etc/ifconfig.axe0 편집으로 구성함
  • 네트워크 어댑터는 공식 RVL-015 Wii LAN Adapter를 사용함
    • dmesg에는 ASIX Electronics AX88772 USB 2.0 10/100 Ethernet 컨트롤러로 표시됨
    • NetBSD 부팅 후에는 NetBSD 드라이버를 사용할 수 있으므로 일반 USB 어댑터도 이론상 동작할 것으로 예상됨

패키지 관리와 웹 서버 구성

  • NetBSD의 pkgin 패키지 관리자는 환경 변수를 설정한 뒤 pkg_add pkgin으로 설치함
  • 패키지 경로는 https://cdn.NetBSD.org/pub/pkgsrc/packages/NetBSD/evbppc/10.1/All/를 사용함
  • 설치한 패키지에는 bsdfetch, iperf3, lighttpd, nano, rsync가 포함됨
  • 웹 서버는 자원 제약 환경에 맞는 lighttpd를 선택함
  • lighttpd 예제 rc 스크립트를 /etc/rc.d로 복사하고, /etc/rc.conflighttpd=YES를 추가한 뒤 시작함
  • 기본 정적 콘텐츠 경로는 /srv/www/htdocs
  • 블로그는 Hugo로 빌드된 정적 페이지 모음이어서 rsync로 파일을 복사한 뒤 표준 HTTP로 바로 서비스할 수 있었음

TLS 부하와 Caddy 리버스 프록시

  • 장시간 부하 테스트 결과, PowerPC 750은 현대적 TLS로 암호화된 여러 페이지를 동시에 서비스할 때 부담을 보임
  • 자원 확보를 위해 NetBSD에서 기본 실행되는 일부 서비스를 비활성화함
    • devpubd, dhcpcd, inetd, mdnsd, postfix를 끔
    • /etc/mailer.conf에서 sendmail, mailq, newaliases/bin/true로 바꿔 관련 프로세스 실행을 막음
  • ntpd는 시스템 RAM의 15.6%를 사용해 비활성화함
  • 시간 동기화는 필요해 ntpdate time.cloudflare.com을 매시간 :42에 실행하도록 crontab에 추가함
  • 최종적으로 블로그의 TLS 종료는 Wii 앞단의 Caddy 인스턴스가 맡음
    • Caddy는 리버스 프록시로 동작하며 암호화와 ACME 인증서 관리를 처리함
    • Caddy에는 캐싱 옵션이 켜져 있지 않음
    • 모든 요청은 Wii가 직접 처리하며, 이 글의 이미지까지 포함하면 페이지 전체 로드는 거의 정확히 1MB임
  • Caddy 계층에서 알려진 스크래퍼 User-Agent 요청을 차단해 Wii로 전달되지 않게 함

상태 모니터링 구성

  • TLS 종료를 Caddy로 옮기면서 Caddy의 Prometheus exporter를 사용할 수 있게 됨
  • 이 데이터는 InfluxDB + Grafana 스택으로 가져와 사이트 부하를 모니터링함
  • Wii 자체에는 Prometheus exporter 같은 추가 프로세스를 직접 올리지 않음
  • 대신 간단한 셸 스크립트를 만들어 crontab에서 15분마다 실행하고, 시스템 상태를 웹 루트의 HTML 파일로 출력함
  • 상태 페이지에는 uname -a, uptime 같은 정보가 표시됨
  • 전체 상태 페이지는 blog.infected.systems/status에서 확인 가능함

운영 제약과 전력 사용량

  • 전체 구성은 예상보다 훨씬 잘 동작했고 설치도 쉬웠음
  • NetBSD를 재부팅하면 NetBSD 앱만 재시작되는 것이 아니라 Wii 콘솔 전체가 재부팅되어 Wii Menu로 돌아감
  • 커널 패치나 시스템 업그레이드 후에는 Wiimote와 센서바가 운영 인프라의 필수 구성요소가 됨
  • UPS 모니터링 기반 테스트에서 Wii는 유휴 상태일 때 홈랩 전체 사용량에 약 18W를 추가함
  • 계산상 월 전력 사용량은 약 13.2kWh임
  • 영국 전기요금 기준 월 약 £3.47로 계산되어, 일부 클라우드 제공자의 VPS보다 저렴함
  • 장기 주말 동안의 재미있는 실험이었고, 계속 잘 동작하면 한동안 유지할 계획임
  • 인위적 제약을 적용한 배포 환경에서 학습이 잘 된다는 이유로 이런 실험에 관심이 있음

2026년 2월 업데이트

댓글과 토론

안쓰는 안드로이드 폰에 debian 올려서 웹서버 굴리던 때가 기억나네요

왜 Caddy와 lighttpd를 동시에 쓰나 싶어서 의아했는데 static 파일만 Wii에서 처리하고 나머지는 다른 머신의 Caddy에서 처리하는 형태인가 보네요.

Hacker News 의견들
  • 모르는 사람을 위해 설명하면, "SSL Added and removed here!" 이미지는 2013년에 NSA에서 유출된 Google 데이터센터 간 비암호화 통신 다이어그램을 가리키는 밈임
    https://arstechnica.com/tech-policy/2013/10/new-docs-show-ns...

    • 예전에 일급기밀 취급 인가가 있고 정부 일을 하던 교수가 있었는데, 이 자료는 아직 기밀 해제된 적이 없어서 직접 언급할 수 없었음
      그런데 관련 주제를 다루는 수업에서 이 두 원이 같은 식으로 배치된 이미지를 보여줬고, 내 분반에서 그걸 알아챈 사람이 있었는지는 모르겠음
    • 미국 정부가 해저 잠수함 같은 걸 써서 미국 기업 통신망에 침투하고 미국인을 감시했다는 일이 2013년에 더 큰 논란이 아니었다는 게 지금 생각해도 꽤 이상함
    • :¬) 얼굴은 보안 관련 채널에서 커스텀 이모트로 쓰기 좋음
    • 급히 끄적인 게 분명한 다이어그램 아래에 top secret 라벨이 붙어 있는 게 너무 웃김
    • “SSL Added and removed here!”라니, 그리고 CloudFlare까지!
  • 상태 페이지를 보면서 제일 흥미로웠던 건 Wii에 RAM이 88MB뿐이었다는 점임. SoC 내장 24MB와 GDDR3 64MB로 나뉘어 있었음
    이 상황에서 ntpd가 시스템 메모리의 15%를 썼다면 약 13MB RAM을 쓴 셈인데, 오늘날 기준으로는 크지 않지만 그렇다고 작지도 않음. 시간 서버 수를 줄이면 꽤 나아질지 궁금함. 내 시스템에서는 Debian 풀에서 서버 9개 정도를 추적 중임
    당시에도 512MB였던 XBox 360과 비교하면, 이렇게 작은 칩에서 얼마나 많은 걸 뽑아냈는지 정말 놀라움
    https://blog.infected.systems/status/

    • 1995년에 쓰던 첫 NetBSD 머신들이 떠오름. 아마 RAM 4~8MB로 돌아갔을 텐데, 메일 서버와 직접 만든 웹메일 서버를 돌리고 여러 사용자가 로그인해서 MUD를 하거나 IRC에 붙어 있었음
  • NetBSD를 재부팅하면 NetBSD “앱”만이 아니라 콘솔 전체가 재부팅되어 Wii Menu로 돌아가는 문제는 Priiloader를 설치해서 완화할 수 있음
    Homebrew Channel이나 NetBSD .dol 파일로 자동 부팅하게 설정하면 됨

  • 이런 물건 너무 좋음. 예전에 내 블로그를 로봇청소기 위의 Docker 컨테이너에서 호스팅한 적이 있음
    청소기가 침대 밑으로 들어가서 Wi-Fi 신호를 잃을 때마다 가동 시간 알림이 울리기 시작해서, 결국 더 정상적인 호스트로 되돌렸음

    • 침대 근처에 Wi-Fi 확장기를 하나 뒀을 것 같음
    • 어떻게 해낸 건지 정말 더 알고 싶음
  • 24년보다 더 전에 봤던 프로젝트가 떠오름. 누군가 GBA용 웹서버를 만들었음
    당시에는 마법처럼 보였고, 업데이트를 보려고 그 사이트에 자주 들어갔던 기억이 아직도 남아 있음. 그래서 URL도 기억함
    다행히 Wayback Machine에 아직 남아 있음
    https://web.archive.org/web/20030204043536/http://fivemouse....

  • 예전 Wii 홈브루 경험상, 작은 SD 카드의 예상되는 신뢰성 문제는 익스플로잇 이후 일반 USB 메모리로 바꿔서 어느 정도 피할 수 있을 듯함
    포트는 USB 2.0뿐이지만 어차피 병목은 프로세서일 가능성이 큼

  • 참고로 Photo Booth 대신 QuickTime Player에서 “새 동영상 녹화”를 만들면 됨. 아마 영상 좌우 반전 문제도 해결될 것 같음

    • 아니면 OBS도 가능함
  • macOS Photo Booth로 캡처 카드를 쓰면 영상 피드의 좌우 반전을 끌 수 없다면, 그냥 OBS를 쓰는 게 좋음

    • Photo Booth를 쓴 것도 의외였음. iOS 기기를 녹화하듯이 QuickTime Player로 녹화했을 것 같음
  • 성능은 나쁘지 않음. 악명 높게 형편없었던 Wii의 Nintendo TCP 스택을 쓰지 않는 게 분명함

    • Nintendo의 네트워킹은 콘솔이 뭐든 이상하게 늘 별로임
    • 전반적으로 WFC 코드도 좀 오래됐고 그다지 안전하지 않음
      이건 두 가지 흥미로운 버그를 떠올리게 하는데, 둘을 함께 쓰면 Wii에서 DNS 설정만 바꿔도 WFC 게임, 요즘은 사실상 Mario Kart Wii를 다시 온라인으로 할 수 있게 됨
      첫째, 인증서의 특정 필드만 설정하면 유효하지 않은 인증서도 그냥 받아들임. 이 버그는 한국 출시 시점의 NWC 라이브러리에서는 고쳐졌지만, DWC에는 꽤 오래 남아 있었음
      이 버그가 게임 등이 PPC에서 쓰던 RVL SDK에도 있었고, signing/Trucha 버그와 같은 원인에서 비롯됐을 가능성이 있다고 봄. Trucha는 IOS 전용 익스플로잇이지만, 같은 코드가 DWC 네트워킹 라이브러리에도 쓰였거나 비슷한 검증 로직을 썼을 가능성이 있음. Mario Kart Wii가 IOS36과 연결되어 있고 DWC 코드는 IOS 일부가 아니므로, 같은 버그였거나 보안 정리 과정에서 함께 고쳐졌다는 추측이 듦
      아직 역공학으로 확인해보지는 않았지만, 더 최신 IOS와 라이브러리를 쓰는 한국판 Mario Kart Wii에서는 이게 동작하지 않는다는 점 때문에 같은 계열 버그였을 가능성이 커 보임. 수정 시점도 흥미로움
      둘째, 네트워킹 라이브러리에는 버퍼 오버런으로 인한 원격 코드 실행이 있음. 첫 메시지에 검사되지 않는 길이 값이 있고, DWC 라이브러리가 패킷 데이터를 그대로 memcpy함. 그래서 이런 버그를 고치는 패치셋이 중요함. 운영체제와 라이브러리가 게임에 포함되어 배포되고, 메모리 안에서가 아니면 업데이트할 수 없기 때문임
      결과적으로 필요한 건 개조하지 않은 Wii에서 DNS 설정을 지정된 DNS 서버로 바꾸고, Mario Kart Wii 같은 게임을 실행한 뒤 WFC를 여는 것뿐임
      그러면 게임이 WFC 서버에 대한 DNS 조회를 하고, 의도적으로 서드파티 서버로 연결되며, 특정 필드를 null 값으로 둔 잘못된 인증서 검증을 통과함. 이후 알려진 원격 코드 실행 취약점을 고치고 기존 WFC 도메인 대신 다른 도메인으로 URL을 돌리는 등 게임을 메모리에서 패치하는 익스플로잇 메시지를 받음
      결국 WFC가 완전히 종료된 지 11년 뒤에도 Wii 게임, 아마 Mario Kart Wii를 온라인으로 할 수 있게 되는 셈임 :)
      https://wiibrew.org/wiki/Signing_bug
      https://wiibrew.org/wiki/IOS36
  • 까다롭게 굴려는 건 아니지만, Caddy 인스턴스를 Wii로 옮기거나 제거하기 전까지는 블로그가 실제로 완전히 Wii에서 호스팅되는 건 아님

    • 작성자는 그냥 TLS를 꺼도 됐을 듯함. 이 상황에서는 충분히 합리적이고, 그러면 단서 없이 완전히 Wii 호스팅 웹사이트가 됐을 것임