나는 systemd이것이 데비안이 가고 있는 방향인 것처럼 보이기 때문에 적응하려고 노력하고 있습니다.
chroot네트워크를 사용하는 대신 하드웨어에서 Xorg를 실행하고 싶습니다 (그런 것 같다systemd호스트 시스템에 X 서버를 설치하고 싶지 않기 때문에 컨테이너에서 이 작업을 수행하는 정식 방법입니다 . 나는 호스트가 간소화되고 유지 관리가 적은 운영 체제가 되기를 원합니다.
이 내 꺼야이해하다따라서 가상화는 systemd-nspawn하드웨어 /dev에 대한 액세스를 허용하지 않습니다.
표준을 실행하는 것은 chroot실제로 꽤 잘 작동하는 것 같지만, 이에 미묘한 문제가 있는지는 확실하지 않습니다.
하드웨어에 직접 액세스할 수 있는 게스트 외에도시스템 시스템에서 "실제" chroot를 실행하는 것은 나쁜 생각입니다.? 그렇다면 어떤 문제가 발생할까요?
그 경우예systemd-nspawn나쁜 습관입니다. "안전하지 않음" 플래그와 같이 이를 수행할 수 있는 방법이 있습니까 ? 페이지에서는 찾을 수 없지만 man,이 페이지, 플래그가 있습니다 --share-system. 이것은 나에게 작동하지 않습니다.
답변1
nspawnsystemd 개발자는 실제 하드웨어에 대한 액세스를 허용하는 것을 매우 반대합니다 .페틀린설명하다:
글쎄, 우리는 컨테이너가 실제로 가상화된 환경에 액세스하는 데만 사용된다고 믿습니다. 즉, /dev는 대부분 비어 있어야 하며(모듈로 /dev/null, /dev/random 등) 컨테이너는 실제로 물리적 환경에 액세스해서는 안 됩니다. 하드웨어. 물론 이것은 컨테이너 내부에서 X 서버를 실행하는 것을 허용하지 않습니다.
다른 컨테이너 솔루션은 호스트에서 컨테이너로의 하드웨어 전달을 지원하지만 nspawn과 같은 간단한 도구에는 초점이 약간 맞지 않으며 그대로 유지되어야 한다고 생각합니다.
Arch Linux의 "표준" 설치는 systemd를 기반으로 하며위키피디아chroot전통이 나쁘다는 말은 없습니다 . Traditional이 비시스템의 요구 사항을 chroot충족한다고 가정하면 systemd시스템에서는 문제가 없을 것입니다 systemd. 경우에 따라 추가 "가상화"가 nspawn도움이 될 수도 있지만 제한적인 경우도 있습니다.