Как надежно подключить к сеансу DBUS через ssh?

Question

У меня вряд ли был какой-либо успех с использованием dbus-зависимого инструмента через ssh (например, pactl - интерфейс командной строки pulseaudio - который выбирает вывод звука).

Я знаю, как вручную экспортировать адрес DBUS сеанса в DBUS_SESSION_BUS_ADDRESS , но все равно почти любое приложение завершается ошибкой с сообщениями, например, об connection refused at pa_context_new() .

К сожалению, это хорошо подходит для всех оговорок в отношении dbus, kdbus (и systemd)...

Итак, какие шаги на самом деле требуются, чтобы любое приложение, зависящее от DBUS, работало с ssh так же, как это было бы из сеанса рабочего стола?
Есть ли какой-нибудь неброский, не подверженный ошибкам способ получить адрес шины, не полагаясь на скрипты на весь экран?
Что еще требуется - приложение с адреса - чтобы разрешить подключение?

Answer 1

pactl не зависит от D-Bus - это всего лишь один из различных методов, которые он может использовать для поиска управляющего сокета. Который теперь всегда находится в одном и том же месте - $XDG_RUNTIME_DIR/pulse/native (как в pulseaudio v3.0). Так что первоначальная жалоба просто не имеет смысла. Я уверен, что strace -e connect pactl info покажет, что ошибка "Отказ в соединении" возникла из-за попытки подключиться к самому импульсу, а не к D-Bus.

• Одна из возможных причин: если 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 - программу , которые делают зависеть от сеанса шины - есть три общих варианта:

• Чтобы подключиться к "новой" шине пользователя:

  Некоторые системы / дистрибутивы, возможно, уже перешли на модель "пользовательской шины", где вместо некоторого количества сессионных шин существует только одна для каждого UID. Его адрес:unix:path=/run/user/$UID/bus с dbus-daemon или kernel:path=/sys/fs/kdbus/$UID-user/bus с kdbus.

  Последние версии sd-bus, libdbus, gdbus будут автоматически пытаться использовать этот адрес, если не установлены ни $ DBUS_SESSION_BUS_ADDRESS, ни $ DISPLAY. Это делает модель "пользовательской шины" наиболее надежным ответом на ваш первый вопрос, так как все, что вам нужно знать, это ваш собственный UID. (Большинство подходов, использующих традиционную модель "сессионной шины", не могут быть надежными, поскольку их может быть любое количество, а не один ...)

• Чтобы подключиться к "традиционной" сессионной шине:

  Адрес шины сеанса обычно выбирается случайным образом, чтобы избежать конфликтов. Однако для различных целей (в первую очередь для функции "автозапуск шины") адрес сохраняется в ~/.dbus/session-bus/$MACHINE_ID-$DISPLAY (прибл.).

  Таким образом, вы можете вручную установить $ DBUS_SESSION_BUS_ADDRESS, как и раньше, но вместо этого вы также можете установить $ DISPLAY, и программа найдет подходящую шину сеанса на основе дисплея X11.

• Чтобы начать новый (выделенный) сеанс шины:

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