リモートマシンのgnuplotでX11が動かない場合の対処法
サーバーの環境：Fedora 36
サーバーのLinux環境は以下の通り．
$ cat /etc/os-release
NAME="Fedora Linux"
VERSION="36 (Server Edition)"
ID=fedora
VERSION_ID=36
VERSION_CODENAME=""
PLATFORM_ID="platform:f36"
PRETTY_NAME="Fedora Linux 36 (Server Edition)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:36"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f36/system-administrators-guide/"
SUPPORT_URL="https://ask.fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=36
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=36
PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
VARIANT="Server Edition"
VARIANT_ID=server
X11フォワーディング
gnuplotをはじめとするグラフィックを使うアプリケーションをリモートマシンで動作させる場合，自分のPCでXquartz（X11）を起動させてグラフィックの表示に使うのが常である．リモートアプリケーションの命令がsshを通して自分のPCに送られ，その命令をXquartzが描画する流れだ．これはsshのX11 ポートフォワーディングを使って可能になる．具体的にはXオプションまたはYオプション（こっちはtrusted x11）をつける．
ssh -X username@remotehost
ssh -Y username@remotehost
または.ssh/configファイルに
ForwardX11 yes # X option
Forwardx11trusted yes # Y option
を追記しても良い．
今回はこのようにXまたはYオプションをつけてもX11転送がうまくいかなかったのでその場合の対処について．
1 ローカルマシンの設定の変更
もし問題が起こっているサーバーが自分が管理しているサーバーではない場合，その原因は（多分サーバーは専門家が管理しているだろうから）自分のローカルマシンのことが多いと思う．
自分の場合はまさにこれで，サーバー上でInvalid MIT-MAGIC-COOKIE-1 keyと表示される問題が発生した．この場合，ローカルマシンでxhostの設定を確認する．このコマンドはXサーバへのアクセスの許可不許可を設定する．
$ xhost
xhost
access control enabled, only authorized clients can connect
LOCAL:
このように表示されればローカルホストが追加されていて大丈夫だが，もし何もなければ
$ xhost +local:
でローカルホストを追加する．これで再度ssh接続して問題なければOK．
2 : 自分がサーバー管理者の場合の/etc/ssh/ssh_configの確認
自分がサーバー管理者の場合，サーバーのsshの設定でX11フォワードを許可しないといけない．このためには/etc/ssh/ssh_configファイルに以下の2行を追記する．
X11Forwarding yes
# ForwardX11Trusted yes これはTrustedX11を許可する場合にyesにする．
X11UseLocalhost no ← これが重要？
X11Forwardingが最も重要で，これがX11フォワードを許可する設定で必須．ForwardX11Trustedを許可するかどうかは時と場合によってだと思うので今回は触れない．
最後のX11UseLocalhostはオプションで，サーバーの設定によってyesかnoかで結果が違うことがあるように思う．まず，このオプションはDISPLAY環境変数の設定に影響する．この環境変数はXクライアントがどのXサーバーに接続するかを指定するもので，
hostname:D.S
という形をとる．ここで
- hostname: Xサーバーが走っているマシン（ここだとリモートサーバー）
- D: Sequence number，0のことが多い．
- S: Screen number, 0のことが多い．
X11UseLocalhostをyesとした場合，
$ echo $DISPLAY
localhost:10.0
のようにhostname部分がlocalhostになる．一方でX11UseLocalhostをnoにするとここには直接IPが入って
$ echo $DISPLAY
10.0.5.251:10.0
のようになる．どちらが良いかは環境によりそうで，自分のサーバーではnoにしたところうまく行ったのでそれを利用しているが原因は不明． もちろん，環境変数を直接手で
export DISPLAY=localhost:0.0
のように指定することも可能なのでトラブルシューティング時に活用されたい．
さて，以上の要領でssh_configファイルを編集したらsshdデーモンを再起動する．
sudo systemctl restart sshd
一度ログアウトしてから再度ログインしてX11転送が成功していればOK．
3：X11の調査に有用なアプリ
ちなみにこの調査をやる時にはxeyesという可愛いグラフィックを表示するアプリがおすすめ．Fedoraだと
# インストール
$ sudo dnf -y install x11-apps
# 起動
$ xeyes
とすれば良い．
4 qtがうまく動かない場合
gnuplotでX11同様qtも動かなかったので，その対処法．今回はqtのライブラリのパスの設定がおかしかったことが原因だった．
まず，gnuplotで
gnuplot
> plot x
とすると
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
となって止まってしまう問題が発生した．まずはexport QT_DEBUG_PLUGINS=1という環境変数を設定してから再度実行する．すると
Got keys from plugin meta data ("vnc")
QFactoryLoader::QFactoryLoader() looking at "/usr/lib64/qt5/plugins/platforms/libqxcb.so"
Found metadata in lib /usr/lib/qt/plugins/platforms/libqxcb.so, metadata=
...略
のようにデバック表示をしてくれる．今回はこれでlibqxcb.soというライブラリをロードする時に問題があることがわかったので，このライブラリのリンクが大丈夫かどうかをlddコマンドで確認する．
$ ldd /usr/lib64/qt5/plugins/platforms/libqxcb.so
ここでリンクしているライブラリの一覧がずらずら出てくるが，そこにnot foundとあった場合，依存しているライブラリが見つかっていないことを意味する．これはpathの設定（LD_LIBRARY_PATH）がおかしいか，そもそもそのライブラリがインストールされていないかの二つの可能性がある．前者なら
ライブラリの場所をfindやlocateコマンドを使って探した上で
export LD_LIBRARY_PATH=/usr/lib64:$LD_LIBRARY_PATH
のような内容を.bash_profileに追記すれば良いし，ライブラリがインストールされていない場合は
dnf whatprovides ライブラリ名
としてライブラリが入っているパッケージを何かインストールすれば良い．そのほかに一応qt5とqt5-develの再インストールも試したがこちらは特に効果がなかった．
参考文献
https://forum.qt.io/topic/93247/qt-qpa-plugin-could-not-load-the-qt-platform-plugin-xcb-in-even-though-it-was-found