Como conectar de forma confiável a sessão DBUS em ssh?

4

Eu dificilmente tive sucesso usando uma ferramenta dependente do dbus sobre o ssh (por exemplo pactl - interface de linha de comando pulseaudio - que seleciona a saída de áudio).

Eu sei exportar manualmente o endereço DBUS da sessão para DBUS_SESSION_BUS_ADDRESS , mas ainda assim quase qualquer aplicativo falha com mensagens como connection refused at pa_context_new() .

Isto, infelizmente, ajusta-se bem a todas as reservas contra dbus, kdbus (e systemd) ...

Então, quais etapas são realmente necessárias para que qualquer aplicativo, dependendo do DBUS, seja executado sobre o ssh, da mesma forma que na sessão de desktop?
Existe alguma maneira não flaky, não propensa a erros para obter o endereço de ônibus sem depender de scripts de tela longa?
O que mais é necessário - aparte do endereço - para permitir conexão?

    
por dronus 22.11.2015 / 15:30

1 resposta

5

pactl não depende do D-Bus - é apenas um dos vários métodos que podem ser usados para localizar o soquete de controle. Que agora está sempre no mesmo local - $XDG_RUNTIME_DIR/pulse/native (como de pulseaudio v3.0). Portanto, a queixa original simplesmente não faz sentido. Tenho certeza de que strace -e connect pactl info revelaria que o erro "Conexão recusada" vem de tentar conectar-se ao pulseaudio em si, não ao D-Bus.

  • Uma causa possível: Se strace mostrar o pactl tentando usar /var/run/pulse/native em vez do caminho por usuário, $ XDG_RUNTIME_DIR talvez não seja configurado. Você pode configurá-lo manualmente (para /run/user/$UID ), no entanto, seria melhor descobrir por que ele não está sendo definido automaticamente.

    A variável $ XDG_RUNTIME_DIR é definida por pam_systemd.so; Certifique-se de que o arquivo /etc/pam.d/sshd config eventualmente liste esse módulo (às vezes diretamente, mas com mais frequência incluindo uma subconfiguração como system-login ou common-session ).

Dito isto, quando você precisa usar outros programas através de SSH - programas que fazem dependem de um barramento de sessão - há três opções comuns:

  • Para anexar ao "novo" usuário:

    Alguns sistemas / distros podem já ter sido movidos para o modelo "user bus", onde, em vez de um número de buses de sessão, há apenas um para cada UID. Seu endereço é unix:path=/run/user/$UID/bus com dbus-daemon ou kernel:path=/sys/fs/kdbus/$UID-user/bus com kdbus.

    As versões mais recentes do sd-bus, libdbus, gdbus tentam automaticamente este endereço no caso de não estarem definidos $ DBUS_SESSION_BUS_ADDRESS nem $ DISPLAY. Isso faz com que o modelo "user bus" seja a resposta mais confiável para sua primeira pergunta, já que tudo que você precisa saber é seu próprio UID. (A maioria das abordagens que envolvem o modelo tradicional de "barramento de sessão" não pode ser confiável, já que pode haver um número delas, não exatamente uma ...)

  • Para anexar a um barramento de sessão 'tradicional':

    O endereço do barramento da sessão é geralmente escolhido aleatoriamente, para evitar conflitos. No entanto, para várias finalidades (principalmente para a função "autolaunch de barramento"), o endereço é armazenado em ~/.dbus/session-bus/$MACHINE_ID-$DISPLAY (aprox.).

    Portanto, você pode definir manualmente $ DBUS_SESSION_BUS_ADDRESS como antes, mas também pode definir $ DISPLAY, e o programa encontrará o barramento de sessão correspondente baseado na tela X11.

  • Para iniciar um novo barramento de sessão (dedicado):

    dbus-launch --exit-with-session /bin/bash
    
por 22.11.2015 / 16:11

Tags