Image Docker XWINDOW tiếng Hàn có thể truy cập qua RDP trên Windows
(github.com/lancard)Tôi đã tạo và công khai image Docker XWINDOW tiếng Hàn (wayland) dựa trên Debian 13 (Trixie) mới nhất.
Trên thực tế có rất nhiều người dùng Windows, và đôi khi bạn sẽ muốn chạy môi trường Linux X Window hỗ trợ tiếng Hàn bằng Docker để làm việc.
Vì vậy!
Tôi đã thử xây dựng một môi trường GUI tiếng Hàn dựa trên Debian có thể truy cập bằng Windows Remote Desktop.
Image này đã được cài sẵn các công cụ chính cần cho môi trường phát triển như Visual Studio Code, Chromium, Vim, Git, Node.js + npm, nên có thể dùng ngay làm môi trường dev. (Vì vậy dung lượng cũng hơi lớn)
Các đặc điểm chính gồm:
- Có thể kết nối bằng Windows Remote Desktop (RDP)
- Giữ lại dữ liệu và volume: nếu gắn
/home/(tên người dùng)với Docker volume thì dữ liệu có thể được lưu bền vững
Lưu ý:
Do chạy trong Docker nên VSCode và Chromium không sử dụng chế độ sandbox. Mong bạn lưu ý về bảo mật; còn tính năng âm thanh đã bị loại bỏ vì có nhiều xung đột và lỗi. Theo tôi thì đa số mọi người có lẽ vẫn nghe nhạc trên PC Windows nên tôi đã bỏ tính năng này.
Đây là một image đặc biệt hữu ích cho người dùng tiếng Hàn muốn nhanh chóng thiết lập môi trường phát triển.
Mã nguồn ở https://github.com/lancard/x11-korean, hãy tham khảo; nếu có tính năng bạn cần, cứ thoải mái gửi issue hoặc PR nhé!
25 bình luận
Trong vscode bên trong, có thể tạo tệp mới nhưng không thể sửa các tệp hiện có. Dù đã đổi các tệp hiện có sang
chmod 777. Có vẻ là vấn đề về quyền hoặc quyền sở hữu nhóm, nên tôi sẽ thử thêm vài cách nữa.Có vẻ như đã khắc phục được bằng cách chỉnh sửa tệp
shở entry point và đặtXWINDOW_USER_IDkhớp với ID của thư mục làm việc.set username
XWINDOW_USER="${XWINDOW_USER:-user}"
if ! id -u $XWINDOW_USER >/dev/null 2>&1; then
useradd -m -s /bin/bash $XWINDOW_USER
echo "user '$XWINDOW_USER' generated."
fi
Phần này được đổi thành
XWINDOW_USER="${XWINDOW_USER:-user}"
XWINDOW_USER_ID="${XWINDOW_USER_ID:-1000}" # mặc định là 1000
if ! id -u $XWINDOW_USER >/dev/null 2>&1; then
useradd -m -s /bin/bash -u $XWINDOW_USER_ID $XWINDOW_USER
echo "user '$XWINDOW_USER' generated with UID $XWINDOW_USER_ID."
else
echo "user '$XWINDOW_USER' already exists."
fi
và tôi đã đặt USER_ID trùng với ID tài khoản của máy host.
Có thể dùng nó thay cho WSL không?
Vâng, dùng được. Cá nhân tôi không thích WSL / WSL2 nên cài Docker trên Hyper-V và đang dùng cái này.
Mình có thể dè dặt hỏi lý do bạn không thích nó được không ạ?
Tôi không thích việc trộn lẫn hai hệ điều hành với nhau. Tôi cũng không biết có thể phát sinh những tác dụng phụ nào. Tôi nghĩ mỗi hệ điều hành nên được sandbox riêng hoặc chiếm trọn một máy chủ vật lý. Hơn nữa, trước đây tôi cũng từng có trải nghiệm WSL hoạt động không ổn định.
Vì trong phạm vi kiến thức tôi biết, tôi không hiểu rõ lắm điều anh/chị đang nói, nên xin hỏi liệu
nó có giống với cấu trúc logic cơ bản của WSL hay Docker không?
Có phải tôi đã hiểu sai chỗ nào không?
Cũng có thể nói WSL2 hơi giống một chút, nhưng cấu trúc của WSL khá khác. Về cơ bản nó chạy trên nhân Windows. Đúng là WSL2 chạy trên hypervisor, nhưng tôi nghĩ mức độ cô lập có phần khác. Vì tự động mount hai chiều nên các OS có thể truy cập hệ thống tập tin của nhau. Do đó có thể phát sinh những kết quả không mong muốn. Ví dụ Windows tự động tạo
$RECYCLE.BINtrên ext4, hoặc nếu một bên OS bị hacker chiếm quyền thì cả hai bên đều có thể bị ảnh hưởng nghiêm trọng. Cái tôi làm thì nếu muốn có thể không mount gì cả. Có thể để nó tự chạy một mình mà không kết nối với Windows.Ngoài ra còn ảnh hưởng đến tốc độ cài đặt nữa... Với cách dùng image của tôi thì nếu không thích chỉ cần xóa image Docker đi rồi sao chép một cái mới khác. Khi cập nhật cũng chỉ cần tải image về là xong. Tôi nhớ là phía mạng của WSL2 cũng từng có một số vấn đề. Thêm nữa, nhân Linux ở đó cũng không phải nhân Linux thuần mà theo tôi biết là bản đã được Microsoft tùy biến.
Nó không thật sự hợp với tôi, vì tôi hướng đến Linux thuần (tức là muốn hai bên được cô lập với nhau).
Tôi chỉ liệt kê các nhược điểm như vậy thôi, nhưng thật ra đây cũng phần nào là khác biệt về sở thích cá nhân, nên bạn cứ chọn thứ mình muốn.
Tôi phản hồi chậm quá.
Cảm ơn bạn đã trả lời rất tận tình!
Và vì bản thân Docker hầu như cũng chỉ dành cho Linux, lại có nhiều lợi ích khi chạy Docker trên NAS, cũng như việc phân biệt chữ hoa/chữ thường, nên có thể xem là tôi đã làm nó vì Docker mang lại khá nhiều lợi thế.
Trong trường hợp
privileged mode, đã chỉnh sửa để chạy trong sandbox. Trong trường hợpprivileged mode, có thể kết nối tài nguyên cục bộ (ổ C, v.v.). Các kết nối sẽ được mount vào$HOME/thinclient_drives.Nếu muốn kết nối tài nguyên cục bộ (C:, D: v.v.) thì hãy chạy ở chế độ privileged. (Khi đó sẽ dùng được sao chép tệp bằng CTRL + C / V)
Ồ... có vẻ VS Code không chạy được nhỉ :)
Tự trả lời: vì không thấy ai phản hồi nên tôi thử đủ thứ, rồi thấy mở được khi chạy
code --no-sandboxtrong terminal.Ủa? Có phải là thứ trên màn hình desktop không mở được không?
À vâng, đúng là không được. Không biết tôi đã làm sai ở đâu..
Có thể là vì tôi vẫn đang tiếp tục thay đổi image nên đây có thể là một image trung gian.
Trước hết, hãy kiểm tra xem biểu tượng vscode trên desktop có lệnh là
/usr/bin/code %Fhay không,và mở file
/usr/bin/codera để kiểm tra xem dòng áp chót có phải làELECTRON_RUN_AS_NODE=1 "$ELECTRON" "$CLI" --no-sandbox --disable-gpu "$@"không nhé.
Gần đây tôi đang học về Docker. Tôi đã dùng
trivyđể quét lỗ hổng của image này thì phát hiện ra 1053 lỗ hổng. Có vẻ không phải cái nào cũng quan trọng, mà giống như nó cứ quét ra đủ thứ. Về mặt thực tế trong công việc, có thể cho tôi xin lời khuyên về cách xác minh và đạt được mức độ bảo mật của image như thế nào không?Thực ra có quá nhiều cách để loại bỏ lỗ hổng nên không có đáp án đúng duy nhất.
Trường hợp của tôi thì dùng phiên bản mới nhất đã được ổn định hóa tối đa, và khi dùng GitHub Actions thì bật các security bot nhiều nhất có thể. Thực ra như bạn có thể thấy, image xwindow lần này không có phần nào được lập trình, nên có lẽ chỉ có các lỗ hổng mặc định vốn có của chính những chương trình đã được cài đặt.
Tôi thắc mắc vì sao việc không áp dụng chế độ sandbox lại được coi là một lưu ý bảo mật.
Docker có nghĩa là không cung cấp chức năng sandbox cho các tiến trình bên trong hay sao? Vì vậy nên buộc phải chạy bằng quyền root, và dù là môi trường đã được cô lập bằng Docker thì vẫn hàm ý rằng mã độc có thể xâm nhập vào các volume được ánh xạ với host? Hay là ý nói các tệp do người dùng tạo ra trong hệ thống tệp bên trong Docker có thể không an toàn?
Theo tôi biết thì dù là Windows hay Linux, Chrome đều chạy ở chế độ sandbox. Nghĩa là... ngay cả khi ai đó tạo exploit bằng
javascriptchẳng hạn để tấn công lỗ hổng, thì nó cũng sẽ không ảnh hưởng đến hệ điều hành thực tế.Nhưng ở chế độ container thì có lẽ chỉ khi bật chế độ
priviligedmới có thể bật được tính năng đó.Tất nhiên cũng có thể hướng dẫn người dùng bật chế độ đó, nhưng tôi vốn nghĩ bản thân container đã là một sandbox rồi. Có thể nói nó giống như một cửa sổ có thể bật lên rồi tắt đi rất dễ dàng...
Vì vậy Chromium và VS Code dựa trên Electron được thiết lập để chạy ở chế độ không có sandbox.
Ý tôi chỉ là, nếu giả định Chromium và VS Code có lỗ hổng, và kẻ tấn công có thể lợi dụng chúng để tạo exploit, thì điều đó có thể nguy hiểm.
Tên Docker là
lancard/xwindow-korean.Vì là Wayland nên tôi đã đổi tên repo thành https://github.com/lancard/xwindow-korean ~
Vì Ubuntu thuộc họ Debian nên bạn cũng có thể thoải mái dùng
aptvà các công cụ tương tự. Tôi thấy Debian còn tốt hơn cả image Ubuntu mặc định.