it-swarm-eu.dev

Otevřete okno na vzdáleném X displeji (proč "Nelze otevřít displej")?

Bylo nebylo,

DISPLAY=:0.0 totem /path/to/movie.avi

po ssh 'ing do mého počítače z mého notebooku by způsobilo totem hrát movie.avi na ploše.

Nyní dává chybu:

No protocol specified
Cannot open display:

Nainstaloval jsem Debian squeeze, když to ustálilo na obou počítačích, a myslím, že jsem zlomil config.

Hleděl jsem na to a nemůžu za celý život přijít na to, co mám dělat.

(VLC má rozhraní HTTP, které funguje, ale není tak pohodlné jako ssh.)

Stejný problém vyvstává, když se to pokusím spustit z úlohy cron.

83
justin cress

(Přizpůsobeno z Linux: wmctrl nemůže otevřít displej, když relace zahájená pomocí ssh + obrazovky )

DISPLEJ A AUTORITA

Program X potřebuje k připojení k displeji X dvě informace.

  • Vyžaduje adresu displeje, což je obvykle :0, Když jste přihlášeni lokálně, nebo :10, :11 Atd., Pokud jste přihlášeni vzdáleně (ale číslo se může měnit v závislosti na tom, kolik připojení X je aktivní). Adresa displeje je obvykle uvedena v proměnné prostředí DISPLAY.

  • K zobrazení potřebuje heslo. X zobrazovaná hesla se nazývají magické cookies . Kouzelné cookies nejsou specifikovány přímo: jsou vždy uloženy v X autorizačních souborech, které jsou kolekcí záznamů formuláře „display :42 Má cookie 123456“. Soubor oprávnění X je obvykle označen v proměnné prostředí XAUTHORITY. Pokud není nastaven $XAUTHORITY, Programy používají ~/.Xauthority.

Pokoušíte se jednat podle oken zobrazených na ploše. Pokud používáte stolní počítač jako jediný člověk, je velmi pravděpodobné, že zobrazovaný název je :0. Najít umístění souboru autorit X je těžší, protože s gdm nastaveným pod Debian squeeze nebo Ubuntu 10.04 je to v souboru s náhodně vygenerovaným názvem. (Dříve jste neměl žádný problém, protože předchozí verze gdm použily výchozí nastavení, tj. Soubory cookie uložené v ~/.Xauthority.)

Získání hodnot proměnných

Zde je několik způsobů, jak získat hodnoty DISPLAY a XAUTHORITY:

  • Můžete systematicky spouštět relaci obrazovky z vašeho počítače, možná automaticky ve svých přihlašovacích skriptech (z ~/.profile; Ale to pouze pokud se přihlašujete pod X: test, zda je DISPLAY nastavena na začátek hodnoty s : (to by mělo pokrýt všechny případy, s nimiž se pravděpodobně setkáte)). V ~/.profile:

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

    Poté v relaci ssh:

    screen -d -r local
    
  • Můžete také uložit hodnoty DISPLAY a XAUTHORITY do souboru a vyvolat hodnoty. V ~/.profile:

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

    V ssh relaci:

    . ~/.local-display-setup.sh
    screen
    
  • Z běžícího procesu můžete zjistit hodnoty DISPLAY a XAUTHORITY. To je těžší automatizovat. Musíte přijít na PID procesu, který je připojen k displeji, na kterém chcete pracovat, a poté získat proměnné prostředí z /proc/$pid/environ (eval export $(</proc/$pid/environ tr \\0 \\n | grep -E '^(DISPLAY|XAUTHORITY)=') ¹).

Kopírování cookies

Dalším přístupem (po doporučení Arrowmaster ) je nezkoušet získat hodnotu $XAUTHORITY V ssh relaci, ale místo toho nechat X session zkopírovat své cookies do ~/.Xauthority. Protože soubory cookie jsou generovány při každém přihlášení, není problém, pokud ponecháte zastaralé hodnoty v ~/.Xauthority.

Pokud je váš domovský adresář přístupný prostřednictvím systému souborů NFS nebo jiného síťového souborového systému, který umožňuje vzdáleným správcům prohlížet jeho obsah, může to znamenat problém. Stále by se museli nějak připojit k vašemu počítači, pokud nemáte povoleno připojení X TCP (ve výchozím nastavení je Debian je vypnuto)). Takže pro většinu lidí to neplatí (ne NFS) nebo nejde o problém (žádné připojení X TCP připojení).

Chcete-li zkopírovat soubory cookie, když se přihlásíte do své pracovní relace X na ploše, přidejte následující řádky do ~/.xprofile Nebo ~/.profile (Nebo do jiného skriptu, který se přečte při přihlášení):

case $DISPLAY:$XAUTHORITY in
  :*:?*)
    # DISPLAY is set and points to a local display, and XAUTHORITY is
    # set, so merge the contents of `$XAUTHORITY` into ~/.Xauthority.
    XAUTHORITY=~/.Xauthority xauth merge "$XAUTHORITY";;
esac

¹ V zásadě postrádá správnou citaci, ale v tomto konkrétním případě $DISPLAY A $XAUTHORITY Nebudou obsahovat žádné metacharaktery Shell.

Tento problém jsem vyřešil přidáním

xhost +si:localuser:$USER

na ~/.xprofile. Nevím, jestli je to úplně bezpečné (měl bych velký zájem slyšet, co si lidé s vědomějšími znalostmi myslí), ale hádám, že je to mnohem lepší, než vypnout kontrolu přístupu (s xhost +), jak se běžně navrhuje, když Google tento problém řešíte.

20
edam

Musíš export DISPLAY=:0.0

7
asoundmove

Pracuje pro mě, debian wheezy -> ubuntu věrohodný.

Poznámka: v tomto případě server neběží správce zobrazení, jedná se o „bezhlavý“ virtuální stroj bez připojené grafické karty nebo monitoru.

[email protected]:~$ grep -iB 1 tcp /etc/gdm3/daemon.conf
[security]
DisallowTCP = false
[email protected]:~$ ssh -C -R 6000:127.0.0.1:6000 [email protected]
X11 forwarding request failed on channel 0
[email protected]:~$ export DISPLAY=:0.0
[email protected]:~$ xterm

Displej X na notebooku zobrazuje výstup xtermu běžícího na serveru.

Ladění pomocí:

[email protected]:~/tmp$ nc -v 127.0.0.1 6001
localhost [127.0.0.1] 6001 (x11-1) : Connection refused
[email protected]:~/tmp$ nc -v 127.0.0.1 6000
localhost [127.0.0.1] 6000 (x11) open
[email protected]:~$ nc -v 127.0.0.1 6000
Connection to 127.0.0.1 6000 port [tcp/x11] succeeded!*
[email protected]:~$ strace xterm

strace rozlije spoustu krvavých podrobností o tom, co dělá, měli byste být schopni uhodnout, kde se zasekne - čekat na připojení nebo cokoli.

Na jednom řádku ..

ssh -C -R 6000:127.0.0.1:6000 [email protected] "DISPLAY=:0.0 xterm"
3
jmullee