Opening x window in linux

Запуск X-приложенний в Linux

Если рассмотреть схему работы системы X Window немного подробнее. То сначала может показаться, что эта схема слишком запутана и сложна. Однако это лишь первое впечатление от нестандартного и универсального подхода к реализации принципов работы с видеодисплейными терминалами (вывода изображения на экран монитора) в сложных и распределённых системах UNIX и Linux. На самом деле такая концепция очень полезна. В первую очередь для системного администрирования. Она позволяет администраторам организовать удобную для себя программно-аппаратную среду для управления и контроля всей системы. Ведь система X Window основана на архитектуре клиент-серверного взаимодействия. Что делает её (X Window) очень податливой для централизации и масштабирования. А это в свою очередь прямо влияет на удобство администрирования и мониторинга систем и сетей (даже самых сложных), в которых используется X Window.

Распределённая схема запуска X-приложений

Изображение обрабатывается для вывода на дисплей (не путать с монитором) X-сервером на его стороне. Для этого используются данные от зарегистрированных клиентов, которые (и это очень важно) могут работать на отдельных компьютерах в системе/сети. В качестве данных клиентов используются результаты работы графических и библиотек элементов интерфейса (GUI). А также графических сред, установленных на стороне клиента.

Информация об обновлении дисплея X Window передаётся по сети от клиентов. К дисплею может быть подключено несколько мониторов — для каждого клиента свой. Для этого клиенту необходимо знать:

• хост, на котором запущен X-сервер;
• номер активного дисплея (управляется менеджером дисплеев);
• номер монитора, привязанного к активному дисплею.

Таким образом системные администраторы могут настраивать свое рабочее место для выполнения служебных обязанностей. В частности для удобного мониторинга систем. Такую схему также можно использовать и для других задач. Например для организации видеостен или напротив для использования одного монитора несколькими машинами.

Переменная окружения DISPLAY

Каким образом X-приложение на стороне клиента «узнаёт», к какому X-серверу подключаться и какие дисплей и монитор использовать для вывода GUI? Для этого существует специальная переменная окружения DISPLAY. Она содержит информацию об IP-адресе X-сервера (или имя хоста) и номера дисплея и монитора (если мониторов несколько). Естественно, что в том случае, когда X-сервер и X-приложение работают на одном компьютере, то вся эта информация может быть опущена за исключением номера монитора. В качестве которого указывается значение «0», если он один.

Для задания параметров переменной DISPLAY на стороне клиента можно выполнить следующую команду:

Теперь клиент будет «знать», что для отображения его GUI нужно использовать монитор номер 2, дисплея номер 10, который поддерживается X-сервером, доступном по адресу hostname.domain.com. Просмотреть текущее значение переменной DISPLAY можно например так:

Однако следует помнить, что переменные окружения должны быть корректно заданы для каждого процесса, использующего X-сервер. Например, X-приложения, запущенные из одной командной оболочки и корректно работающие в системе X Window, могут не работать, будучи запущенными из другой. Если для этих оболочек переменная DISPLAY имеет разные значения.

Даже когда X-приложения работают через указанный X-сервер, то они могут отправлять в вывод клиентской командной оболочки (из которой были запущены) некоторую информацию по стандартным каналам ввода/вывода STDOUT и STDERR – в этом нет ничего необычного.

Разумеется, в имени хоста можно опускать название домена. Если клиент и сервер оба в него включены. Хотя это может зависеть от схемы распознавания доменных имён в конкретной сети. Ну и конечно стоит помнить о том, что если клиент и сервер работают на одном компьютере, то очень рекомендуется полностью исключать из переменной DISPLAY имя компьютера (вместо хоста как в случае с удалённым X-сервером). В этом случае будет задействован сокет UNIX вместо стандартного сетевого сокета TCP. Это очень полезно — ведь данный тип сокета более быстрый и эффективный, чем сокет сети. К тому же это позволяет избежать проблем с настройкой брандмауэров. Поскольку сокеты типа UNIX по-умолчанию не подлежат прослушиванию и блокировкам.

Авторизация клиентов

Когда-то к X-серверу могли подключаться абсолютно все клиенты. Но в эпоху всё нарастающих опасностей в киберпространстве возникла необходимость защиты соединений и взаимодействия по сети. Не стала исключением и система X Window. С помощью команды xhost, выполняющей подключение к X-серверу любой пользователь мог впоследствии навредить системе. Позже от неё закономерно отказались.

Самой распространённой моделью авторизации клиентов для X-сервера является использование куков (cookie). Которые представляют собой случайно генерируемые последовательности символов. Куки известны диспетчеру дисплеев, отвечающему за авторизацию. Клиент, предоставивший диспетчеру дисплеев такие куки воспринимается сервером как аутентифицированный. Сами куки сохраняются в файл

/.Xauthority на стороне клиента. Команда xauth позволяет просматривать куки сервера и добавлять их в файл

/.Xauthority. Когда X-приложение не может получить доступ к X-серверу по причине неудачной авторизации, может быть получен вывод примерно такого содержания:

Как видно, для X-приложения был отклонён доступ к X-серверу из-за отсутствия нужных куков. Но не стоит унывать, ведь сами куки можно получить, выполнив на стороне сервера:

В данном выводе получены куки для сокета UNIX, сетевого интерфейса Ethernet. А также для интерфейса с обратной связью localhost.

Далее, поскольку возможность копирования/вставки поддерживается командными оболочками. Чтобы добавить полученные куки в набор клиента нужно выполнить (на стороне клиента) следующую команду:

Теперь можно удостовериться, что куки были добавлены правильно. Т. е. попробовать запустить X-приложение на клиентской машине. В результате чего данные клиента должны быть отображены на сервере.

Как можно видеть, использование системы X Window позволяет легко выйти за рамки использования одного компьютера. Подобная концепция позволяет гибко масштабировать системы на основе UNIX\Linux не только в классическом представлении «командной строки», но и с использованием всех самых современных разработок и достижений для GUI.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник

Запуск X Window System Linux

Локальный запуск X-клиентов

Существует «ручной» запуск компонент оконной системы X, что достаточно неудобно, т. к. требует установить правильное значение переменной окружения display, запустить X-сервер «до запуска первого клиента, а завершить после завершения последнего и т. д.

Поэтому для автоматизации запуска X-сервера и всех клиентов X-сеанса пользователя предназначается специальная команда xinit, проиллюстрированная в листинге ниже.

Запуск сеанса iceWM с отображением на сервере Xnest

$ xinit /usr/bin/icewn-session — /usr/bin/Xnest :1 &
[email protected]:

$ ps f

PID TTY STAT TIME COMMAND
28163 pts/8 Ss 0:00 bash
28218 pts/0 S 0:00 \_ xinit /usr/bin/icewm-session — /usr/bin/Xnest :1
28219 pts/0 Sl 0:00 | \_ /usr/bin/Xnest 1
28226 pts/0 S 0:00 | \_ /usr/bin/icewm-session
28231 pts/0 R+ 0:00 \_ ps f

Запускатель xinit может быть сконфигурирован пользовательскими dot-файлами -/.xinitrc и

/.xserverrc, представляющими собой сценарии командного интерпретатора, которые запускают, клиентскую и серверную части оконной системы соответственно.

В примере из листинга ниже показан сценарий .xserverrc, позволяющий xinit использовать виртуальный X-сервер Xnest по умолчанию на указанном дисплее, что сокращает командную строку запуска.

Запуск сеанса TWM с отображением на сервере «по умолчанию» (Xnest)

$ cat .xserverrc
#!/bin/sh
exec /usr/bin/Xnest
[email protected]:

$ ps f

PID TTY STAT TIME COMMAND
28268 pts/1 Ss 0:00 bash
28322 pts/1 S 0:00 \_ xinit /usr/bin/twm — :2
28323 pts/1 Sl 0:01 | \_/usr/bin/Xnest :2
28330 pts/1 S 0:00 | \_ /usr/bin/twm
30112 pts/1 R+ 0:00 \_ ps f

В примере из листинга ниже показан сценарий .xinitrc, позволяющий xinit использовать X-сеанс среды KDE по умолчанию, что еще более сокращает командную строку запуска.

Запуск локальной X Window System (окружение KDE с отображением на сервере Xnest)

$ cat .xserverrc

$ cat .xinitrc

$ xinit — :3 &

$ ps f

PID TTY STAT TIME COMMAND
30810 pts/2 Ss 0:00 bash
30996 pts/2 S 0:00 \_ xinit — :3
30997 pts/2 Si 0:04 | \_/usr/bin/Xnest :3

31004 pts/2 S 0:00 | \_ /bin/sh /usr/bin/startkde

31064 pts/2 S 0:00 | \_ kwrapper4 ksmserver
31179 pts/2 R+ 0:00 \_ ps f

Нужно заметить, что все три пользовательских сеанса, запущенных из листингов выше, могут существовать одновременно, т. к. используют разные экземпляры X-сервера.

Дистанционный запуск X-клиентов

Оконная система X изначально: проектировалась для распределенной работы ее компонент на различных узлах сети, что достаточно широко используется на практике, когда нужно запускать графические приложения на удаленном узле, их окна отображать на локальном дисплее.

В большинстве случаев для дистанционного запуска используется ssh. Попытка «прямого» запуска xeyes на узле centos от лица пользователя lich не увенчалась успехом потому, что в большинстве инсталляций аппаратный X-сервер на дисплее :0 не принимает сетевые соединения.

Попытка запуска локального виртуального сервера Xnest на дисплее :1 с перенаправлением ему вывода дистанционного xeyes тоже оказалась неудачной, но уже по другим причинам.

Запуск дистанционного X-клиента

$ ssh -f [email protected] «DISPLAY=ubuntu. local:0 xeyes»

Error: Can’t open display: ubuntu.local:0

$ Xnest :1 &

$ ssh -f [email protected] «DISPLAY=ubuntu.local:1 xeyes»

No protocol specified

Error: Can’t open display: ubuntu.local:1

При сетевом взаимодействии X-клиентов и X-сервера для аутентификации клиентских подключений используется механизм, основанный на предъявлении общего (известного обеим сторонам) «секрета», называемого «волшебной печенькой» (см. W:[magic cookie]), использование которых проиллюстрировано в примере ниже.

На стороне сервера «печеньки» всех клиентов, которым разрешено подключение, размещаются при помощи утилиты xauth в «банке с печеньками» (jar), откуда извлекаются сервером для проверки при подключении клиента. На стороне клиента «печеньки» при помощи той же утилиты xauth размещаются в «банке» -/.Xauthority, откуда извлекаются библиотекой Xlib для предъявления серверу при соединении с ним.

Аутентификация дистанционного X-клиента

$ mcookie

8f36c904dc0c9934c506c21ea7860eb2

$ xauth -f cookie-jar

xauth: file cookie-jar does not exist Using authority file cookie-jar

xauth> add ubuntu:1 MIT-MAGIC-C00KIE-1 8f36c904dc0c9934c506c21ea786Oeb2↵

xauth> exit↵

Writing authority file cookie-jar

$ Xnest :1 -auth cookie-jar &

Last login: Fri Jan 8 17:43:04 2016 from ubuntu

xauth: file /home/lich/.Xauthority does not exist

Using authority file /hone/lich/.Xauthority

xauth> add ubuntu.local:1 MIT-MAGIC-COOKIE-1 8f36c904dc0c9934c506c21ea7860eb2↵

xauth> exit↵

Writing authority file /hone/lich/.Xauthority [[email protected]

]$ logout

onnection to centos closed.

$ ssh -f [email protected] «DISPLAY=ubuntu.local:1 xeyes»

Необходимость установки общего секрета и переменной окружения display и необходимость запуска дополнительного виртуального X-сервера (или необходимость активации приема сетевых соединений аппаратным сервером) делают «ручной» запуск дистанционных X-клиентов неудобным «чуть более, чем полностью».

Вместе с этим, передача «волшебных печенек» (как и любых других сообщений X-протокола) от X-клиента к X-серверу по сети происходит незащищенным образом, что может быть легко использовано злоумышленником. Именно поэтому на практике используют туннелирующие возможности протокола SSH, позволяющие удобным автоматизированным способом решить все вышеперечисленные задачи и проблемы.

В примере из листинга ниже показано поведение SSH-сервера при туннелировании X-протокола. По запросу (-x) от SSH-клиента SSH-сервер начинает эмулировать поведение X-сервера, устанавливает О переменную окружения display, указывающую на «дисплей» :10 на «том же» узле localhost, и создает «волшебную печеньку» для этого дисплея.

При последующем запуске X-клиента xeyes им будет установлено соединение с «SSH-эмулятором» X-сервера на localhost: 10, а SSH-сервер перенаправит (туннелирует) это соединение X-протокола обратно SSH-клиенту внутри зашифрованного соединения SSH.

SSH-туннелирование X-протокола (SSH-сервер)

Last login: Fri Jan 8 17:48:34 2016 from ubuntu

]$ echo $DISPLAY

]$ xauth list
centos/unix:10 MIT-MAGIC-C00KIE-1 80c749073282be2001c33bd43e577aa4
[[email protected]

]$ sudo lsof -nP -i 4:6010

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME

sshd 14221 Itch 10u IPv4 44578 0t0 TCP 127.0.0.1:6010 (LISTEN)
[[email protected]

]$ logout

Connection to centos closed.

Листинг ниже иллюстрирует поведение SSH-клиента в режиме (-X) X-туннелирования, при котором он эмулирует «Х-клиента» и соединяется с аппаратным (!) Х-сервером через локальный сокет /tmp/.x11-unix/X0.

При получении от SSH-сервера перенаправленных соединений X-протокола они ретранслируются SSH-эмулятором «X-клиента» локальному X-серверу, тем самым вывод дистанционных X-клиентов изображается в окнах локального X-сервера.

SSH-туннелирование X-протокола (SSH-клиент)

-fe connect ssh -f |X [email protected] xeyes

Так как SSH-туннелирование X-протокола позволяет перенаправлять любое количество X-соединений внутри одного SSH-соединения, то дистанционно можно запускать целые сеансы пользовательских сред, таких как GNOME с использованием xinit и виртуального X-сервера Xnest.

Запуск дистанционного сеанса GNOME с отображением на локальном сервере Xnest

$ xinit /usr/bin/ssh -X [email protected] gnome-session — /usr/bin/Xnest :4 &
[email protected]:

$ ps f

PID TTY STAT TIME COMMAND
27759 pts/0 Ss 0:00 bash
27829 pts/0 S 0:00 \_ xinit/usr/bin/ssh -X [email protected] gnomes-session — …
27830 pts/0 Sl 0:00 | \_ /usr/bin/Xnest :4
27837 pts/0 S 0:00 | \_ /usr/bin/ssh -X [email protected] gnome-session
27928 pts/0 R+ 0:00 \_ ps f

Управление X-дисплеями: XDMCP-менеджер и протокол

В большинстве современных инсталляций Linux работа пользователей в системе осуществляется сразу с использованием оконной системы X и какой-либо пользовательской среды, например GNOME.

Оконная система запускается сразу при старте операционной системы и не требует использования xinit или startx.

Если при работе в автоматически запущенной оконной системе проследить дерево процессов от командного интерпретатора до прародителя процессов init, то обнаружится менеджер дисплеев (например, lightdm), осуществляющий запуск пользовательского сеанса в (gnome-session).

Более того, аппаратный -сервер дисплея :0 тоже окажется запущенным этим менеджером.

Менеджер дисплеев является специальной компонентой оконной системы, управляющей автоматическим запуском ее X-серверов и X-сеансов. Именно он запускает аппаратные X-серверы для обслуживания дисплеев в указанном количестве (по умолчанию один дисплей :0), а затем «графическим» образом производит аутентификацию пользователя в системе и запускает менеджер сеансов пользовательской среды.

Кроме этого, менеджер дисплеев предназначен и для запуска дистанционных пользовательских X-сеансов, но делает это при помощи специального протокола W:[XDMCP], а не посредством протокола SSH, как при «ручном» дистанционном их запуске.

В листинге ниже показано дистанционное подключение виртуального X-сервера Xnest с узла terminal к узлу ubuntu.local по протоколу XDMCP (-query), в результате чего менеджер дисплеев lightdm (при помощи X-протокола) отобразил экран аутентификации пользователей в системе узла ubuntu. При успешной аутентификации пользователя будет запущен его X-сеанс на узле ubuntu.local так, что вывод всех X-клиентов будет направлен на дистанционный X-сервер узла terminal.

Дистанционный графический вход в ubuntu

$ sudo lsof -p 32494 -a -i4

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME

lightdm 32494 root 11u IPv4 3031884 0t0 UDP *:xdmcp
[email protected]:

$ Xnest :1 -query ubuntu.local

Надо заметить, что при использовании дистанционного XDMCP-запуска данные XDMCP- и X-протоколов при передаче в публичной сети оказываются никак не защищены (включая согласование «волшебной печеньки» и ее последующее использование), поэтому на практике безальтернативно используют SSH-запуск дистанционных сеансов с туннелированием X-протокола внутри криптографически защищенного SSH-соединения.

Источник