Linux: o wmctrl não pode abrir a tela quando a sessão é iniciada via tela ssh +

Question

Estou usando o wmctrl em uma máquina Ubuntu para gerenciar janelas a partir de um script, que corro dentro de uma tela (gnu).

Se eu iniciar a sessão de tela a partir da máquina local, o wmctrl funciona bem, inclusive se eu fechar completamente a janela do terminal e emitir os comandos wmctrl ao conectar-se à tela remotamente via ssh. Por outro lado, se eu me conectar remotamente com o ssh e iniciar uma tela, o wmctrl não funcionará (retorna "Não é possível abrir a exibição") mesmo se eu anexar essa sessão de tela localmente no Terminal do Ubuntu.

Eu acho que há algum parâmetro de tela oculta que não é definido de uma forma que permite acessar a tela quando é lançado remotamente - qualquer idéia do que é e como modificá-lo de dentro de uma sessão remota de tela ssh que o script pode acessar as janelas?

    

Answer 1

DISPLAY e AUTORIDADE

Um programa X precisa de duas informações para se conectar a um display X. (Observe que wmctrl é um programa X, mesmo que acesse as janelas de outros processos em vez de criar suas próprias).

• Ele precisa do endereço da exibição, que normalmente é :0 quando você está conectado localmente ou :10 , :11 , etc. quando você está conectado remotamente (mas o número pode mudar dependendo de quantas conexões X estão ativas). O endereço da exibição é normalmente indicado na variável de ambiente DISPLAY .

• Precisa da senha para a exibição. X senhas de exibição são chamadas de cookies mágicos . Cookies mágicos não são especificados diretamente: eles são sempre armazenados em arquivos de autoridade X, que são uma coleção de registros do formulário “display :42 has cookie 123456 ”. O arquivo de autoridade X é normalmente indicado na variável de ambiente XAUTHORITY . Se $XAUTHORITY não estiver definido, os programas usarão ~/.Xauthority .

Dentro de uma sessão de tela, as variáveis de ambiente são determinadas quando a sessão é iniciada, a menos que você as altere explicitamente em algum momento. Portanto, se você iniciar uma sessão de tela localmente em sua máquina de desktop e, em seguida, anexar a essa sessão remotamente, $DISPLAY e $XAUTHORITY ainda estarão apontando para a sua máquina desktop. Mas se você iniciar a sessão de tela a partir de uma conexão ssh de alguma máquina C para a sua máquina desktop, então as variáveis não serão configuradas. (Eles seriam configurados para apontar para C se você tivesse um servidor X em C e tivesse ativado o encaminhamento de X pela sessão ssh).

Obtendo os valores das variáveis

Tanto quanto eu entendo, você está tentando agir nas janelas que são exibidas na sua área de trabalho. Se você for a única pessoa que usa sua máquina de desktop, é muito provável que o nome de exibição seja :0 . Encontrar a localização do arquivo de autoridade X é mais difícil (sob a configuração padrão no Ubuntu, ele está em um arquivo com um nome gerado aleatoriamente).

Aqui estão algumas maneiras de obter os valores de DISPLAY e XAUTHORITY :

• A solução fácil é sempre iniciar uma sessão de tela a partir de sua área de trabalho, talvez automaticamente em seus login scripts (de ~/.profile ; mas faça isso apenas se efetuar login em X: teste se DISPLAY estiver definido como um valor inicial com : (que deve cobrir todos os casos que você provavelmente encontrará). Em ~/.profile :

  case $DISPLAY in
    :*) screen -S local -d -m;;
  esac
  

  Na sessão ssh:

  screen -d -r local
  

• Você também pode salvar os valores de DISPLAY e XAUTHORITY em um arquivo e recuperar os valores. Em ~/.profile :

  case $DISPLAY in
    :*) export | grep -E ' (DISPLAY|XAUTHORITY)=' >~/.local-display-coordinates.sh;;
  esac
  

  Na sessão ssh:

  . ~/.local-display-coordinates.sh
  screen
  

• Você pode detectar os valores de DISPLAY e XAUTHORITY de um processo em execução. Isso é mais difícil de automatizar. Você precisa descobrir o PID de um processo conectado à exibição na qual deseja trabalhar e, em seguida, obter as variáveis de ambiente em /proc/$pid/environ ( eval export $(</proc/$pid/environ tr \0 \n | grep -E '^(DISPLAY|XAUTHORITY)=') ¹).

Copiando os cookies

Outra abordagem (seguindo uma sugestão da Arrowmaster é não tente obter o valor de $XAUTHORITY na sessão ssh, mas, em vez disso, faça a sessão X copiar seus cookies em ~/.Xauthority . Como os cookies são gerados sempre que você efetua login, não é um problema se você manter os valores obsoletos em ~/.Xauthority .

Pode haver um problema de segurança se o seu diretório pessoal estiver acessível via NFS ou outro sistema de arquivos de rede que permita que administradores remotos visualizem seu conteúdo. Eles ainda precisam se conectar à sua máquina de alguma forma, a menos que você tenha habilitado as conexões X TCP (o Debian as descarta por padrão). Portanto, para a maioria das pessoas, isso não se aplica (sem NFS) ou não é um problema (não há conexões X-TCP).

Para copiar cookies quando você fizer login na sua sessão X de área de trabalho, adicione as seguintes linhas a ~/.xprofile ou ~/.profile (ou algum outro script que seja lido quando você efetuar login):

case :$DISPLAY:$XAUTHORITY in
  :*:?*) XAUTHORITY=~/.Xauthority xauth merge "$XAUTHORITY";;
esac

Então, dentro da tela, você terá apenas setenv DISPLAY :0 (ou qualquer que seja o número de exibição, mas é provável que seja :0 conforme explicado acima).

¹ Em princípio, isto não possui uma cotação apropriada, mas nesta instância específica, $DISPLAY e $XAUTHORITY não conterão nenhum metacaractere de casca.

    

Answer 2

Se você quiser apenas executar um único comando, provavelmente conseguirá isso:

env DISPLAY=:0 XAUTHORITY=/home/UserOfDesktop/.Xauthority wmctrl -r "Firefox" -e 0,0,0,1920,1080

Certificar-se de alterar DISPLAY =: 0 para a área de trabalho que você deseja manipular e UserOfDesktop para o nome do usuário que está executando a sessão X.