откройте окно на удаленном дисплее x (почему «не удается открыть дисплей»)?

<p>давным-давно,</p><pre><code>display=:0.0 totem /path/to/movie.avi </code></pre><p>после входа ssh в мой рабочий стол с моего ноутбука тотем начинает играть <code>movie.avi</code> на моем рабочем столе.</p><p>теперь выдает ошибку:</p><blockquote> <pre><code>no protocol specified cannot open display: </code></pre></blockquote><p>я переустановил debian squeeze, когда он стал стабильным на обоих компьютерах, и, думаю, я сломал конфиг.</p><p>я погуглил по этому поводу и не могу понять, что я должен делать.</p><p>(vlc имеет интерфейс http, который работает, но он не так удобен, как ssh.)</p><p>та же проблема возникает, когда я пытаюсь запустить это из задания cron.</p>

<p><sub><em> (адаптировано из <a href="https://superuser.com/questions/190801/linux-wmctrl-cannot-open-display-when-session-initiated-via-sshscreen#190878">linux: wmctrl не может открыть дисплей, когда сеанс инициируется через ssh + screen</a> ) </em></sub></p><h2>отображение и власть</h2><p>программе x требуется две части информации для подключения к дисплею x.</p><ul> <li> <p>ему нужен адрес дисплея, который обычно равен <code>:0</code>, когда вы вошли в систему локально, или <code>:10</code>, <code>:11</code> и т.д., когда вы вошли в систему удаленно (но число может меняться в зависимости от того, сколько активных x-соединений). адрес дисплея обычно указывается в переменной окружения <code>display</code>.</p> </li> <li> <p>требуется пароль для отображения. пароли x-дисплея называются <em> волшебными куки </em>. магические куки не указываются напрямую: они всегда хранятся в авторитетных файлах x, которые представляют собой набор записей вида "display <code>:42</code> содержит cookie <code>123456</code>". файл полномочий x обычно указывается в переменной среды <code>xauthority</code>. если <code>$xauthority не установлен, программы используют ~/.xauthority.  вы пытаетесь действовать на окнах, которые отображаются на вашем рабочем столе. если вы единственный, кто использует ваш настольный компьютер, вполне вероятно, что отображаемое имя - :0. найти местоположение авторитетного файла x сложнее, потому что с gdm, настроенным в debian squeeze или ubuntu 10.04, он находится в файле со случайно сгенерированным именем. (у вас не было проблем раньше, потому что в более ранних версиях gdm использовалась настройка по умолчанию, то есть файлы cookie, хранящиеся в ~/.xauthority.)получение значений переменныхвот несколько способов получить значения display и xauthority:  вы можете систематически запускать сеанс экрана со своего рабочего стола, возможно, автоматически в сценариях входа в систему (из ~/.profile; но делать это только при входе в систему под x: проверьте, установлено ли для display значение, начинающееся с : (которое должно охватите все случаи, с которыми вы можете столкнуться)). в ~/.profile: case $display in :*) screen -s local -d -m;; esac </code></pre> <p>затем в сеансе ssh:</p> <pre><code>screen -d -r local </code></pre></li> <li> <p>вы также можете сохранить значения <code>display</code> и <code>xauthority</code> в файле и вызвать их. в <code>~/.profile</code>:</p> <pre><code>case $display in :) export | grep -e '(^| )(display|xauthority)=' >~/.local-display-setup.sh;; esac  в сеансе ssh: . ~/.local-display-setup.sh screen   вы можете обнаружить значения display и xauthority из запущенного процесса. это сложнее автоматизировать. вы должны выяснить pid процесса, который подключен к дисплею, с которым вы хотите работать, а затем получить переменные окружения из /proc/$pid/environ</code> (<code>eval export $(</proc/$pid/environ tr \\0 \\n | grep -e '^(display|xauthority)=')</code> ¹).</p> </li> </ul><h2>копирование куки</h2><p>другой подход (следуя предложению <a href="https://unix.stackexchange.com/users/3459/arrowmaster">arrowmaster</a> ) состоит в том, чтобы не пытаться получить значение <code>$xauthority в сеансе ssh, а вместо этого заставить сеанс x копировать свои куки в ~/.xauthority. поскольку файлы cookie генерируются при каждом входе в систему, это не проблема, если вы сохраняете устаревшие значения в ~/.xauthority.может быть проблема безопасности, если ваш домашний каталог доступен через nfs или другую сетевую файловую систему, что позволяет удаленным администраторам просматривать его содержимое. им все равно нужно каким-то образом подключаться к вашей машине, если только вы не включили соединения x tcp (у debian они отключены по умолчанию)). поэтому для большинства людей это либо неприменимо (нет nfs) или не является проблемой (нет x tcp соединения).чтобы скопировать файлы cookie при входе в сеанс x рабочего стола, добавьте следующие строки в ~/.xprofile или ~/.profile (или в какой-либо другой сценарий, который читается при входе в систему):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 ¹ в принципе, здесь не хватает правильного цитирования, но в этом конкретном случае $display</code> и <code>$xauthority не будут содержать метасимвол shell.

я решил эту проблему, добавивxhost +si:localuser:$user </code></pre><p>к <code>~/.xprofile</code>. я не знаю, насколько это безопасно (мне было бы очень интересно услышать, что думают более знающие люди), но я предполагаю, что это намного лучше, чем отключение контроля доступа (с <code>xhost +</code>) как обычно предлагается, когда вы решаете эту проблему в google.</p>

<p>тебе следует <code>export display=:0.0</code></p>

<p>у меня работает, debian wheezy -> ubuntu trusty.</p><p>примечание: в этом случае на сервере не запущен менеджер дисплеев, это виртуальная машина без головы без подключенной графической карты или монитора.</p><pre><code>bob@laptop:~$ grep -ib 1 tcp /etc/gdm3/daemon.conf [security] disallowtcp = false bob@laptop:~$ ssh -c -r 6000:127.0.0.1:6000 alice@server x11 forwarding request failed on channel 0 alice@server:~$ export display=:0.0 alice@server:~$ xterm </code></pre><p>x дисплей на ноутбуке показывает вывод xterm на сервере.</p><p>отладка с использованием:</p><pre><code>bob@laptop:~/tmp$ nc -v 127.0.0.1 6001 localhost [127.0.0.1] 6001 (x11-1) : connection refused bob@laptop:~/tmp$ nc -v 127.0.0.1 6000 localhost [127.0.0.1] 6000 (x11) open alice@server:~$ nc -v 127.0.0.1 6000 connection to 127.0.0.1 6000 port [tcp/x11] succeeded! alice@server:~$ strace xterm </code></pre><p><code>strace</code> расскажет множество подробностей о том, что он делает, вы должны быть в состоянии угадать, где он застрял - ожидание соединения или что-то еще.</p><p>в одну строчку ..</p><pre><code>ssh -c -r 6000:127.0.0.1:6000 alice@server "display=:0.0 xterm" </code></pre>