Windows RDP ile bağlanılabilen Türkçe XWINDOW Docker imajı
(github.com/lancard)En güncel Debian 13 (Trixie) tabanlı Türkçe XWINDOW (wayland) Docker imajını hazırlayıp paylaşıyorum.
Gerçekte Windows kullanan çok kişi var; ara sıra Docker ile Türkçe destekli bir Linux X Window ortamını ayağa kaldırıp çalışmak istediğiniz zamanlar olabiliyor.
Bu yüzden!
Windows Uzak Masaüstü ile erişilebilen, Debian tabanlı Türkçe bir GUI ortamı hazırladım.
Bu imajda Visual Studio Code, Chromium, Vim, Git, Node.js + npm gibi geliştirme ortamı için gerekli başlıca araçlar varsayılan olarak kurulu geliyor; bu sayede doğrudan geliştirme ortamı olarak kullanılabiliyor. (Bu yüzden boyutu biraz büyük.)
Başlıca özellikleri şunlar:
- Windows Uzak Masaüstü (RDP) bağlantısı desteklenir
- Veri ve volume kalıcılığı:
/home/(kullanıcı_adı)dizinini Docker volume olarak bağlarsanız veriler kalıcı olur
Dikkat edilmesi gerekenler:
Docker üzerinde çalıştığı için VSCode ve Chromium sandbox modunu kullanmaz. Güvenlik açısından dikkatli olmanızı rica ederim; ses özelliği ise çakışma ve hata çok olduğu için çıkarıldı. Benim düşünceme göre çoğu kişi müziği zaten Windows PC üzerinden dinliyordur, bu yüzden dahil etmedim.
Geliştirme ortamını hızlıca kurmak isteyen Türkçe kullanıcılar için özellikle faydalı bir imaj.
Kaynak kodu https://github.com/lancard/x11-korean adresinde; bakabilirsiniz. İhtiyacınız olan bir özellik varsa istediğiniz zaman issue ya da PR gönderebilirsiniz!
25 yorum
İçerideki vscode'da yeni dosya oluşturulabiliyor ama mevcut dosyalar düzenlenemiyor. Mevcut dosyaları
chmod 777ile değiştirsem de olmuyor. Muhtemelen izinler ya da grup sahipliğiyle ilgili bir sorun; biraz daha çeşitli şeyler deneyeceğim.Giriş noktasındaki
shdosyasını düzenleyipXWINDOW_USER_IDdeğerini çalışma klasörü kimliğiyle eşleştirerek bunun üstesinden gelmiş gibi görünüyor.kullanıcı adını ayarla
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
bölümünü
XWINDOW_USER="${XWINDOW_USER:-user}"
XWINDOW_USER_ID="${XWINDOW_USER_ID:-1000}" # varsayılan 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
şeklinde değiştirip USER_ID değerini host makinedeki hesap kimliğiyle aynı olacak şekilde verdim.
WSL yerine kullanılabilir mi?
Evet, kullanılabiliyor. Ben şahsen WSL / WSL2'yi sevmiyorum; bu yüzden Hyper-V üzerine Docker kurup bunu kullanıyorum.
Acaba neden sevmediğinizi kibarca sorabilir miyim?
İki farklı işletim sisteminin karışmasından hoşlanmıyorum. Ne tür yan etkiler olabileceğini de bilmiyorum. Her işletim sisteminin ya bir sandbox içinde olması ya da tek başına bir fiziksel sunucuyu kullanması gerektiğini düşünüyorum. Ayrıca geçmişte WSL’in garip davrandığı bir deneyimim de oldu.
Benim bildiklerimle söylemek istediğiniz şeyi tam anlayamadım, acaba
WSL ya da Docker’ın temel mantıksal yapısına benzemiyor mu?
Benim yanlış değerlendirdiğim bir nokta var mı?
WSL2 için biraz benziyor diyebilirsiniz ama WSL’in yapısı biraz farklı. Temelde Windows çekirdeği üzerinde çalışıyor. WSL2’nin hypervisor üzerinde çalıştığı doğru ama yalıtım seviyesinin biraz farklı olduğunu düşünüyorum. Otomatik mount işlemi iki tarafta da yapıldığı için işletim sistemleri birbirlerinin dosya sistemine erişebiliyor. Bu da istenmeyen sonuçlara yol açabiliyor. Örneğin Windows’un ext4 üzerinde otomatik olarak
$RECYCLE.BINoluşturması gibi; ya da taraflardan birindeki işletim sistemi bir hacker tarafından ele geçirilirse, bu iki taraf için de kritik olur. Benim yaptığım çözümde isterseniz hiçbir şeyi mount etmeyebilirsiniz. Windows’a bağlamadan tek başına çalıştırabilirsiniz.Ayrıca kurulum hızı da etkileniyor denebilir... Benim image yöntemimde hoşunuza gitmezse docker image’ını silip bir tane daha kopyalamanız yeterli. Güncelleme yaparken de sadece image’ı indirmeniz yeterli oluyor. WSL2’nin ağ tarafında da bazı sorunlar olduğunu hatırlıyorum. Ayrıca Linux çekirdeğinin de saf bir Linux çekirdeği değil, MS’in özelleştirdiği bir çekirdek olduğunu biliyorum.
Saf Linux’u hedefleyen (yani birbirinden yalıtılmış olmasını isteyen) biri olarak bana pek uymuyor.
Sadece dezavantajlarını sıralamış gibi oldum ama aslında biraz da kişisel tercih farkı var; bu yüzden istediğiniz şeyi seçebilirsiniz.
Kontrolüm gecikti.
Özenli yanıtınız için teşekkür ederim!
Ayrıca Docker’ın kendisi de neredeyse yalnızca Linux odaklı ve NAS üzerinde Docker çalıştırmak ya da büyük/küçük harf ayrımı gibi konularda Docker kullanmanın birçok avantajı olduğu için bunu yaptığımı düşünebilirsiniz.
privileged modedurumunda sandbox içinde çalışacak şekilde düzeltildi.privileged modedurumunda yerel kaynaklar (C sürücüsü vb.) bağlanabilir. Bağlantılar$HOME/thinclient_drivesiçine mount edilir.Yerel kaynakları (
C:,D:vb.) bağlamak istiyorsanız privileged modda çalıştırmanız yeterlidir. (BöyleceCTRL + C / Vile dosya kopyalama çalışır)Ooo.. VS Code çalışmıyor gibi görünüyor :)
Kendi yanıtım: Tepki gelmeyince şuna buna bakarken terminalde
code --no-sandboxçalıştırınca açıldığını gördüm.Hmm? Masaüstündeki şey açılmadı mı acaba?
Ah evet, olmuyordu. Neyi yanlış yaptığımı bilmiyorum..
Ben görüntüyü sürekli değiştirdiğim için bunun ara bir imaj olduğunu düşünebilirsiniz.
Öncelikle masaüstündeki vscode simgesinin komutunun
/usr/bin/code %Folup olmadığını kontrol edin,ve
/usr/bin/codedosyasını açıp sondan ikinci satırınELECTRON_RUN_AS_NODE=1 "$ELECTRON" "$CLI" --no-sandbox --disable-gpu "$@"şeklinde olup olmadığını kontrol edin.
Ben de son zamanlarda Docker çalışıyorum. Bu imajın güvenlik açıklarını
trivyile taradım ve 1053 açık çıktı. Hepsi önemli gibi görünmüyor; sanki bulabildiği her şeyi yakalıyor gibi. Pratikte bir imajın güvenliğini nasıl doğrulayıp sağlayabileceğimiz konusunda tavsiye verebilir misiniz?Aslında zafiyetleri gidermenin çok fazla yolu var; bu yüzden tek bir doğru cevap yok.
Benim durumumda mümkün olduğunca kararlı en güncel sürümü kullanıyor, GitHub Actions kullanırken de security botlarını olabildiğince açık tutuyorum. Aslında bu xwindow imajında da gördüğünüz gibi programlanmış bir kısım olmadığı için, büyük olasılıkla yalnızca kurulu programların kendi varsayılan zafiyetleri vardır.
sandboxmodunun uygulanmamış olmasının neden bir güvenlik uyarısı sayıldığını merak ettim.Docker, iç süreçlere sandbox özelliği sağlamıyor mu? Bu yüzden mecburen root olarak çalıştırılması mı gerekiyor ve Docker ile izole edilmiş bir ortam olsa bile host ile eşlenen volume'lere kötü amaçlı yazılım sızabilmesi riskini mi ifade ediyor? Yoksa Docker içindeki dosya sisteminde kullanıcının oluşturduğu dosyaların güvenli olmayabileceği anlamına mı geliyor?
Bildiğim kadarıyla Chrome, ister Windows’ta ister Linux’ta olsun, sandbox modunda çalışır. Yani... olur da JavaScript vb. ile bir exploit hazırlanıp bir zafiyete saldırı yapılsa bile, gerçek işletim sistemini etkilemez.
Ama konteyner modunda bu özelliği açabilmek için muhtemelen
privilegedmodunu etkinleştirmek gerekir.Elbette bu modu açmaları yönünde bir yönlendirme yapılabilir ama ben konteynerin kendisini bir sandbox olarak düşünüyordum. Kolayca açıp kapatılan bir Windows gibi, öyle düşünün...
Bu yüzden Chromium ve Electron tabanlı VS Code, sandbox olmayan modda çalışacak şekilde ayarlanmış.
Bu, tamamen Chromium ve VS Code’da bir zafiyet olduğu ve saldırganın bunu kullanarak bir exploit geliştirebildiği varsayımında tehlikeli olabileceği anlamına geliyor.
Docker adı
lancard/xwindow-korean.Wayland olduğu için repo adını https://github.com/lancard/xwindow-korean olarak değiştirdim~
Ubuntu Debian tabanlı olduğu için
aptgibi araçları da rahatça kullanabilirsiniz. Ubuntu’nun temel imajından ziyade Debian’ın daha iyi olduğunu gördüm.