Wie verlässt man sich zuverlässig mit Session-DBUS über ssh?

3082
dronus

Ich hatte kaum Erfolg mit einem dbus-abhängigen Tool über ssh (zum Beispiel pactl- pulseaudio command line interface - das wählt die Audioausgabe).

Ich weiß, wie man die DBUS-Adresse der Sitzung manuell exportiert DBUS_SESSION_BUS_ADDRESS, aber trotzdem scheitert fast jede Anwendung mit Meldungen wie connection refused at pa_context_new().

Das passt leider gut zu allen Vorbehalten gegen dbus, kdbus (und systemd) ...

Welche Schritte sind also tatsächlich erforderlich, damit jede Anwendung, die von DBUS abhängt, über ssh läuft, genau wie bei der Desktopsitzung?
Gibt es eine nicht flockige, nicht fehleranfällige Möglichkeit, die Busadresse zu erhalten, ohne sich auf lange Bildschirmskripts zu verlassen?
Was ist noch erforderlich - von der Adresse aus -, um die Verbindung zuzulassen?

4
Vielleicht mische ich etwas zusammen ... Da _some_ dbus-Apps funktionieren, zB. der "d-feet" dbus viewer, ich denke, es hat mehr mit pulseaudio-buchsen zu tun als mit seinem dbus-anschluss. dronus vor 8 Jahren 0
Auf der anderen Seite verwendet pulseaudio dbus und sollte auch seine eigene Buchse finden und authentifizieren, wenn der richtige dbus verfügbar ist. dronus vor 8 Jahren 0

1 Antwort auf die Frage

5
grawity

pactl ist nicht auf D-Bus angewiesen - es ist nur eine der verschiedenen Methoden, die es zur Lokalisierung der Steuerungsbuchse verwenden kann. Welches ist jetzt immer am selben Ort - $XDG_RUNTIME_DIR/pulse/native(ab pulseaudio v3.0). Also macht die ursprüngliche Beschwerde einfach keinen Sinn. Ich bin mir sicher, dass strace -e connect pactl infodies zeigen würde, dass der Fehler "Verbindung abgelehnt" auf den Versuch zurückzuführen ist, sich mit pulseaudio selbst zu verbinden, nicht mit dem D-Bus.

  • Eine mögliche Ursache: Wenn strace zeigt, dass pactl /var/run/pulse/nativeanstelle des benutzerspezifischen Pfads verwendet wird, wurde $ XDG_RUNTIME_DIR möglicherweise nicht festgelegt. Sie können es manuell einstellen (bis /run/user/$UID), es ist jedoch besser herauszufinden, warum es nicht automatisch eingestellt wird.

    Die Variable $ XDG_RUNTIME_DIR wird von pam_systemd.so gesetzt. Stellen Sie sicher, dass Ihre /etc/pam.d/sshdKonfigurationsdatei dieses Modul schließlich auflistet (manchmal direkt, aber häufiger durch Hinzufügen einer Unterkonfiguration wie system-loginoder common-session).

Wenn Sie jedoch andere Programme über SSH verwenden müssen - Programme, die von einem Sitzungsbus abhängen - gibt es drei Möglichkeiten:

  • An den 'neuen' Benutzerbus anschließen:

    Einige Systeme / Distros sind möglicherweise bereits zum "User Bus" -Modell übergegangen, wobei anstelle einer Anzahl von Sitzungsbussen nur einer für jede UID vorhanden ist. Seine Adresse lautet unix:path=/run/user/$UID/busbei dbus-daemon oder kernel:path=/sys/fs/kdbus/$UID-user/busbei kdbus.

    Neueste Versionen von sd-bus, libdbus, gdbus versuchen diese Adresse automatisch, falls weder $ DBUS_SESSION_BUS_ADDRESS noch $ DISPLAY gesetzt sind. Damit ist das "User Bus" -Modell die zuverlässigste Antwort auf Ihre erste Frage, da Sie nur Ihre eigene UID kennen müssen. (Die meisten Ansätze, die ein herkömmliches "Sitzungsbus" -Modell verwenden, können nicht zuverlässig sein, da es eine beliebige Anzahl davon geben kann, nicht genau eine ...)

  • An einen "traditionellen" Sitzungsbus anschließen:

    Die Sitzungsbusadresse wird normalerweise zufällig ausgewählt, um Konflikte zu vermeiden. Zu verschiedenen Zwecken (hauptsächlich für die Funktion "Bus Autolunch") wird die Adresse jedoch in ~/.dbus/session-bus/$MACHINE_ID-$DISPLAY(ca.) gespeichert .

    Sie können also $ DBUS_SESSION_BUS_ADDRESS wie zuvor manuell festlegen. Stattdessen können Sie auch $ DISPLAY festlegen. Das Programm wird den passenden Sitzungsbus anhand der X11-Anzeige finden.

  • So starten Sie einen neuen (dedizierten) Sitzungsbus:

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

Verwandte Probleme