Содержание
Многие пользователи операционных систем Linux рано или поздно сталкиваются с необходимостью удалённо управлять уже запущенной X-сессией. Решить эту задачу можно разными способами, в зависимости от этапа, с которого пользователь хочет управлять сессией и менеджера графических окружений. В статье будут рассмотрены несколько способов реализации.
Дано: компьютер N1 (сервер), с установленной ОС ALT Linux 5.0 Школьный Лёгкий - это будет система, которую нужно контролировать. Компьютер включен в локальную сеть и имеет адрес 192.168.10.1/24. Компьютер N2 (клиент) включен в эту же локальную сеть, имеет установленную ОС Windows или Linux, имеет адрес 192.168.10.2/24.
Надо: обеспечить удалённое управление уже работающей X-сессии с целью контроля за учениками.
Уровень пользователя: умение работать с текстовым редактором, понимание функционирования X.org-сервера хотя бы в общих чертах.
Решение:
Предполагается, что после запуска машины и загрузки системы, запускаются иксы и менеджер рабочих столов. Пользователь вводит свой логин\пароль и входит в систему.
Вариант управления X-сессией с момента начала работы менеджера рабочих столов можно реализовать с помощью пакета x11vnc. В качестве клиентской программы используется любой vnc-клиент. Программа x11vnc в нормальном режиме запускается после процедуры аутентификации самим пользователем и перехватывает обращения стандартного графического терминала. Этот вариант не всегда удобен, поскольку никогда не знаешь когда нужно запустить в работу такую возможность управления. Ниже будет рассмотрен вариант запуска x11vnc по требованию - сервер будет всегда готов, но при обращении клиентской программы к нему, он запустится и начнёт выполнять свою работу.
Вариант для менеджеров графических окружений xdm и kdm
На машине-сервере:
1. Доустанавливаем пакеты xinetd и x11vnc (можно через менеджер пакетов Synaptic):
# apt-get update # apt-get install xinetd x11vnc
2. В любимом редакторе открываем файл /etc/xinetd.conf и комментируем в нём строку, разрешающую подключения только с 127.0.0.1, как показано ниже:
- xinetd.conf
defaults { log_type = SYSLOG authpriv info log_on_success = PID HOST DURATION log_on_failure = HOST instances = 100 per_source = 5 # only_from = 127.0.0.1 } includedir /etc/xinetd.d
3. Переходим в каталог /etc/xinetd.d и создаём файл, назовём его x11vnc, такого содержания:
- x11vnc
service x11vnc { disable = no socket_type = stream protocol = tcp port = 5900 user = root wait = no server = /usr/local/bin/x11vnc_wrapper }
В нём задаются "какую программу и с какими параметрами запускать при обращении на tcp-порт 5900 этого компьютера". Запускать мы будем скрипт /usr/local/bin/x11vnc_wrapper.
Так как мы разрешили доступ для запуска служб xinetd не только для localhost`а, но и для других ip-адресов, проследите, чтобы в остальных файлах в /etc/xinetd.d/ конфигурации ненужных сервисов были отключены опцией disable. Например:
disable = yes
4. Создаём скрипт x11vnc_wrapper
- x11vnc_wrapper
#!/bin/bash authfilename=`ls /var/lib/xdm/authdir/authfiles/` authfile="/var/lib/xdm/authdir/authfiles/$authfilename" if [[|-r $authfile ]]; then exec /usr/bin/x11vnc -inetd -o /var/log/x11vnc.log -display :0 \ -auth $authfile -noxdamage -prog /usr/bin/x11vnc fi
Этот скрипт проверяет наличие файла аутентификации для X-сессии, запускает x11vnc и передаёт путь к этому файлу в параметрах запуска. Для менеджера GDM, такой скрипт не нужен, поскольку путь до файла аутентификации всегда статичен и запуск x11vnc можно производить непосредственно из конфигурационного файла xinetd.
От имени root`а копируем его в /usr/local/bin/ и даём права на исполнение:
# chmod +x /usr/local/bin/x11vnc_wrapper
По своему усмотрению, можно в строку запуска добавить нужные опции. Например, не лишним будет добавить опции проверки пароля у клиентской стороны.
5. Зарегистрируем сервис с номером порта 5900 в файле /etc/services , иначе суперсервер xinetd не разрешит подключаться на этот порт. Открываем в редакторе файл и вставляем строку такого содержания:
... x11vnc 5900/tcp # X11vnc protocol ...
Этим описывается сервис, его порт и рабочий протокол.
6. Перезапустим xinetd:
# /etc/init.d/xinetd restart
7. Проверим, прослушивается ли порт 5900, выполнив команду netstat:
# netstat -a -n |grep 5900 tcp 0 0 0.0.0.0:5900 0.0.0.0:* LISTEN
Отлично, xinetd заработал как надо. Иначе - изучаем логи daemon и syslog для получения дополнительной информации о проблемах.
На машине-клиенте:
1. Доустановим программы vnc-клиенты. Если контролируемая машина всего одна, то можно установить пакет vncviewer (консольное приложение) или gvncviewer (GTK-интерфейс). Если машин много, то лучше программы Remmina просто нету - имеет удобный и интуитивно-понятный интерфейс в виде списка машин. Каждый экран открывается в новом окне.
# apt-get install remmina
Внимание! В некоторых дистрибутивах remmina идёт без плагинов и требуется дополнительно установить пакеты remmina-plugins. Проверить наличие плагинов можно запустив программу и перейдя в меню "Инструменты" → "Плагины". Должно открыться окно со списком доступных плагинов и в списке должен быть плагин VNC. Если нет - попробуйте найти и поставить в репозиториях пакет remmina-plugins.
2. Теперь можно добавить нужные машины в список программы и проверить соединение. На стороне сервера, программой x11vnc сообщения будут писаться в лог /var/log/x11vnc.log В случае проблем, можно посмотреть этот лог на предмет ошибок.
Для подключения к серверу через программу vncviewer можно выполнить:
$ vncviewer 192.168.1.1:0 FullColor=1
У vncviewer достаточно много опций и можно хорошо оптимизировать работу под пропускную способность канала передачи данных.
Для ОС Windows можно воспользоваться любым VNC-клиентом.
Комбинации горячих клавиш для переключения раскладок не должны совпадать на клиентской и серверной стороне! Совпадение и использование этих клавиш в некоторых случаях приводит к неадекватному поведению X-сессии.
Вариант для менеджера графических окружений gdm
Раздел ждёт автора
Смотрите также
- man x11vnc
- man vncviewer
- Страничка Karl J. Runge, проекта x11vnc: http://www.karlrunge.com/x11vnc/