web-dev-qa-db-ja.com

ssh経由でセッションDBUSに確実に接続するにはどうすればよいですか？

Ssh上でdbus依存ツールを使用してもほとんど成功しませんでした（たとえば、オーディオ出力を選択するpactl --pulseaudioコマンドラインインターフェイス-）。

セッションのDBUSアドレスを手動で_DBUS_SESSION_BUS_ADDRESS_にエクスポートする方法を知っていますが、それでもほとんどすべてのアプリケーションがconnection refused at pa_context_new()のようなメッセージで失敗します。

悲しいことに、これはdbus、kdbus（およびsystemd）に対するすべての予約にうまく適合します...

では、デスクトップセッションの場合と同じように、DBUSに依存するアプリケーションをsshで実行するには、実際にどのような手順が必要ですか？
画面の長いスクリプトに依存せずにバスアドレスを取得するための、不安定でエラーが発生しにくい方法はありますか？
接続を許可するには、他に何が必要ですか（アドレスからのアパート）？

linuxsshdbus
4
dronus

pactlはD-Busに依存しません –これは制御ソケットを見つけるために使用する可能性のあるさまざまな方法の1つにすぎません。これは常に同じ場所にあります– $XDG_RUNTIME_DIR/Pulse/native（pulseaudio v3.0以降）。したがって、元の苦情は単純に意味がありません。 strace -e connect pactl infoは、「接続が拒否されました」というエラーが、D-Busではなくpulseaudio自体に接続しようとしたことによるものであることを明らかにすると確信しています。

  • 考えられる原因の1つ：straceがpactlがユーザーごとのパスの代わりに/var/run/Pulse/nativeを使用しようとしていることを示している場合、$ XDG_RUNTIME_DIRが設定されていない可能性があります。手動で（/run/user/$UIDに）設定することもできますが、自動的に設定されない理由を理解することをお勧めします。

    $ XDG_RUNTIME_DIR変数はpam_systemd.soによって設定されます。 /etc/pam.d/sshd構成ファイルが最終的にそのモジュールをリストすることを確認します（場合によっては直接ですが、system-loginやcommon-sessionなどのサブ構成を含めることによってより頻繁に）。

そうは言っても、SSH経由でotherプログラムを使用する必要がある場合–doセッションバスに依存–3つの一般的なオプションがあります。

  • 「新しい」ユーザーバスに接続するには：

    一部のシステム/ディストリビューションはすでに「ユーザーバス」モデルに移行している可能性があります。このモデルでは、いくつかのセッションバスの代わりに、各UIDに1つしかありません。そのアドレスは、dbus-daemonの場合はunix:path=/run/user/$UID/bus、kdbusの場合はkernel:path=/sys/fs/kdbus/$UID-user/busです。

    $ DBUS_SESSION_BUS_ADDRESSも$ DISPLAYも設定されていない場合、最新バージョンのsd-bus、libdbus、gdbusは自動的にこのアドレスを試します。これにより、「ユーザーバス」モデルが最初の質問に対する最も信頼できる回答になります。知る必要があるのは自分のUIDだけだからです。 （従来の「セッションバス」モデルを含むほとんどのアプローチは信頼できません。1つではなく、いくつでも存在する可能性があるためです...）

  • 「従来の」セッションバスに接続するには：

    セッションバスアドレスは通常、競合を避けるためにランダムに選択されます。ただし、さまざまな目的（主に「バス自動起動」機能）のために、アドレスは~/.dbus/session-bus/$MACHINE_ID-$DISPLAY（約）に格納されます。

    したがって、以前のように手動で$ DBUS_SESSION_BUS_ADDRESSを設定できますが、代わりに$ DISPLAYを設定することもでき、プログラムはX11ディスプレイに基づいて一致するセッションバスを見つけます。

  • new（専用）セッションバスを開始するには：

    dbus-launch --exit-with-session /bin/bash
6
user1686