Windows RDP से कनेक्ट होने वाली कोरियाई XWINDOW Docker इमेज

मैं नवीनतम Debian 13(Trixie) आधारित कोरियाई XWINDOW (wayland) Docker इमेज बनाकर सार्वजनिक कर रहा हूँ.

वास्तव में Windows इस्तेमाल करने वाले लोग बहुत हैं, और कभी-कभी आप Docker में कोरियाई-सक्षम Linux X Window चलाकर काम करना चाहेंगे.
इसलिए!
मैंने Windows Remote Desktop से एक्सेस की जा सकने वाली Debian-आधारित कोरियाई GUI environment तैयार किया है.

इस इमेज में Visual Studio Code, Chromium, Vim, Git, Node.js + npm जैसे development environment के लिए ज़रूरी प्रमुख टूल पहले से इंस्टॉल हैं, इसलिए इसे तुरंत development environment के रूप में इस्तेमाल किया जा सकता है. (इसी वजह से इमेज थोड़ी बड़ी है)

मुख्य विशेषताएँ:

• Windows Remote Desktop (RDP) कनेक्शन सपोर्ट
• डेटा और volume बना रहता है: /home/(사용자명) को Docker volume से जोड़ने पर डेटा persistent रहता है

ध्यान देने योग्य बातें:
Docker में चलने के कारण VSCode और Chromium sandbox mode के बिना उपयोग किए जाते हैं. कृपया सुरक्षा का ध्यान रखें. साथ ही, sound feature को conflicts और bugs की वजह से हटा दिया गया है. मेरा मानना है कि ज़्यादातर लोग संगीत Windows PC पर ही सुनते होंगे, इसलिए इसे शामिल नहीं किया गया.

यह इमेज उन कोरियाई उपयोगकर्ताओं के लिए खास तौर पर उपयोगी है जो development environment जल्दी सेटअप करना चाहते हैं.

सोर्स https://github.com/lancard/x11-korean पर उपलब्ध है, देख लें, और यदि आपको कोई ज़रूरी feature चाहिए तो कभी भी issue या PR भेजें!

[chcv0313]

अंदर के vscode में नई फ़ाइल बनाई जा सकती है, लेकिन मौजूदा फ़ाइलों को एडिट नहीं किया जा सकता। मौजूदा फ़ाइलों पर chmod 777 लगाने के बाद भी। लगता है यह permission या group ownership की समस्या हो सकती है, इसलिए मैं कुछ और चीज़ें आज़माकर देखूंगा।

[chcv0313]

ऐसा लगता है कि entry point में मौजूद sh फ़ाइल को संशोधित करके और XWINDOW_USER_ID को working folder ID के अनुसार सेट करके इसे हल किया गया है।

[chcv0313]

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

इस हिस्से को

XWINDOW_USER="${XWINDOW_USER:-user}"
XWINDOW_USER_ID="${XWINDOW_USER_ID:-1000}" # डिफ़ॉल्ट 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

में बदलकर USER_ID को host machine के account ID के समान ही सेट कर दिया।

[shakespeares]

क्या इसे WSL के विकल्प के रूप में इस्तेमाल किया जा सकता है?

[lancard]

हाँ, इसका इस्तेमाल किया जा सकता है। मुझे व्यक्तिगत रूप से WSL / WSL2 पसंद नहीं है, इसलिए मैंने hyperv पर docker इंस्टॉल करके यही इस्तेमाल किया हुआ है.

[shakespeares]

क्या मैं सावधानी से यह पूछ सकता हूँ कि आपको यह क्यों पसंद नहीं है?

[lancard]

मुझे दो तरह के OS का मिलाना पसंद नहीं है। पता नहीं इससे किस तरह के side effects हो सकते हैं। मेरा मानना है कि हर OS या तो sandbox में होना चाहिए या एक पूरा physical server अकेले इस्तेमाल करना चाहिए। इसके अलावा, पहले WSL के अजीब तरह से काम करने का अनुभव भी रहा है।

[doovooda]

मेरी जानकारी के हिसाब से, आप जो कह रहे हैं वह मुझे ठीक से समझ नहीं आ रहा, तो क्या यह
WSL या Docker की बुनियादी logical structure से मिलता-जुलता नहीं है?
क्या मैंने कहीं गलत समझा है?

[lancard]

WSL2 को कुछ लोग इससे मिलता-जुलता कह सकते हैं, लेकिन WSL की संरचना थोड़ी अलग है। मूल रूप से यह Windows kernel के ऊपर चलता है। WSL2 का hypervisor के ऊपर चलना सही है, लेकिन मुझे लगता है कि इसका isolation level थोड़ा अलग है। क्योंकि auto-mount दोनों तरफ होता है, इसलिए दोनों OS एक-दूसरे के file system तक पहुँच सकते हैं। इससे अनचाहे नतीजे आ सकते हैं। उदाहरण के लिए, Windows का ext4 पर अपने-आप $RECYCLE.BIN बना देना, या अगर किसी एक OS पर हैकर का कब्ज़ा हो जाए तो दोनों के लिए यह घातक हो सकता है। मैंने जो बनाया है, उसमें चाहें तो कुछ भी mount न करें। इसे Windows से जोड़े बिना, पूरी तरह अपने-आप भी चलाया जा सकता है.
और शायद installation speed पर भी असर पड़ता है... मेरी image वाली विधि में बस इतना है कि अगर पसंद न आए तो docker image हटा दें और नई copy बना लें। Update करते समय भी बस image ही फिर से लेनी होती है। मुझे याद है कि WSL2 के network पक्ष में भी कुछ समस्याएँ थीं। साथ ही, Linux kernel भी शुद्ध Linux kernel नहीं है, बल्कि मेरी जानकारी के अनुसार MS ने उसे customize किया है।
शुद्ध Linux को लक्ष्य बनाने वाले (यानी जो आपसी isolation चाहते हैं) मेरे उपयोग के साथ यह थोड़ा मेल नहीं खाता।

मैंने सिर्फ कमियाँ ही गिनाईं, लेकिन सच कहूँ तो यह कुछ हद तक व्यक्तिगत पसंद का मामला भी है, इसलिए आप अपनी ज़रूरत के हिसाब से जो चाहें चुन सकते हैं.

[doovooda]

जांचने में देर हो गई।
इतने मन से दिए गए जवाब के लिए धन्यवाद!

[lancard]

और Docker खुद भी लगभग Linux-only है, और NAS पर Docker चलाना हो या case sensitivity जैसी बातें हों, Docker से करने के फायदे ज़्यादा हैं, इसलिए इसे बनाया गया है।

[lancard]

privileged mode होने पर इसे sandbox में चलने के लिए संशोधित किया गया है. privileged mode होने पर लोकल resources (C drive आदि) को कनेक्ट किया जा सकता है. कनेक्शन $HOME/thinclient_drives में mount किया जाता है.

[lancard]

अगर आप local resources (C:, D: आदि) कनेक्ट करना चाहते हैं, तो इसे privileged मोड में चलाएँ। (तब CTRL + C / V से फ़ाइल कॉपी काम करेगी)

[po5678]

ओहोओक.. VS Code चल नहीं रहा है :)

[po5678]

मैं खुद ही जवाब दे रहा हूँ। कोई प्रतिक्रिया नहीं मिली, तो यह-वह देखते हुए पाया कि टर्मिनल में code --no-sandbox चलाने पर यह खुल जाता है।

[lancard]

हूँ? क्या डेस्कटॉप पर मौजूद चीज़ नहीं खुली?

[po5678]

आह, नहीं, यह काम नहीं कर रहा था। पता नहीं मैंने क्या गलत किया..

[lancard]

मैं इमेज को लगातार बदल रहा हूँ, इसलिए हो सकता है कि यह बीच का इमेज हो.
फिलहाल पहले यह देख लें कि डेस्कटॉप पर मौजूद vscode आइकन का कमांड /usr/bin/code %F है या नहीं,
और /usr/bin/code फ़ाइल खोलकर यह भी जांच लें कि अंत से दूसरी पंक्ति
ELECTRON_RUN_AS_NODE=1 "$ELECTRON" "$CLI" --no-sandbox --disable-gpu "$@"
ऐसी ही है या नहीं.

[chcv0313]

मैं हाल ही में Docker सीख रहा हूँ। मैंने trivy से इस इमेज की vulnerabilities स्कैन कीं, तो 1053 vulnerabilities मिलीं। ऐसा नहीं लगता कि वे सब महत्वपूर्ण हैं; बस लगता है जैसे यह हर तरह की चीज़ पकड़ लेता है। क्या व्यावहारिक तौर पर यह जाँचने और हासिल करने के बारे में कोई सलाह मिल सकती है कि इमेज कितनी secure है?

[lancard]

असल में vulnerabilities हटाने के तरीके इतने ज़्यादा हैं कि कोई एक सही जवाब नहीं है, लेकिन
मेरे मामले में, मैं जितना हो सके उतना stabilized latest version इस्तेमाल करता हूँ, और GitHub Actions इस्तेमाल करते समय security bot को अधिकतम हद तक enabled रखता हूँ। दरअसल, जैसा कि आप इस xwindow image में देख सकते हैं, इसमें कोई programming वाला हिस्सा नहीं है, इसलिए installed programs की अपनी default vulnerabilities ही होंगी।

[grollcake]

मुझे यह जानकर जिज्ञासा हुई कि sandbox mode लागू न होना सुरक्षा संबंधी सावधानी क्यों माना गया।
क्या इसका मतलब है कि Docker अंदरूनी processes को sandbox feature नहीं देता? इसलिए क्या इसे मजबूरी में root के रूप में चलाना पड़ता है, और भले ही यह Docker से अलग-थलग किया गया environment हो, फिर भी host से mapped volume में malware घुसने का जोखिम हो सकता है? या फिर इसका मतलब यह है कि Docker के अंदर file system में user द्वारा बनाई गई files सुरक्षित न हों?

[lancard]

मेरी जानकारी के अनुसार, चाहे Windows हो या Linux, Chrome sandbox mode में चलता है। यानी... अगर कोई JavaScript वगैरह से exploit बनाकर किसी vulnerability पर हमला भी करे, तब भी उसका असर वास्तविक OS पर नहीं पड़ता।

लेकिन container mode में शायद वह फीचर चालू करने के लिए privileged mode ऑन करना पड़ेगा।

बेशक, ऐसा करने के लिए निर्देश दिया जा सकता है, लेकिन मैं तो container को ही एक sandbox मानता था। शायद इसे ऐसे कहूँ कि यह ऐसे Windows जैसा है जिसे आसानी से चालू और बंद किया जा सकता है...

इसी वजह से Chromium और Electron-आधारित vscode को sandbox के बजाय non-sandbox mode में चलने के लिए रखा गया है।

बात सिर्फ इतनी है कि अगर Chromium और vscode में vulnerability हो, और कोई हमलावर उसका इस्तेमाल करके exploit बना सके, तो यह खतरनाक हो सकता है।

[lancard]

docker का नाम lancard/xwindow-korean है

[lancard]

Wayland होने की वजह से repo का नाम https://github.com/lancard/xwindow-korean में बदल दिया गया है~

[lancard]

Ubuntu, Debian-आधारित होने की वजह से, apt जैसी चीज़ें भी आसानी से इस्तेमाल की जा सकती हैं। Ubuntu की बेस इमेज से Debian मुझे ज़्यादा बेहतर लगा।