Запуск приложения X11 на гостевом KVM, чтобы оно отображалось в хост-системе

Он сработал у меня после того, как я сделал несколько изменений в стоковой установке на CentOS 6.5 64-bit:

  • Я добавил /opt/mono/bin в PATH, и перезапустил мой shell. Пакет mono-opt, по идее, должен это сделать, но он этого не делает.

  • В свежесозданном решении щелкните правой кнопкой мыши проект (на один шаг ниже уровня решения) и выберите Options из контекстного меню. Перейдите в Run > General и выключите Run on external console.

    Возможно, вам не придется этого делать. Я делал это, потому что запускал MonoDevelop через SSH-переадресованную сессию X11. Это может не понадобиться при запуске из Gnome Terminal или подобного. С другой стороны, если вы запускаете MonoDevelop, щелкнув по значку, это может понадобиться, если MonoDevelop по какой-то причине не может открыть внешнее окно консоли.

    В итоге, эта настройка заставляет запускать программу в среде MonoDevelop, с выводом на вкладку Application Output в пользовательском интерфейсе. Вы, вероятно, не сможете использовать программу интерактивно с этой настройкой.

    Если вам нужно запустить консольную программу Mono в интерактивном режиме, лучше всего сделать это прямо из терминала:

    $ mono foo/bin/Debug/foo.exe
    

    Здесь решение называется foo, но при необходимости подставьте свое собственное имя.

5
24.03.2019, 22:28
2 ответа

Переадресация SSH X11 — это нечто большее, чем обычная переадресация портов, и, вероятно, это самый простой способ добиться того, чего вы хотите.по крайней мере, с точки зрения пользователя .

Если вы хотите, чтобы технически было проще, вам нужно понять, как изначально предполагалось использовать X11.

В среде с несколькими компьютерами с поддержкой X11 -информация о пользователях может централизованно управляться с помощью NIS, а домашние каталоги могут совместно использоваться с выделенного дискового сервера для всех других компьютеров с NFS (с небольшим количеством автоматического монтирования. брошен в ). Все компьютеры также должны иметь возможность разрешать имена хостов друг друга. Предполагалось, что в доверенной внутренней сети вы ()не отключите порт прослушивания TCP вашего сервера X11.

В такой среде вы можете подключаться с одного хоста к другому, и вам нужно только убедиться, что DISPLAYпеременная среды установлена ​​​​правильно, чтобы любая удаленная клиентская программа X11 могла установить прямое соединение с вашим локальным сервером X11, и таким образом, на ваш локальный дисплей. Поскольку домашние каталоги являются общими для NFS, один и тот же ~/.Xauthorityбудет виден как удаленному, так и локальному хосту.

Если бы не было НИС? Это не проблема для X11 :, он не заботится об идентичности. Пока любой клиент, подключающийся к серверу X11, может предоставить правильный файл cookie аутентификации X11 из файла ~/.Xauthority(или файла по умолчанию, отличного от -, на который указывает переменная среды XAUTHORITY), X11 будет работать.. Однако без общих назначений номеров UID/GID совместное использование домашних каталогов может оказаться невозможным.

Без общего домашнего каталога? В этом случае вам также потребуется передать файл cookie аутентификации X11, как правило, извлекая его на хосте дисплея, например, с помощью. xauth nextract /some/file :0.0, затем получить содержимое /some/file, переданное на удаленный хост любым способом, и использовать там xauth nmerge, чтобы добавить его в файл ~/.Xauthorityудаленного хоста.

(Или вы можете использовать xhost +, чтобы отключить проверку безопасности либо полностью, либо только для определенного удаленного хоста.Но это оказалось очень плохой идеей,:если на удаленном хосте были другие пользователи, это открывало вам доступ xsnowк вторжению, или к xroachзаражению, или к худшим вещам, таким как получение все ваши события клавиатуры и мыши для всего сеанса X11 отслеживаются.)

Но незашифрованный протокол X11 оказался довольно слабым местом в системе безопасности. Из-за законов США об экспорте криптовалюты в то время мир остановился на использовании SSH с переадресацией X11 и отключением TCP-порта сервера X11. Стало нормой видеть, что X-сервер запускается как Xorg -nolisten tcp <other options...>.

Совсем недавно X.org признал это и перевернул логику прослушивания TCP :Если ваш дистрибутив Linux запускает сервер X11 без опции -nolisten tcpпо умолчанию, это может быть связано с тем, что ваша версия сервера X11 на самом деле требует явного -listen tcpдля включения классического и небезопасного прослушивателя TCP X11.

Так что... да, можно:

  • включить прослушиватель TCP на сервере X11 вашего хоста
  • убедитесь, что ваша виртуальная машина может разрешить IP-адрес хоста и подключиться к порту хоста 6000 (= соответствует DISPLAY :0.0через TCP)
  • настроить вашу виртуальную машину так, чтобы переменная DISPLAYуказывала наkvmhost:0.0
  • предпримите необходимые шаги для передачи файла cookie аутентификации X11 на виртуальную машину

Это позволило бы X11 работать «классическим способом» с минимальной дополнительной технической сложностью. Но на самом деле настроить гораздо сложнее, чем просто использовать ssh -X virtualmachine, и это может открыть вас для различных старых, хорошо -известных атак.

6
27.01.2020, 20:40

вы можете сделать это с помощью простого крана


-netdev tap,id=mynet0,ifname=qtap0,script=no,downscript=no -device e1000,netdev=mynet0,mac=fe:ed:be:ef:55:66

после установки некоторых совместимых с x -двоичных файлов в виртуальной машине вы можете удаленно запускать их через ssh:

xhost +10.11.12.10 ;ssh -p 6666 user@127.0.0.1 "LANG=de BROWSER=chromium-browser DISPLAY=10.11.12.11:0.0 dbus-run-session chromium-browser"

→ будьте осторожны, Full HD youtube потребляет пропускную способность 1,2+ Гбит

0
05.03.2021, 22:28

Теги

Похожие вопросы