Он сработал у меня после того, как я сделал несколько изменений в стоковой установке на 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
, но при необходимости подставьте свое собственное имя.
Переадресация 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.
Так что... да, можно:
:0.0
через TCP)DISPLAY
указывала наkvmhost:0.0
Это позволило бы X11 работать «классическим способом» с минимальной дополнительной технической сложностью. Но на самом деле настроить гораздо сложнее, чем просто использовать ssh -X virtualmachine
, и это может открыть вас для различных старых, хорошо -известных атак.
вы можете сделать это с помощью простого крана
-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+ Гбит