グラフィカルデスクトップ

Linuxのグラフィカルデスクトップの基礎と問題解決

Linuxのグラフィカルデスクトップでは、伝統的にX11（X Window System）が広く使われてきました。現在では、X11に代わる仕組みとしてWaylandを標準採用するディストリビューションも増えています。

LPICレベル1では、X11のクライアント・サーバー構成、DISPLAY環境変数、アクセス制御、ディスプレイマネージャやウィンドウマネージャの役割などを理解しておくことが重要です。

X11（X Window System）の基礎

XサーバーとXクライアント

X11は、画面表示や入力装置を管理する側と、アプリケーションを実行する側を分離した、クライアント・サーバー型の仕組みです。

一般的なサーバーのイメージとは異なり、X11では次のように呼びます。

• Xサーバー
  • ディスプレイへの描画を管理する
  • キーボードやマウスなどの入力を受け取る
  • 通常はユーザーの手元にあるマシンで動作する
• Xクライアント
  • ブラウザ、端末エミュレータ、エディタなどのGUIアプリケーション
  • Xサーバーへ描画を要求し、Xサーバーから入力イベントを受け取る

ウィンドウマネージャもXクライアントの一種です。ウィンドウの枠、配置、移動、サイズ変更、最小化などを管理します。

なお、ウィンドウマネージャとデスクトップ環境は同じものではありません。デスクトップ環境は、ウィンドウマネージャまたは同等の機能に加え、パネル、ファイルマネージャ、設定ツールなどをまとめたソフトウェア一式です。

ネットワーク透過性とDISPLAY変数

X11には、XサーバーとXクライアントを異なるマシン上で動作させられるネットワーク透過性があります。

Xクライアントが接続するXサーバーは、DISPLAY環境変数によって指定されます。

DISPLAY=ホスト名:ディスプレイ番号.スクリーン番号

例：

DISPLAY=:0

ローカルマシンのディスプレイ0を表します。

DISPLAY=remotehost:1.0

remotehost上のディスプレイ1、スクリーン0を表します。

現在のマルチモニター環境では、複数のモニターを別々のスクリーン番号に分けるのではなく、RandR拡張などによって1つの大きな画面として管理するのが一般的です。そのため、スクリーン番号は通常.0です。

現在の値は次のように確認できます。

echo "$DISPLAY"

DISPLAYが未設定または誤っていると、Xクライアントの起動時に次のようなエラーが発生します。

Error: Can't open display

ただし、同じXサーバーに接続するには、DISPLAYが正しいだけでなく、後述するアクセス許可も必要です。

X11のアクセス制御

Xサーバーへの接続制御では、主にxauthとxhostが使われます。

xauth

xauthは、通常「MIT-MAGIC-COOKIE」と呼ばれる認証情報を使ってXサーバーへの接続を許可します。認証情報は、一般的にユーザーの次のファイルに保存されます。

~/.Xauthority

認証情報は次のように確認できます。

xauth list

sudoやsuで別ユーザーに切り替えた後にGUIアプリケーションを起動できない場合は、DISPLAYだけでなく、X11の認証情報を引き継げていない可能性があります。

xhost

xhostは、Xサーバーへの接続をホスト単位またはユーザー単位で許可・拒否するコマンドです。

現在の設定は次のように確認できます。

xhost

次の設定は、すべてのホストからの接続を許可してしまうため危険です。

xhost +

アクセス制御を無効化する方法は、試験上の注意点として覚えておく必要がありますが、実運用では使用を避けます。可能な限りxauthやSSHのX11転送を利用します。

SSHによるX11転送

ネットワーク越しにXアプリケーションを利用する場合、X11の通信を直接公開するのではなく、SSHのX11転送を利用するのが一般的です。

ssh -X user@remotehost

信頼する接続先に対しては、次の指定が使われることもあります。

ssh -Y user@remotehost

SSHのX11転送では、SSHがDISPLAYやxauthの認証情報を自動的に設定します。そのため、ログイン後のDISPLAYが:0ではなく、次のような値になることがあります。

localhost:10.0

WaylandとXWayland

Waylandは、X11よりも構成を単純化し、セキュリティや描画効率を改善することを目的とした表示システムです。

X11ではXサーバーとウィンドウマネージャが別々に動作しますが、Waylandでは一般に、画面合成や入力管理を行うWaylandコンポジタが中心的な役割を担います。

代表例には次のものがあります。

• GNOMEのMutter
• KDE PlasmaのKWin

Waylandで使用するソケットは、WAYLAND_DISPLAY環境変数で示されます。

echo "$WAYLAND_DISPLAY"

例：

wayland-0

Wayland環境で従来のX11アプリケーションを動作させるためには、互換性を提供するXWaylandが使われます。この場合、Waylandセッション上でもDISPLAY環境変数が設定されていることがあります。

現在のセッション種別は、環境によっては次のように確認できます。

echo "$XDG_SESSION_TYPE"

代表的な出力は次のとおりです。

x11

または、

wayland

ディスプレイマネージャ

ディスプレイマネージャの役割

ディスプレイマネージャ（Display Manager）は、グラフィカルなログイン画面を表示し、ユーザー認証後にデスクトップセッションを開始するソフトウェアです。ログインマネージャと呼ばれることもあります。

主な役割は次のとおりです。

• グラフィカルなログイン画面を表示する
• ユーザーを認証する
• GNOME、KDE Plasma、Xfceなどのセッションを選択する
• X11またはWaylandのグラフィカルセッションを開始する
• ログアウト後にログイン画面へ戻す
• 必要に応じてリモートログイン機能を提供する

ディスプレイマネージャは、デスクトップ環境やウィンドウマネージャとは別のものです。

代表的なディスプレイマネージャ

ディスプレイマネージャとデスクトップ環境は、必ずしも同じ系列を組み合わせる必要はありません。例えば、LightDMからGNOMEやXfceを起動することもできます。

ディスプレイマネージャの確認

systemdを使用する環境では、ディスプレイマネージャへの共通のエイリアスとして、display-manager.serviceが用意されていることがあります。

systemctl status display-manager

実体となるサービスは、ディストリビューションや選択したディスプレイマネージャによって異なります。

systemctl status gdm
systemctl status sddm
systemctl status lightdm

どのサービスにリンクされているかは、次のように確認できます。

readlink -f /etc/systemd/system/display-manager.service

ログを調べる場合はjournalctlを使用します。

journalctl -u display-manager -b

または、実際のサービス名を指定します。

journalctl -u gdm -b
journalctl -u sddm -b
journalctl -u lightdm -b

サービスを再起動すると、実行中のグラフィカルセッションが強制終了する可能性があります。

sudo systemctl restart display-manager

作業中のデータが失われる可能性があるため、実行には注意が必要です。

graphical.targetとmulti-user.target

systemd環境では、既定の起動先を次のコマンドで確認できます。

systemctl get-default

代表的なターゲットは次のとおりです。

グラフィカル環境を既定にする場合は、次のように設定します。

sudo systemctl set-default graphical.target

現在の起動中システムでグラフィカル環境へ移行する場合は、次のようにします。

sudo systemctl isolate graphical.target

ただし、ディスプレイマネージャが未導入、無効化、設定不良などの状態では、graphical.targetにしてもログイン画面が表示されないことがあります。

セッション定義ファイル

ログイン画面で選択できるセッションは、一般に次のディレクトリにある.desktopファイルによって定義されます。

/usr/share/xsessions/

Waylandセッションは、一般に次のディレクトリに配置されます。

/usr/share/wayland-sessions/

セッションがログイン画面の一覧に表示されない場合は、該当するデスクトップ環境のパッケージやセッション定義ファイルがインストールされているか確認します。

主な設定ファイル

設定ファイルの場所はディストリビューションによって異なりますが、代表例は次のとおりです。

/etc/gdm/custom.conf
/etc/gdm3/custom.conf
/etc/sddm.conf
/etc/sddm.conf.d/
/etc/lightdm/lightdm.conf
/etc/lightdm/lightdm.conf.d/

試験対策としては、個々の設定項目を暗記するよりも、各ディスプレイマネージャの役割と、設定場所がディストリビューションによって異なることを理解しておく方が重要です。

X11の設定ファイルとログ

X.orgの代表的な設定ファイルは次のとおりです。

/etc/X11/xorg.conf
/etc/X11/xorg.conf.d/*.conf

現在のX.orgは、ハードウェアを自動検出するのが一般的です。そのため、xorg.confが存在しなくても異常とは限りません。必要な設定だけをxorg.conf.d以下のファイルで追加する方式もよく使われます。

代表的なログの保存場所には次があります。

/var/log/Xorg.0.log
~/.local/share/xorg/Xorg.0.log
~/.xsession-errors

ただし、ログの保存場所や~/.xsession-errorsの有無は、ディストリビューション、ディスプレイマネージャ、systemdとの統合状況によって異なります。現在はjournalctlに記録される場合も多いため、次の確認も重要です。

journalctl -b

グラフィカルログインのトラブルシューティング

ログイン画面が表示されない

次の項目を確認します。

• 既定のターゲットがgraphical.targetか

systemctl get-default

• ディスプレイマネージャが起動しているか

systemctl status display-manager

• 起動時のログにエラーがないか

journalctl -u display-manager -b

• X.orgまたはGPUドライバにエラーがないか

grep -E '\((EE|WW)\)' /var/log/Xorg.0.log

EEはエラー、WWは警告を表します。ただし、ログが別の場所にある場合もあります。

ログイン後、すぐにログイン画面へ戻る

この現象は「ログインループ」と呼ばれることがあります。代表的な原因は次のとおりです。

• デスクトップセッションの起動失敗
• ホームディレクトリの所有者やアクセス権の異常
• ディスク容量またはinodeの不足
• ~/.Xauthorityや~/.ICEauthorityの所有者・アクセス権の異常
• シェルの初期化ファイルにおけるエラー
• デスクトップ環境やGPUドライバの不整合

ディスク容量は次のように確認します。

df -h
df -i

ホームディレクトリや認証ファイルの所有者も確認します。

ls -ld "$HOME"
ls -l ~/.Xauthority ~/.ICEauthority

.Xauthorityを安易に削除するのではなく、まず所有者やログを確認することが重要です。また、Waylandセッションでは.Xauthorityが直接の原因ではない場合があります。

GUIアプリケーションだけ起動できない

次の項目を確認します。

echo "$DISPLAY"
echo "$XDG_SESSION_TYPE"
xauth list

sudoやsuの後だけ起動できない場合は、接続先のXサーバーや認証情報を引き継げていない可能性があります。

主要なデスクトップ環境

デスクトップ環境とは、ウィンドウ管理機能に加えて、パネル、ファイルマネージャ、設定ツール、各種アプリケーションなどを統合したソフトウェア一式です。

厳密には、KDEはソフトウェアを開発するコミュニティやプロジェクトの名称で、デスクトップ環境はKDE Plasmaです。ただし、試験問題や一般的な説明では、単に「KDE」と表記される場合もあります。

また、GNOMEやKDE PlasmaはX11だけでなくWaylandでも動作します。利用可能なセッションは、ディストリビューションやバージョンによって異なります。

LPICレベル1では、各環境の細かなカスタマイズ手順よりも、次のような大まかな位置付けを理解しておくことが重要です。

• GNOMEとXfceは主にGTKを利用する
• KDE PlasmaはQtを利用する
• Xfceは比較的軽量
• デスクトップ環境とディスプレイマネージャは別の構成要素である

リモートデスクトップへアクセスするためのプロトコル

XDMCP

XDMCP（X Display Manager Control Protocol）は、Xサーバーがネットワーク上のディスプレイマネージャへ問い合わせ、リモートログイン画面やXセッションを利用するためのプロトコルです。

伝統的にUDPポート177番を使用します。

XDMCPでは、接続元の端末でXサーバーが動作し、リモート側で実行されたXクライアントの画面を手元のXサーバーへ表示します。そのため、画面全体を画像として転送するVNCとは仕組みが異なります。

XDMCP自体は通信を安全に暗号化しないため、信頼できないネットワークやインターネットへ直接公開するべきではありません。現在は、SSHのX11転送、VNC、RDPなどの利用が一般的です。

VNC

VNC（Virtual Network Computing）は、RFB（Remote Framebuffer）プロトコルに基づくリモートデスクトップの仕組みです。

サーバー側から画面の内容を転送し、クライアント側からキーボードやマウスの操作を送り返します。Linux、Windows、macOSなど、異なるOS間でも利用できます。

VNCには、主に次の利用形態があります。

• 既存のデスクトップ画面を共有する
• 接続ごとに仮想デスクトップセッションを作成する

伝統的なVNCサーバーでは、次の規則でTCPポートが割り当てられます。

5900 + VNCディスプレイ番号

ただし、これは代表的な規則であり、実際のポート番号はVNCサーバーの実装や設定によって変更できます。また、VNCのディスプレイ番号と、物理画面で動作するXサーバーのDISPLAYが必ず一致するとは限りません。

VNC実装によっては通信の暗号化が十分でないため、SSHトンネルやVPN、TLS対応の実装と組み合わせることがあります。

SPICE

SPICE（Simple Protocol for Independent Computing Environments）は、主にQEMU/KVMなどの仮想マシンのコンソールへアクセスするためのプロトコルです。

仮想化基盤との統合を前提としており、次のような機能を扱えます。

• 仮想マシンの画面表示
• キーボード・マウス入力
• 音声
• クリップボード共有
• USBデバイスのリダイレクト

VNCやRDPのような一般的なリモートデスクトップにも似ていますが、試験対策としては、SPICEは特に仮想マシンのコンソール接続で使われると覚えておくとよいでしょう。

RDP

RDP（Remote Desktop Protocol）は、Microsoftが開発したリモートデスクトッププロトコルです。Windows環境で標準的に使われています。

代表的なポート番号は3389番です。一般にTCP 3389番が使われ、現在の実装では性能向上のためUDP 3389番も併用されることがあります。

Linuxでは、xrdpなどを使ってRDPサーバーを構築できます。これにより、Windowsの標準的なリモートデスクトップクライアントからLinuxのデスクトップへ接続できます。