24

Banshee 音楽プレーヤーを再生および一時停止するための簡単な Python プログラムを作成しました。自分のマシンで作業している間、同じルーター (LAN) に接続されているリモート コンピューターに対して行うのに問題があります。リモート マシンの session.conf を編集して、次の行を追加しました。

<listen>tcp:host=localhost,port=12434</listen>

ここに私のプログラムがあります:

    import dbus


    bus_obj=dbus.bus.BusConnection("tcp:host=localhost,port=12434")
    proxy_object=bus_obj.get_object('org.bansheeproject.Banshee',                              
    '/org/bansheeproject/Banshee/PlayerEngine')

    playerengine_iface=dbus.Interface(proxy_object,
    dbus_interface='org.bansheeproject.Banshee.PlayerEngine')

    var=0

    while (var!="3"):
        var=raw_input("\nPress\n1 to play\n2 to pause\n3 to exit\n")


            if var=="1":
                print "playing..."
                playerengine_iface.Play()

            elif var=="2":
                print "pausing"
                playerengine_iface.Pause()

これは私がそれを実行しようとすると得られるものです

Traceback (most recent call last):
  File "dbus3.py", line 4, in <module>
    bus_obj=dbus.bus.BusConnection("tcp:host=localhost,port=12434")
  File "/usr/lib/python2.7/dist-packages/dbus/bus.py", line 125, in __new__
    bus = cls._new_for_bus(address_or_type, mainloop=mainloop)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoServer: Failed to connect to socket "localhost:12434" Connection refused

ここで何が間違っていますか?/usr/lib/python2.7/dist-packages/dbus/bus.py を編集する必要がありますか?

アップデート:

わかりました、これは私が追加したときの取引です

<listen>tcp:host=192.168.1.7,port=12434</listen>

/etc/dbus-1/session.confに移動してから再起動し、再起動時にリッスンを開始することを期待していますが、起動しません。ロード画面でスタックし、時折、次のテキストが表示された黒い画面が点滅します。

Pulseaudio Configured For Per-user Sessions Saned Disabled;edit/etc/default/saned

そのため、ctrl+alt+f1 に移動し、session.conf を元の状態に変更して再起動すると、正常に起動します。

それは何ですか?問題が発生することなく、dbus デーモンが tcp 接続をリッスンするようにするにはどうすればよいですか?

4

3 に答える 3

39

私は最近、これを設定する必要があり、その秘訣は次のとおりであることを発見しました:の要素の順序が重要です。TCP 要素が最初に出現することを確認する必要があります。奇妙なことは知っていますが、少なくとも私の場合は真実です。(順序を逆にして UNIX ソケット要素を最初に配置すると、まったく同じ黒い画面の動作が見られます。)<listen>session.conf<listen>

また、TCP<listen>タグを先頭に追加する必要がありますが、十分ではありません。TCP 経由のリモート D-Bus 接続を機能させるには、次の 3 つのことを行う必要があります。

  1. <listen>次のように、UNIX のタグの上にタグを追加します。

    <listen>tcp:host=localhost,bind=*,port=55556,family=ipv4</listen>
    <listen>unix:tmpdir=/tmp</listen>
    
  2. 次の行を追加します (<listen>タグのすぐ下で問題ありません)。

    <auth>ANONYMOUS</auth>
    
  3. これらの下に次の行を追加します。

    <allow_anonymous/>
    

に含まれている可能性のある<auth>他のタグに加えて、タグを追加する必要があります。要約すると、次のようなスニペットを含める必要があります。<auth>session.confsession.conf

<listen>tcp:host=localhost,bind=*,port=55556,family=ipv4</listen>
<listen>unix:tmpdir=/tmp</listen>

<auth>ANONYMOUS</auth>
<allow_anonymous/>

これら 3 つのことを実行すると、セッション バスにリモートで接続できるようになります。D-Feetでリモート接続を指定すると、次のようになります。

D フィートのスクリーン キャプチャ

システムバスにも接続したい場合は、 に同様の変更を加える必要/etc/dbus-1/system.confがありますが、別のTCP ポート (たとえば 55557) を指定する必要があることに注意してください (奇妙なことに、この場合、要素の順序は重要ではないようです)。

この構成で私が気付いた唯一の奇妙な動作は、sudo(たとえばsudo gvim) でデスクトップ アプリを実行すると、エラーが発生したり、「D-BUS デーモンが実行されていません」と言って完全に失敗したりする傾向があることです。しかし、これは私が行う必要があることであり、ほとんど問題にならないほどめったにありません。

を使用してリモート マシンに送信する場合は、それに応じdbus-sendて設定する必要がありますDBUS_SESSION_BUS_ADDRESS。たとえば、次のように設定します。

export DBUS_SESSION_BUS_ADDRESS=tcp:host=localhost,bind=*,port=55556,family=ipv4

これは、送信先のバスが実際にはリモート マシンのシステム<listen>バスであっても、設定がターゲットの TCPタグと一致する限り機能します/etc/dbus-1/system.conf。(このヒントを提供してくれたMartin Vidnerに感謝します。この質問に対する彼の回答に出くわすまで、dbus-sendリモート操作がサポートされているとは思いませんでした。)

更新: systemd を使用している (そしてシステム バスにアクセスしたい) 場合は、次のようListenStream=55557に toという行を追加する必要がある場合もあります。/lib/systemd/system/dbus.socket

[Socket]
ListenStream=/var/run/dbus/system_bus_socket
ListenStream=55557  # <-- Add this line

UPDATE2 : D-Bus の最近のバージョンでは、利用可能なシステムでAppArmorメディエーションが有効になることを指摘してくれた @altagir に感謝し<apparmor mode="disabled"/>ます。session.confsystem.conf

于 2012-11-07T18:35:58.937 に答える
7

dbus 1.6.12 (例: kubuntu 13.10) 以降、dbus 構成ファイル (/etc/dbus-1/ mybus .confまたはリモート アクセスを必要とするインターフェイス、つまり system.d/ my. interface.conf )

<apparmor mode="disabled"/>

更新:サービスがカスタム dbus-daemon に接続できるようにする apparmor プロファイルの作成に苦労した後、DBUS のバグが原因で接続が常に拒否されるようです...したがって、 tcp= を使用するときは常に apparmor を無効にする必要があります。 .. 14.04 を対象としたバグ修正

ここで Tyler Hicks と議論した後、 bugs.launchpad.netでバグを開きました。

AppArmor メディエーション コードには、UNIX ドメイン ソケットを介してピア ラベルをチェックする機能しかありません。ラベルを取得してから接続を拒否すると、エラーが発生する可能性が最も高くなります。

注: disable フラグは dbus < 1.6.12 では認識されないため、systen に応じて異なるバージョンの mydaemon.conf をパッケージ化する必要があります)。そうしないと、apparmor がない場合、dbus-daemon は起動時に失敗します...私の CMakeLists.txt :

IF(EXISTS "/usr/sbin/apparmor_status")
  install(FILES dbus_daemon-apparmordisabled.conf RENAME dbus_daemon.conf DESTINATION /etc/dbus-1/ )
ELSE (EXISTS "/usr/sbin/apparmor_status")
   install(FILES dbus_daemon.conf DESTINATION /etc/dbus-1/ )
ENDIF(EXISTS "/usr/sbin/apparmor_status")
于 2013-11-15T23:04:25.350 に答える
3

もう1つの感謝@Shorin、および別の参考までに-私は私の仕事をするためにこのようなことをしなければなりませんでした:

<listen>tcp:host=localhost,bind=0.0.0.0,port=55884</listen>

注意してくださいbind=0.0.0.0-bind=*私にはうまくいかなかったので、そのfamily=ipv4部分を省略しました。私はUbuntu 12.04を使用しています。リモートマシンでnetstatを使用して、dbusがポートでリッスンしていることを確認し、ローカルからtelnetを使用してポートが開いていることを確認しました。

netstat -plntu | grep 55884

tcp   0     0 0.0.0.0:55884    0.0.0.0:*     LISTEN    707/dbus-daemon

0 0.0.0.0:55884のようなものではなく、のようなものを見る必要があります0 127.0.0.1:55884

于 2013-11-29T03:30:00.437 に答える