우선, 이것은아니요보안상의 이유로 또는 프로덕션 환경에서 사용하기 위한 것입니다. VM(시간 및 리소스 오버헤드)이나 LXC(버전 요구 사항 및 불필요한 복잡성)를 사용하지 않고 상대적으로 낮은 사양의 워크스테이션에서 다른 구성 관리 시스템을 사용하고 싶기 때문입니다. Chroot는 상대적으로 안전하지 않지만 설치가 빠르고 쉽습니다.
어쨌든: chroot 환경과 가상 이더넷 인터페이스(eth0:1 등)가 있는 경우 chroot의 프로그램이 항상 가상 인터페이스를 사용하도록 어떻게 보장할 수 있습니까?
진정한 네트워크 격리는 필요하지 않습니다. 즉, chroot 내부에 실제 인터페이스가 표시되지 않습니다. 나는 chroot 프로그램이 호스트(또는 다른 chroot)와 다른 IP 주소에 응답하여 Puppet과 같은 서버/클라이언트 설정을 올바르게 사용할 수 있기를 원합니다.
호스트 시스템은 Debian Wheezy x64를 실행합니다.
어쩌면 내가 잘못된 방향으로 가고 있을지도 모릅니다. 내가 원하는 것은 여러 개의 chroot를 갖고 호스트 시스템의 호스트 이름을 통해 각 chroot에 액세스할 수 있는 것입니다. 그게 가능합니까?
답변1
Chroot는 여기서 도움이 되지 않습니다. 파일 이름에만 영향을 미치며 네트워크 및 기타 기능에는 영향을 미치지 않습니다.
최신 버전의 Linux는 다음을 통해 환경의 특정 측면을 점진적으로 가상화하는 방법을 제공합니다.네임스페이스. 전통적인 파일 이름 가상화(chroot 프로세스는 chroot 외부의 파일을 볼 수 없음) 외에도 chroot프로세스 ID를 가상화할 수도 있습니다(따라서 PID 네임스페이스 내부의 프로세스는 네임스페이스 외부의 프로세스에 신호를 보내거나 추적할 수 없습니다). , 사용자(따라서 사용자 네임스페이스 내부의 사용자 1234는 네임스페이스 외부의 사용자 1234와 독립적입니다) 등 당신은 관심이 있습니다네트워크 네임스페이스, 프로세스에는 자체 네트워크 인터페이스, IP 주소, 경로 등이 있습니다.
나는 독서를 추천한다Michael Kerrisk의 우수한 LWN 기사 시리즈, 최소한 소개와 기사가 있어야 합니다.네트워크 네임스페이스.
네트워크 네임스페이스는 커널 2.6.29(이전 버전에서 부분 구현 가능)부터 사용되었으므로 RHEL5/CentOS5를 제외한 모든 최신 배포판에서 작동합니다. 커널 3.8부터는 네트워크 네임스페이스를 사용자 네임스페이스와 결합하고 네임스페이스 외부의 루트 권한 없이 네임스페이스 내에서 네트워크 설정을 수행할 수도 있습니다. wheezy의 3.2와 같은 이전 커널에서는 먼저 호스트 시스템에 대한 루트 액세스가 필요합니다. 사용자 네임스페이스를 생성합니다. 사용자 도구는 커널 기능보다 느리게 등장하므로 현재 많은 시스템에는 커널 기능을 최대한 활용할 수 있는 모든 도구가 없습니다. 데비안 wheezy가 함께 제공됩니다unshare, 이는 네임스페이스를 생성하기에 충분하지만 셸 nsenter래퍼가 부족합니다.setns호스트의 네임스페이스 내에서 작동합니다(7월부터 불안정한 상태 진입).
바라보다Linux에서 하위 프로세스를 "오프라인"(외부 네트워크 없음)으로 실행하는 명령네트워크 네임스페이스를 만드는 간단한 예입니다.스캇 로우의 블로그더 자세한 튜토리얼이 있습니다.
답변2
답변: 상당히 광범위한 Google 검색을 통해 알 수 있는 한 chroot에 네트워크 네임스페이스가 부족하여 실제로 이것이 불가능합니다. 어떤 식으로든 chroot 환경에 자체 IP, 호스트 이름, FQDN 등을 할당할 수 없습니다.
Chroot는 개별 프로그램이나 데몬을 보호하는 데 유용합니다. 어떤 종류의 격리된 테스트 시스템을 만드는 데는 거의 쓸모가 없어 보입니다.