Ｘウィンドウは、パソコンやサーバにＧＵＩ（言葉でなく画像での操作）を提供する、基本アプリのひとつですーークライアント〜サーバ・モデルの採用や、柔軟なカスタマイズ性など、ほかのウィンドウシステムにはない特徴があります。［※１］
- ※１
- ただ細かい部分ではあつかいにくい面もあり、いまは、これをより洗練させたモデル（Wayland ）が提案〜実装されています（とはいえX Window のプロトコルも受け付けられるよう、サブシステムとして残されています）。
検証
- ◯
- ローカル
- ・
- ＯＳ：macOS 11
- ・
- ウィンドウシステム：XQuartz 2.8
- ・
- コンテナ：Docker 20.10 (Docker Desktop)
- ◯
- リモートホスト
- ・
- ＯＳ：Ubuntu 20.04
- ・
- コンテナ：Docker 20.10
ＧＵＩの基本アプリ：X Window
Ｘウィンドウは、パソコンやサーバにＧＵＩを提供する、基本アプリのひとつです。
その大きな特徴は、クライアント〜サーバ・モデルになっている、という点にありますーーＸウィンドウは、グラフィックを送信する「Ｘクライアント」と、グラフィックを表示する「Ｘサーバ」に分かれますーーこうすることで、たとえばビデオモニタがない（ヘッドレスの）リモートホストで動いているＸクライアントの描画を、ローカル（自分のパソコンなど）のＸサーバの画面に表示させる、といったことができるようになります。［※１］［※２］
- ※１
- つまりウィンドウ単位で、遠隔操作ができるわけです。しかもＩＰネットワークに対応しているので、原理上はインターネット上のどのノードでも、ＸサーバとＸクライアントになれます（ただし現状のネットーワークは、ＮＡＴといった制約があるのでやっかいですが）。
- ※２
- カスタマイズが自在であることも、特徴のひとつですーーウィンドウの枠の形や色、ボタン類の有無や配置まで、柔軟に変更できます（たとえばボタン類をいっさい廃して、枠とキーのショートカットだけでウィンドウを操作する、といったこともできたりします……見た目かなりシンプルになりますよ）。
ＧＵＩの基本アプリ：個別：X Window (XQuartz)
マック（macOS ）向けのＸウィンドウ（XQuartz ）は、次にあります：
- ・
- https://www.xquartz.org/
遠隔のサーバやコンテナ上のＸクライアントからの接続を許可するには、次を設定しておきます：
環境設定 > セキュリティ > 接続を認証: <yes> > ネットワーククライアントからの接続を許可: <yes>
標準のＣＧライブラリ（OpenGL）は、既定では有効になっていません。これを使うには、次を設定し、ウィンドウシステムを再起動します：
$ defaults write org.xquartz.X11 enable_iglx -bool true
Ｘサーバの設定
Ｘサーバ側は、Ｘクライアントからの描画要求を受けつけるよう、認証させる必要があります。基本は、相手のＩＰアドレスやホスト名を指定します。
たとえば、ローカルで動いているＸクライアントに対しては：
$ xhost +localhost
Ｘクライアントの設定（ローカル：コンテナの場合）
ローカルのコンテナ上で動いているＸクライアントからの描画要求を受けられるようにするには、Ｘウィンドウの表示デバイスとソケットとを共有します：
- ◯
- ローカル：
$ docker run -it --rm \
--env DISPLAY=${DISPLAY} \ # ホスト側の表示デバイスを引き継ぐ
--mount type=bind,src=/tmp/.X11-unix,dst=/tmp/.X11-unix \ # ホスト側のソケットを共有する
--name ${container} \
${image}
Ｘクライアントの設定（ローカル：コンテナ：仮想環境の場合）
コンテナが仮想環境の上で動いている場合（macOS やWindows の一部）、ローカルのＸサーバとは、表示デバイスやソケットを共有できません。代わりに、特別な表示デバイスをコンテナ側が用意しているので、これを使います：
- ◯
- ローカル：
$ docker run -it --rm \
--name ${container} \
${image}
- ◯
- コンテナ：
$ export DISPLAY=host.docker.internal:0.0
Ｘクライアントの設定（リモートホスト：コンテナの場合）
ＸウィンドウがＩＰネットワークに対応しているといっても、現在のネットワークでは、リモートにＸクライアントがある場合、ローカルのＸサーバに向けて直接通信できないこともよくあります（内側のアドレスが変換されてしまう、ＮＡＴなどにより）。
ローカル側から、リモートのコンテナにあるＸクライアントにつなぐ手法には、ＳＳＨによるポートフォワーディングがあります：［※１］
- ◯
- リモートホスト：
$ cd /etc/ssh $ cat sshd_config | grep '^X11Forwarding' X11Forwarding yes
$ docker run -it --rm \
--env DISPLAY=${DISPLAY} \ # ホスト側の表示デバイスを引き継ぐ
--net host \ # ホスト側とネットワークを共有する
--mount type=bind,src=${HOME}/.Xauthority,dst=/root/.Xauthority \ # ホスト側のＸウィンドウの認証ファイルを共有する
--name ${container} \
${image}
- ◯
- ローカル：
$ xhost +${server_remote} # 許可：リモートホスト
$ ssh -X ${user_remote}@${server_remote} # 接続：リモートホスト
- ※１
- この場合、リモートホストにファイアウォールを適用していなければ、リモートホストのホストに、どこからでもＳＳＨで接続できる状態になります……かといってプロバイダ経由だと、ＩＰアドレスが自動で割り当てられるので、ファイアウォールでそれなりに範囲を絞ることはできても完全に防ぐことは難しいですしね……ＶＰＮサーバを立ち上げて、そこを経由してアクセスする、などの方法はありますが……
Ｘクライアントの設定（リモートホスト：コンテナ：マルチユーザの場合）
ホスト側のネットワークを独占しない場合は（ルートレスのコンテナなど）、コンテナ内でＳＳＨサーバを稼働させ、そこにＸフォワードします：
- ◯
- リモートホスト：コンテナ：
$ apt install openssh-server # ＳＳＨサーバを導入〜設定 $ echo 'PermitRootLogin prohibit-password' >> /etc/ssh/sshd_config $ echo 'X11UseLocalhost no' >> /etc/ssh/sshd_config $ cd /root $ mkdir .ssh $ cd /root/.ssh $ vi authorized_keys # 自身の公開鍵を記載 $ /etc/init.d/ssh restart # いったん起動し、既定の設定を生成
- ◯
- リモートホスト：
$ docker run -d --rm -p 10023:22 --name ${container} ${image} /usr/sbin/sshd -D # ＳＳＨサーバとして起動（ホスト側の空いているポートで受け付け）
- ◯
- ローカル：
$ ssh -X -p 10023 root@${server_remote} # Ｘフォワーディングでコンテナに接続
Ｘクライアントの設定（リモートホスト：コンテナ：ＶＮＣの場合）：Xvfb, x11vnc
ローカル側でＸサーバを動かしたくないなら、ＶＮＣクライアントを使う、というやり方もあります。
リモートホストのコンテナでＸサーバを動かし、そのＸサーバの描画要求をＶＮＣサーバに渡します。そのＶＮＣサーバに、ローカルのＶＮＣクライアントから接続します：［※１］
- ・
- Ｘサーバ：Xvfb
- ・
- ＶＮＣサーバ：x11vnc
- ◯
- リモートホスト：コンテナ：
$ export n=1
$ export DISPLAY=:${n}
$ Xvfb :${n} -screen 0 600x450x24 &
$ x11vnc -display :${n} -forever -passwd ******** &
- ※１
- マック（macOS ）の標準ＶＮＣクライアントの場合、次のオプションは必須です：-forever, -passwd
遠隔からデスクトップを使う［検証中］
遠隔からデスクトップを使うには、Ｘサーバをネストする（Ｘサーバ兼Ｘクライアント）アプリを使うことで、実現できます：［※１］［※２］
ＳＳＨからポートフォワードした遠隔の端末で、次のように実行します：
$ Xephyr :1 & $ DISPLAY=:1 gnome-session # デスクトップ環境がGNOME の場合 $ DISPLAY=:1 startkde # デスクトップ環境がKDE の場合
- ※１
- Xephyrは、Xnest の後継です。
- ※２
- ただしキーマップやセッションの管理がややこしく、現時点ではうまく動かせていません（2022.10.16）。
ＧＵＩの開発環境：Tcl/Tk
Ｘウィンドウで動くＧＵＩのアプリを作るために、専用のツールキット「Tcl/Tk」が用意されています。
このうち「Tk」は、ＡＰＩを提供します。「Tcl 」は、そのＡＰＩ操作するスクリプト言語のひとつです（「Tk」に対しては、ほかにさまざまなスクリプト言語（Python, etc.）も対応しています）。