Rootless, Seamless, Stateless Linux Desktop

개발 환경은 모두 Docker Rootless 컨테이너에 집중돼 여러 기기를 틈새 없이 분리해 사용할 수 있는 환경을 만들었다.이 기초 위에서 겪은 과제를 총결하다.

개요

로컬 부팅 후 로컬 컨테이너에서 앱을 실행하고, SSH 연결부에서 부팅하면 원격 컨테이너에서 앱을 실행해 로컬에서 화면 전송을 한다.
bash

user@local:~$ vscode  # <--- vscodeをローカル実行
user@local:~$ ssh remote
user@remote:~$ vscode # <--- vscodeをリモートで実行してローカルに表示

관리하기 편리하도록 제작된 도구가 여기 있습니다.
https://github.com/ysuito/xsprash.git
vscode 외에도 자주 사용하는 응용 프로그램 Docker file이 추가되었습니다.

용례

브라우저는 무릎 위 컴퓨터에서 시작하고 개발 환경은 데스크톱에서 시작하며 부하 분산

AWS EC2 g4ad.2xlarge와 같은 GPU 인스턴스를 사용하여 무력한 PC에서 편안한 개발 환경 조성

각 프로젝트에 vscode 환경을 만들고 완전히 분리하여 인증 정보 등 유출 위험을 방지한다

자체 제작 원격 브라우저

로 로컬에서 화면 전송만 가능

호스트 OS를 더럽히고 싶지 않은 사람.사고 발생 시 사용자만 삭제하면 처리 가능

배경.

리눅스를 영원히 아름답게 만들고 싶지만 타락해서 오염되는 자신을 싫어한다.

NOPASSWD에서 sudo

사용

불필요한 가방을 설치하고 설치하는 것을 잊었다

HOME 밑에 수많은 숨겨진 파일이 생겨서 관리할 수 없음

빠르게 구축된 데스크톱이 있는데도 잠을 자면서 무릎 위 컴퓨터를 사용했다

CLI로 모두 유지하기 힘들어

하지만, 나는 자유롭고 싶다

거기서 Docker Rootless와 xpra를 사용하여 개인적인 이상적인 환경을 만들었습니다.
이 과정에서 특히 로틀러스 컨테이너를 이용할 때 다음과 같은 과제를 해설하고 싶다.

과제.

Rootless 컨테이너 내의 일반 사용자

호스트의 id,gid는 용기 내에서 /etc/subuid,/etc/subgid에 정의된 id 공간에 비칩니다./etc/subuid, /etc/subgid에서 다음과 같이 설정합니다.
/etc/subuid

hostuser:100000:65536

호스트
용기내
1000:1000
0:0
100999:100999
1000:1000
호스트의 docker가 사용자의 uid,gid를 실행하면 용기 안에서 루트: 루트 (0: 0) 에 비추게 됩니다.
컨테이너 내의 일반 사용자(1000:100)가 호스트에서100000(/etc/subuidの開始id) + 1000(コンテナ内でのuid) - 1(コンテナ内でのrootはホストのユーザidにマッピングされているので除外) = 100999.

저장 장치

bash

$docker run --rm -it -v /home/hostuser/test:/home/user ubuntu bash -c "useradd user && chown -R 1000:1000 /home/user && touch /home/user/root_create && su - user -c 'touch user_create && ls -lan' "
total 0
drwxr-xr-x 2 1000 1000 44 Jan  6 04:19 .
drwxr-xr-x 1    0    0 18 Jan  6 04:19 ..
-rw-r--r-- 1    0    0  0 Jan  6 04:19 root_create
-rw-rw-r-- 1 1000 1000  0 Jan  6 04:19 user_create

컨테이너 안에서 루트가 만든 파일은 0:0 일반 사용자가 만든 파일1000:1000이다.
그럼 호스트 쪽에서 어떻게 된 건지 확인해 보세요.
bash

$ ls -ln ~/test
total 0
-rw-r--r-- 1   1000   1000 0 Jan  6 13:19 root_create
-rw-rw-r-- 1 100999 100999 0 Jan  6 13:19 user_create

이렇게 0:0->1000:1000, 1000:1000->100999:100999가 비친다.
여기서 주의해야 할 것은 다음과 같은 두 가지다.

용기 내의 사용자 루트가 만든 파일은 호스트에서 1000:1000로 호스트 사용자가 삭제할 수 있다.

컨테이너 내 일반 사용자가 작성한 파일은 호스트에서 100999:100999 등으로 호스트 사용자가 삭제할 수 없습니다.

bash

$ rm ~/test/user_create
rm: cannot remove '/home/hostuser/test/user_create': Permission denied

이러면 곤란할 수도 있지만 컨테이너 안의 루트 사용자라면 삭제할 수 있습니다.
호스트 사용자에게 비치기 때문에 헷갈리지만 용기 안에서는 루트 사용자입니다.
bash

$ docker run --rm -it -v /home/hostuser/test:/home/user ubuntu bash -c "rm /home/user/user_create"
$ ls -ln ~/test
total 0
-rw-r--r-- 1 1000 1000 0 Jan  6 13:19 root_create

틈새 없는 환경을 만들 때 여러 호스트가 파일을 동기화할 때 이 소유권의 편차가 매우 큰 과제이다.
컨테이너 안의 루트 사용자를 사용하여 해결할 수 있다.syncthing 공식의 docker image 컨테이너 내의 실행 UID를 지정할 수 있으므로 아래와 같이 루트 실행을 통해 모든 파일을 균일하게 처리할 수 있습니다.
bash

docker run -p 127.0.0.1:8384:8384 -p 22000:22000/tcp -p 22000:22000/udp \
    -v /wherever/st-sync:/var/syncthing \
    --hostname=my-syncthing \
    -e PUID=0 -e PGUID=0 \
    syncthing/syncthing:latest

그러나 복제 대상 호스트에서 복제 파일의 소유권은 모두 복제 대상 호스트 사용자가 됩니다.
각 rootless 컨테이너를 시작할 때 HOME 디렉토리chown -R user:user가 작업 프롬프트입니다.

X Server

rootless에서는 rootfull 모드에서 화면을 공유하는 것보다 시간이 더 걸립니다.
위에서 말한 바와 같이 루트러스 용기 내의 일반 사용자의 ID는 호스트 사용자의 ID와 일치할 수 없습니다.
호스트 사용자와 용기 내의 일반 사용자의 편차 때문에 다음과 같은 처리가 필요합니다.

소켓 파일의 권한 변경

인증 설정

구체적으로 다음과 같다.
bash

chmod 777 /tmp/.X11-unix/X0
xhost +local:

이 설정을 통해 호스트 PC의 사용자라면 누구나 X Server에 액세스할 수 있으므로 보안이 악화됩니다.

pulseaudio

pulsseaudio의 플러그인 파일은 666입니다. 공유하기만 하면 됩니다.
인증용 쿠키 파일~/.config/pulse/cookie은 600이기 때문에 공유만 하면 읽을 수 없습니다.
용기가 시작될 때 루트 사용자가 변경 권한을 복사해서 해결합니다.

dbus

dbus의user용 플러그인 파일은 666 이며 공유만 하면 문제없습니다.
인증은 사용자가 다르기 때문에 직접 방문할 수 없습니다.호스트의 시스템 설정을 변경하여 처리할 수 있습니다.
생성/usr/share/dbus-1/session.d/session-local.conf/usr/share/dbus-1/session.d/session-local.conf

<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
  <auth>ANONYMOUS</auth>
  <allow_anonymous/>
</busconfig>

인산염을 다시 가동하세요.

로컬 및 원격 원활한 전환

xpra와 ssh config를 사용하여 틈새 없는 응용 전환을 실현합니다.
~/.ssh/config

Host dev-server
HostName       IP_ADDRESS
Port           22
User           USERNAME
IdentityFile   ~/.ssh/KEY
RequestTTY     force
RemoteCommand  xpra start :101 --bind-tcp=127.0.0.1:10001 --start="xhost +local:" & SHELL
PermitLocalCommand yes
LocalCommand   xpra attach tcp://127.0.0.1:10001/101 &
LocalForward   10001 127.0.0.1:10001

IP_ADDRESS, USERNAME, KEY, SHELL 섹션을 환경별로 변경하십시오.
위에서 말한 바와 같이 예전처럼 ssh 원격 연결을 통해 화면 전송에 사용할 서버와 클라이언트를 준비하고 케이스를 시작할 수 있다.
원격으로 프로그램을 시작하려면 ssh를 연결하고 명령을 입력하십시오.

아쉬운 점

ec2 실례에서android 모방기를 이동하려고 시도했지만 /dev/kvm 사용할 수 없기 때문에 사용할 수 없습니다

안전한 개발 환경을 만들고 싶지만 일부 자원에 대한 인증이 엄격하지 않기 때문에 앞으로 엄격하게 인증할 것이다.