web-dev-qa-db-ja.com

Linux：セッションがssh + screenを介して開始された場合、wmctrlは表示を開くことができません

私はUbuntuマシンでwmctrlを使用して、（gnu）画面内で実行するスクリプトからウィンドウを管理しています。

ローカルマシンから画面セッションを開始すると、ターミナルウィンドウを完全に閉じて、sshを介してリモートで画面に接続するときにwmctrlコマンドを発行する場合を含め、wmctrlは正常に機能します。逆に、sshにリモート接続して画面を起動すると、Ubuntuターミナルからローカルにその画面セッションを接続してもwmctrlが機能しません（「ディスプレイを開けません」を返します）。

リモートで起動したときにディスプレイにアクセスできるように設定されていない非表示の画面パラメータがあると思います-それが何であるか、リモートのssh-screenセッション内からディスプレイを変更する方法スクリプトはウィンドウにアクセスできますか？

linuxubuntusshgnu-screengdm
7
GJ.

表示と権限

Xプログラムは、Xディスプレイに接続するために2つの情報を必要とします。 （wmctrlは、独自のプロセスを作成するのではなく、他のプロセスのウィンドウにアクセスする場合でも、Xプログラムであることに注意してください。）

  • ディスプレイのアドレスが必要です。これは通常、ローカルでログインしている場合は_:0_、リモートでログインしている場合は_:10_、_:11_などです（ただし、番号はアクティブなX接続の数に応じて変更します）。ディスプレイのアドレスは通常、DISPLAY環境変数で示されます。

  • 表示にはパスワードが必要です。 Xディスプレイパスワードはマジッククッキーと呼ばれます。マジッククッキーは直接指定されません。それらは常に「display _:42_ has cookie _123456_」という形式のレコードのコレクションであるX典拠ファイルに保存されます。 X典拠ファイルは通常、XAUTHORITY環境変数で示されます。 _$XAUTHORITY_が設定されていない場合、プログラムは_~/.Xauthority_を使用します。

スクリーンセッション内では、ある時点で明示的に変更しない限り、セッションの開始時に環境変数が決定されます。したがって、デスクトップマシンでローカルに画面セッションを開始し、そのセッションにリモートで接続すると、_$DISPLAY_と_$XAUTHORITY_は引き続きデスクトップマシンを指します。ただし、あるマシンCからデスクトップマシンへのssh接続から画面セッションを開始する場合、変数は設定されません。 （C上にXサーバーがあり、sshセッションを介したX転送を有効にしている場合は、Cを指すように設定されます。）

変数の値を取得する

私の知る限り、あなたはデスクトップに表示されているウィンドウを操作しようとしています。デスクトップマシンを使用しているのがあなただけの場合、表示名は_:0_である可能性が非常に高くなります。 X典拠ファイルの場所を見つけるのは困難です（Ubuntuのデフォルト設定では、ランダムに生成された名前のファイル内にあります）。

DISPLAYとXAUTHORITYの値を取得するいくつかの方法を次に示します。

  • 簡単な解決策は、常にデスクトップから、おそらくログインスクリプトで自動的に（_~/.profile_から）スクリーンセッションを開始することです。ただし、Xでログインする場合にのみ実行します。DISPLAYがに設定されているかどうかをテストします。 _:_で始まる値（遭遇する可能性のあるすべてのケースをカバーする必要があります））。 _~/.profile_：

    _case $DISPLAY in
  :*) screen -S local -d -m;;
esac
_

    Sshセッションの場合：

    _screen -d -r local
_

  • DISPLAYとXAUTHORITYの値をファイルに保存して、値を呼び出すこともできます。 _~/.profile_：

    _case $DISPLAY in
  :*) export | grep -E ' (DISPLAY|XAUTHORITY)=' >~/.local-display-coordinates.sh;;
esac
_

    Sshセッションの場合：

    _. ~/.local-display-coordinates.sh
screen
_

  • 実行中のプロセスからDISPLAYとXAUTHORITYの値を検出できます。これは自動化するのが難しいです。作業したいディスプレイに接続されているプロセスのPIDを把握してから、_/proc/$pid/environ_（eval export $(</proc/$pid/environ tr \\0 \\n | grep -E '^(DISPLAY|XAUTHORITY)=')¹）から環境変数を取得する必要があります。

クッキーのコピー

別のアプローチ（ Arrowmasterによる提案 に従うことは、sshセッションで_$XAUTHORITY_の値を取得しようとせず、代わりにXセッションにCookieを_~/.Xauthority_にコピーさせることです。 。Cookieはログインするたびに生成されるため、_~/.Xauthority_に古い値を保持しても問題ありません。

リモート管理者がその内容を表示できるようにするNFSまたはその他のネットワークファイルシステムを介してホームディレクトリにアクセスできる場合は、セキュリティの問題が発生する可能性があります。 X TCP接続を有効にしない限り、何らかの方法でマシンに接続する必要があります（Debianではデフォルトでオフになっています）。したがって、ほとんどの人にとって、これも当てはまりません（ NFS）または問題ではありません（X TCP接続なし）。

デスクトップXセッションにログインするときにCookieをコピーするには、次の行を_~/.xprofile_または_~/.profile_（またはログイン時に読み取られるその他のスクリプト）に追加します。

_case :$DISPLAY:$XAUTHORITY in
  :*:?*) XAUTHORITY=~/.Xauthority xauth merge "$XAUTHORITY";;
esac
_

次に、画面内で_setenv DISPLAY :0_（または表示番号は何でも）だけで済みますが、上記で説明したように_:0_である可能性があります。

¹原則として、これには適切な引用符がありませんが、この特定のインスタンスでは、_$DISPLAY_および_$XAUTHORITY_にはシェルメタ文字が含まれません。

11
Gilles 'SO- stop being evil'

1つのコマンドを実行したいだけの場合は、おそらくこれで回避できます。

env DISPLAY=:0 XAUTHORITY=/home/UserOfDesktop/.Xauthority wmctrl -r "Firefox" -e 0,0,0,1920,1080

DISPLAY =：0を操作するデスクトップに変更し、UserOfDesktopをXセッションを実行しているユーザーの名前に変更してください。

5
Alex R