Есть ли какие-либо решения для установки текстового режима Debian Wheezy, где я могу запустить виртуальную машину с установленным графическим интерфейсом, который будет отображаться на одном из экранов?
1 ответ
3
Нет, не совсем, но, пожалуйста, обратите внимание, что все различия между "текстовым режимом Debian" и "графическим интерфейсом Debian" существуют только в вашей голове ;-)
Идея состоит в том, что обычно вам нужен либо "сервер", и тогда это обычно означает "текстовый режим", либо "рабочую станцию", а затем это обычно означает некоторую среду рабочего стола, такую как GNOME или KDE или XFCE или что-то еще. Подвох в том, что виртуальные пакеты, устанавливающие соответствующие "рабочие столы", обычно зависят от того или иного пакета, предоставляющего так называемый менеджер дисплеев - программа, которая запускается при загрузке, порождает X-сервер (сложная часть программного обеспечения, фактически предоставляющая консоль с графическим интерфейсом) запускает на нем менеджер входа в систему, и как только вам удастся успешно войти в систему, он отвечает за настройку сеанса для вас. Как только вы выйдете из сеанса, менеджер дисплея снова включится, и вы вернетесь к квадрату 0.
Но ничто не требует, чтобы у вас был установлен менеджер дисплеев (или запускался при загрузке). Просто установите пакет xorg , и вы получите X-сервер, который сможете запускать вручную.
Теперь давайте перейдем к более жестким вещам.
Сначала вам нужно запустить X-сервер, а затем запустить программу с графическим интерфейсом так, чтобы она знала, как связаться с порожденным X-сервером.
Давайте отложим вопрос о запуске экземпляра X-сервера на минутку и поговорим о том, как программа с поддержкой X находит сервер. Существует несколько способов сделать это, но наиболее распространенным является поиск переменной среды с именем "DISPLAY", которая должна содержать имя сокета, который прослушивает экземпляр X-сервера для соединения с клиентом, и так далее. вызываемый номер дисплея. Я не хочу писать здесь слишком много об этом: важно понять, что после запуска X-сервера программы, которые хотят его использовать, обычно должны видеть соответствующий набор env. переменная, чтобы иметь возможность найти сервер.
И вот тут-то и возникает концепция «X-сессии»: хотя вы можете запускать экземпляр X-сервера вручную, проще использовать специальную программу, чтобы сделать это для вас, и в дополнение к запуску программа или набор программ в специально подготовленной среде, чтобы они могли найти запущенный сервер.
В старые добрые времена ручного запуска X-серверов и подключенных к ним сеансов люди обычно использовали сценарий startx который все еще поддерживается и является частью пакета xinit . Он порождает X-сервер и либо запускает указанную программу, либо выполняет сценарий оболочки ~/.xinitrc . Вы поняли идею.
Но в наши дни может быть удобнее использовать диспетчер отображения с автологином - так что у вас есть готовый X-сеанс, сидящий на указанном VT прямо при загрузке. Для этого используйте пакет nodm . Он автоматически запускает X-сервер, а затем запускает указанный сценарий от имени указанного пользователя.
В любом случае просто убедитесь, что ваша виртуальная машина работает как часть процесса запуска сеанса X, или заставьте программное обеспечение виртуальной машины видеть правильную переменную среды DISPLAY .
Обновление 2016-09-20, чтобы ответить на комментарий @LauriK :
…Не совсем. Позволь мне объяснить. В своем ответе я объяснил, как X-клиенты находят X-сервер. В парадигме X Windows System X-клиенты (программы с графическим интерфейсом) ничего не рисуют сами по себе, а скорее направляют запросы на передачу к экземпляру X-сервера, к которому они подключены - через сокет. Таким образом, графический экран (с указателем мыши), который вы видите на локальном компьютере, на котором вы сидите (то есть на вашем мониторе), представлен вам экземпляром X-сервера, работающего локально.
Теперь интересное свойство X-клиента и X-сервера, соединенных через сокет, заключается в том, что они могут фактически работать на разных компьютерах - если этот сокет подключен к сети (скажем, предоставляется стеком TCP/IP). Это несколько менее известное свойство X Window System, которое называется прозрачностью сети.
Важнейшим аспектом прозрачности сети X является то, что X-сервер всегда работает на локальной машине (той, к которой подключены монитор и устройства ввода), в то время как X-клиенты, работающие на нем, могут работать либо локально, либо на любом количестве. удаленных машин.
Эта парадигма родилась естественным образом, потому что она была изобретена в «эру мэйнфреймов»: в основном, на базе типичного предприятия / лаборатории / чего бы то ни было, существовал бы один дорогостоящий мощный мэйнфрейм и пара менее мощных рабочих станций, которые, будучи менее мощный, - будет оснащен графическими экранами. В таких установках рабочие станции будут запускать свои X-программы на мэйнфрейме, и эти программы будут использовать X-серверы, работающие на рабочих станциях.
Чтобы сделать это более понятным, протокол X поддерживает набор примитивов для рисования (таких как линии, прямоугольники, заливка областей определенным цветом и т.д.).
Набор NX (который предоставляет nomachine.com ) как бы "переворачивает" подход, заставляющий все это работать, подобно протоколу RDP (доступ к серверу терминалов) Windows или VNC.
В этой парадигме и X-клиенты, и X-сервер, через который они рисуют, расположены на удаленном компьютере ("сервер"), но вместо рисования на реальном аппаратном экране (скажем, на мониторе) X-сервер "рисует" где-то еще (подробнее об этом чуть позже), и эта информация собирается и доставляется удаленно подключенному клиенту. То есть весь "скрининг" данных передается оптом. От клиента другой поток информации возвращается обратно на сервер: данные от клиентских устройств ввода, таких как нажатия клавиш клавиатуры и движения указывающего устройства.
В этой парадигме весь "графический сеанс" запускается на сервере, создается там, и эта постоянно меняющаяся "картинка экрана" непрерывно передается подключенному клиенту (очень эффективным способом). Вы можете посмотреть на это так, как если бы сервер генерировал бесконечное видео на YouTube, которое вы просматриваете и смотрите.
Как видите, эта парадигма обратна по сравнению с исходной моделью прозрачности X-сети, поскольку X-сервер также работает удаленно.
Как клиент, вы, как правило, "видите" весь удаленный графический сеанс в одном окне, отображаемом специализированным программным обеспечением, которое вы используете для создания и поддержки этого удаленного сеанса.
Преимущество этого подхода заключается в том, что он упрощает передачу неграфической информации через сеанс, такой как звук, общий доступ к принтерам и другим устройствам и т.д.
Последний кусочек головоломки состоит в том, как данные с удаленного X-сервера доставляются удаленно подключенному клиенту.
В принципе, есть два способа добиться этого:
Специальная часть программного обеспечения, выполняющая серверную часть, "зацепляет" события рисования, генерируемые X-сервером, и обрабатывает их: определяет, какие области экрана были обновлены и как, объединяет обновления в пакеты, возможно, "уменьшая их масштаб" (понижая цвет глубина и / или разрешение) сжимает их и отправляет клиенту.
Вот как работает серверное программное обеспечение VNC.
X-сервер может работать на реальном аппаратном устройстве или в специальной области памяти, называемой кадровым буфером. Последний подход позволяет запускать любое количество графических сеансов для удаленных клиентов на "безголовом" компьютере, который в противном случае не имеет графических устройств вывода или только элементарных устройств, таких как текстовые консоли.
Сервер использует специальный драйвер дисплея, который работает как любой другой "настоящий" драйвер дисплея, управляющий аппаратным устройством, таким как видеокарта, но этот драйвер просто выполняет то, что делает описанное выше программное обеспечение - обеспечивает эффективную доставку вывода сервера клиенту. ,
Насколько мне известно, NX/nomachine (и его аналог F/OSS, X2Go) реализует последний подход.
Обратите внимание, что NX/X2Go - не единственные решения, использующие эту парадигму. Популярный стек виртуализации под названием KVM поддерживает протокол SPICE для подключения к виртуализированному графическому экрану своих гостей. Существуют драйверы Windows, реализующие специальный протокол QXL, обеспечивающий эффективную доставку графического вывода клиентам с помощью SPICE (и VNC также).
Также обратите внимание, что также возможно "экспортировать" только одно приложение, работающее удаленно с использованием этой парадигмы. Я упустил эту возможность в своем объяснении, чтобы не перегружать вас информацией.
Например, посмотрите на xpra.
Наконец, обратите внимание, что технология «изменения игры» в * nix graphics - проект Wayland - фактически поддерживает только этот NX-подобный подход к работе с удаленными графическими программами. Когда он вступит во владение, прозрачность сети «X-way» уйдет в прошлое. ;-)
Надеюсь это поможет.