Linux xrdp gfx pipeline

H264 Graphics Pipeline in XRDP #1174

Comments

antoine-roux commented Jul 23, 2018

I’m wondering if XRDP implements the RDP 8.1 Graphics Pipeline.
I’m trying to use the /gfx-h264 of FreeRDP but it do not works with a XRDP server 🙁

In the XRDP source code, I can read some lines about H264 codec, but it appears to be another thing not compatible with FreeRDP. What I understand is that Graphics Pipeline’s H264 is not just another codec but another channel. Am I wrong?

But from XRDP side, there is much more codecs.

Lines 311 to 335 in 577bd82

/* Bitmap Codec: codecGUID (MS-RDPBCGR 2.2.7.2.10.1.1) */

/* CODEC_GUID_NSCODEC CA8D1BB9-000F-154F-589FAE2D1A87E2D6 */

# define XR_CODEC_GUID_NSCODEC \

» \xb9\x1b\x8d\xca\x0f\x00\x4f\x15\x58\x9f\xae\x2d\x1a\x87\xe2\xd6 «

/* CODEC_GUID_REMOTEFX 76772F12-BD72-4463-AFB3B73C9C6F7886 */

# define XR_CODEC_GUID_REMOTEFX \

» \x12\x2F\x77\x76\x72\xBD\x63\x44\xAF\xB3\xB7\x3C\x9C\x6F\x78\x86 «

/* CODEC_GUID_IMAGE_REMOTEFX 2744CCD4-9D8A-4E74-803C-0ECBEEA19C54 */

# define XR_CODEC_GUID_IMAGE_REMOTEFX \

» \xD4\xCC\x44\x27\x8A\x9D\x74\x4E\x80\x3C\x0E\xCB\xEE\xA1\x9C\x54 «

/* MFVideoFormat_H264 0x34363248-0000-0010-800000AA00389B71 */

# define XR_CODEC_GUID_H264 \

» \x48\x32\x36\x34\x00\x00\x10\x00\x80\x00\x00\xAA\x00\x38\x9B\x71 «

/* CODEC_GUID_JPEG 1BAF4CE6-9EED-430C-869ACB8B37B66237 */

# define XR_CODEC_GUID_JPEG \

» \xE6\x4C\xAF\x1B\xED\x9E\x0C\x43\x86\x9A\xCB\x8B\x37\xB6\x62\x37 «

/* CODEC_GUID_PNG 0E0C858D-28E0-45DB-ADAA0F83E57CC560 */

# define XR_CODEC_GUID_PNG \

» \x8D\x85\x0C\x0E\xE0\x28\xDB\x45\xAD\xAA\x0F\x83\xE5\x7C\xC5\x60 «

This sounds very interesting, but I unable to use them. Can someone tell me how to do?

The text was updated successfully, but these errors were encountered:

Источник

Включаем Enhanced Session Mode для Arch Linux-гостей в Hyper-V

Пользование виртуальными машинами на Linux в Hyper-V из коробки — несколько менее комфортное занятие, чем с гостевыми Windows-машинами. Причиной тому является то, что Hyper-V все же изначально не предназначался для десктопного пользования; нельзя просто взять, поставить пакет гостевых дополнений и получить работоспособное графическое ускорение, буфер обмена, общие директории и другие радости жизни, как это происходит в VirtualBox.

Hyper-V сам предоставляет несколько сервисов интеграции — так, гости могут пользоваться службой теневого копирования (VSS) хоста, гостям можно послать сигнал выключения, гости могут синхронизировать системное время с хостом виртуализации, с хоста возможен обмен файлами с виртуальной машиной ( Copy-VMFile в PowerShell). Для некоторых гостевых операционных систем, в числе которых, конечно, находится и Windows, в приложении Virtual Machine Connection ( vmconnect.exe ) доступен Enhanced Session Mode, работающий по протоколу RDP и позволяющий пробрасывать в виртуальную машину дисковые устройства и принтеры, а также пользоваться общим буфером обмена.

Enhanced Session Mode из коробки работает в Windows в Hyper-V сразу после установки. С гостями на Linux нужно устанавливать RDP-сервер, поддерживающий vsock (специальное виртуальное сетевое адресное пространство в Linux, предназначенное для коммуникации с гипервизором). Если для Ubuntu в приложении VMCreate, идущим с Hyper-V на настольных редакциях Windows, есть специальный подготовленный шаблон виртуальной машины, в котором работающий с vsock RDP-сервер XRDP уже предустановлен, то с другими дистрибутивами все менее однозначно — так, у автора этого поста получилось включить ESM в Fedora. Здесь же мы активируем Enhanced Session Mode для виртуальной машины с Arch Linux.

Установка сервисов интеграции

Здесь все более или менее просто, нам достаточно установить пакет hyperv из репозитория community:

Включим сервисы VSS, обмена метаданными и файлами:

Установка XRDP

Репозиторий linux-vm-tools на GitHub предоставляет скрипты, автоматизирующие процесс установки и настройки XRDP, для Arch Linux и Ubuntu. Установим Git, если он еще не установлен, вместе с компилятором и другим софтом для ручных сборок, после чего склонируем репозиторий:

На момент написания этой статьи самым свежим выпуском XRDP, который устанавливается скриптом makepkg.sh , предложенным в репозитории, является 0.9.11, в котором сломан парсинг vsock:// -адресов, поэтому придется установить XRDP из Git и драйвер Xorg к нему из AUR вручную. Патч к XRDP, предлагаемый в AUR, также слегка устарел, поэтому придется отредактировать PKGBUILD и патч вручную.

Склонируем репозитории с PKGBUILD-ами из AUR (обычно эту процедуру вместе со сборкой автоматизируют программами вроде yay, но автор проделывал всю эту процедуру на чистой системе):

Установим сначала сам XRDP. Откроем файл PKGBUILD любым текстовым редактором.

Отредактируем параметры сборки. PKGBUILD для сборки XRDP из Git не включает поддержку vsock при сборке, поэтому включим ее самостоятельно:

В патче arch-config.diff , правящем юниты и скрипты запуска XRDP под пути к файлам, используемым в Arch Linux, содержится в том числе патч к скрипту instfiles/xrdp.sh , который на момент написания статьи был удален из поставки XRDP, поэтому патч придется отредактировать вручную (примечание от 15-03-2020: патч актуализирован, редактировать его более не требуется):

Соберем и установим пакет командой % makepkg —skipchecksums -si (ключ —skipchecksums нужен для отключения проверки контрольных сумм исходных файлов, поскольку мы редактировали их вручную).

Перейдем в директорию xorgxrdp-devel-git , после чего просто соберем пакет командой % makepkg -si .

Перейдем в директорию linux-vm-tools/arch и запустим скрипт install-config.sh , устанавливающий настройки XRDP, PolicyKit и PAM:

Скрипт устанавливает устаревшую настройку use_vsock , которая игнорируется с версии 0.9.11, поэтому отредактируем файл конфигурации /etc/xrdp/xrdp.ini вручную (примечание от 15-03-2020: скрипт обновили, редактировать конфигурацию более не нужно):

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

Выключим виртуальную машину. Активируем транспорт vsock для виртуальной машины, выполнив следующую команду в PowerShell от администратора:

Включим виртуальную машину снова.

Подключение

Как только после запуска системы запустится сервис XRDP, приложение vmconnect это определит и в меню станет доступен пункт View -> Enhanced Session. При выборе этого пункта нам предложат установить разрешение экрана, а на вкладке Local Resources открывшегося диалога можно будет выбрать устройства, пробрасываемые внутрь RDP-сессии.

Подключимся. Увидим окно входа XRDP:

Введем свои имя пользователя и пароль.

Использование

Профит от этих манипуляций заметен: сессия RDP работает намного отзывчивее, чем при работе с виртуальным дисплеем без Enhanced Session. Проброшенные внутрь VM через RDP диски доступны в директории $/shared-drives :

Буфер обмена работает нормально. Пробрасывать принтеры внутрь нельзя, это не только не поддерживается, но и ломает проброс дисков. Также не работает звук, но автору это и не требовалось. Для того, чтобы захватывались сочетания клавиш вроде Alt+Tab, нужно разворачивать vmconnect на весь экран.

Источник

Ubuntu + XRDP + x11RDP терминальный сервер, с поддержкой звука, для серфинга в интернете — пошаговое руководство

Особенно нетерпеливых отсылаю сразу в конец статьи где будет ссылка на готовый .deb-пакет для установки.

А для всех остальных…

Что это такое и для чего это нужно

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

История номер один. (основано на реальных событиях)

Предположим бухгалтеру, в конце отчетного периода, когда все «на ушах», на
эл.почту приходит страшное письмо от «Налоговой Полиции» в котором говорится о том, что её фирма попала под жуткую проверку и ей следует немедленно ознакомиться с официальным документом который находится в прикреплённом к письму файле.
В панике бухгалтер пытается открыть прикреплённый файл и… все компьютеры фирмы подключенные в данный момент к внутренней локальной сети получают порцию вируса щифровальщика который парализует работу фирмы не не один день.

В случае с реализацией доступа через терминал на всех! компьютерах блокируется прямой доступ в интернет. Если работнику понадобилось в сеть для серфинга (почта, скайп, мессенджер) то он просто щелкает по иконке на рабочем столе и попадает на альтернативный рабочий стол где он может делать всё что угодно. В случае заражения при просмотре почты или любым другим способом вирус попадает на одинокую локальную машину (терминальный сеанс) которая не имеет доступа к сети предприятия и другим компьютерам. Так же в данном сеансе не хранятся важные документы и бухгалтерские базы данных. Поэтому ущерба, даже при полном удалении информации внутри сеанса, не будет абсолютно ни какого. Так же терминальную сессию можно просто свернуть в трей и открывать по мере необходимости, если пикнуло сообщение от мессенджера или поступил скайп звонок.

История номер два. (основано на реальных событиях)

Предположим один из сотрудников принес на флешке взломанную лицензионную программу которую поставил к себе на компьютер, в данном случае не рассматриваем доменные структуры AD, речь идет о небольших фирмах где не содержат штат сетевиков. После установки данной программы она спокойно может пожаловаться разработчикам через интернет что на компьютере по такому то IP кто то поставил взломанную версию и спокойно пользуется.
Дальше дело техники. Причем разборки могут быть очень серьёзные.
При реализации варианта терминал сервера данный вариант так же не проходит так как у локального компьютера просто нет доступа к сети и любая программа шпион не сможет вынести сор из избы.

Предисловие

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

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

Сборка и тестирование производилось на виртуальной машине от virtualbox. При использовании чистого железа так же могут возникнуть проблемы с настройками драйверов. Из программного обеспечения были использованы Ubuntu 16.04 LTS server / x11RDP 7.6 / xRPD 0.9.2. На других версиях данное решение не тестировалось и не проверялось.

XRDP является специальным прокси-сервером который прослушивает RDP port 3389 на предмет внешних запросов. Принимает на него подключения и далее, в зависимости от настроек, переадресовывает их на внутренние порты OS.

Для установки скомпилируем необходимые пакеты:

По умолчанию в репозиториях UBUNTU 16.04 находится пакет xRDP v0.6.0 в котором я не смог найти решения для рализации передачи звука. Поэтому собирать новую версию xRDP будем из исходников.

На многих сайтах советуют клонировать свежую версию при помощи git:

Но, в данном случае, возникает риск того что, на момент тестирования, вы можете столкнуться с совершенно новой версией имеющей значительные отличия от v0.9.2 и что то может пойти не так. Поэтому скачиваем и распаковываем фиксированный пакет XRDP v0.9.2 с сайта разработчиков.

Перейдем в каталог с XRPD и начнем компиляцию:

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

Установим библиотеки необходимые для переадресации звука.

Добавляем ключ активирующий звук —enable-load_pulse_modules при конфигурации пакета, собираем и устанавливаем.

Теперь скопируем ключ защиты. В данном файле содержится пара ключей RSA, используемая для аутентификации удаленного клиента. Открытый ключ является самозаверяющим. Если этого не сделать то при подключении получим ошибку протокола RDP.

Добавляем XRDP в автозагрузку. Для автозагрузки будем использовать systemd:

Проверим прошла ли установка:

$ xrdp: A Remote Desktop Protocol server.
Copyright © Jay Sorg 2004-2014
See www.xrdp.org for more information.
Version 0.9.2

Если все сделано верно то теперь можно попробовать подключиться к серверу при помощи любого RDP клиента с другого компьютера. Или установить на этой же тестовой машине клиент freerdp:

И подключится локально внутри системы.

Дальше стартовой заставки дело не пойдет потому что у нас пока не установлена серверная часть ПО которой прокси сервер XRDP был бы должен передать управление.

x11RDP

В качестве серверной части могут быть использованы серверные модули поддерживающие разные протоколы передачи данных. В данном варианте будем использовать x11RDP v7.6.

Небольшое отступление

Все дело в том, что установленный нами ранее прокси XRDP 0.9.2 не может, без доработок, перебрасывать подключения к предыдущей версии сервера x11RDP v7.1 на котором, в свою очередь, отсутствует известная проблема с переключением раскладок клавиатуры ru/en как при создании нового сеанса так и при переподключении к старой сессии.

А при использовании старой версии прокси XRDP 0.6.0 с которой работает сервер x11RDP v7.1 мы не сможем осуществить переброс звука так как XRDP 0.6.0 не поддерживает ключ —enable-load_pulse_modules.

Для установки x11RDP v 7.6 вернемся в каталог:

Создадим каталог для установки пакета и произведем сборку.

Сборка происходит достаточно долго 15-30 мин. Команда time позволит нам увидеть, по окончании процесса процесса, сколько было затрачено времени.

Теперь у нас есть и RDP прокси и RDP сервер которому прокси передаст управление. Но нет графического приложения которое RDP сервер сможет вывести на экран.

Для дальнейшего тестирования, чтобы убедиться что все установки прошли успешно, установим графический эмулятор терминала xterm.

И попробуем подключиться к серверу со стороны, или локально если ранее установили freerdp.

Теперь из меню необходимо выбрать x11RDP чтобы указать прокси какому именно серверу должно быть передано управление и ввести логин и пароль к ubuntu серверу.

Если все верно то на экране мы увидим графический интерфейс терминала xterm.

Настройка языковой консоли и режима переключения языков

Почти все основные настройки клавиатуры в ubuntu осуществляются при прмощи пакета setxkbmap.

Для начала закроем терминальную сессию и вернемся в консоль нашего ubuntu сервера
посмотрим что творится с клавиатурой.

Теперь подключимся к серверу терминалов и в терминале xterm выполним ту же команду:

$ Trying to build keymap using the following components:
keycodes: xfree86+aliases(qwerty)
types: complete
compat: complete
symbols: pc+us+inet(pc105)
geometry: pc(pc105)
xkb_keymap <
xkb_keycodes < include «xfree86+aliases(qwerty)» >;
xkb_types < include «complete» >;
xkb_compat < include «complete» >;
xkb_symbols < include «pc+us+inet(pc105)» >;
xkb_geometry < include «pc(pc105)» >;
>;

Есть русская консоль и определены клавиши переключения языка alt_shift. На сервере терминалов противоположность:

Есть только английский язык и клавиши переключения языка не определены.

Есть еще одна странность. Локально, на сервере ubuntu, модель клавиатуры определилась как pc104:

А на сервере терминалов как pc105:

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

Вернемся к ubuntu серверу и посмотрим что установлено в конфигурационных файлах системы
по умолчанию

$ # KEYBOARD CONFIGURATION FILE
# Consult the keyboard(5) manual page.
XKBMODEL=«pc105»
XKBLAYOUT=«us,ru»
XKBVARIANT=»,»
XKBOPTIONS=«grp:alt_shift_toggle,grp_led:scroll»
BACKSPACE=«guess»

Установим hwinfo (сборщик информации об аппаратной части системы) и посмотрим информацию о железе:

В итоге аппаратно модель клавиатуры, в нашем случае определяется как pc104, в файлах конфигурации системы прописано обращение к устройству pc105. На локальном сервере определяется pc104, на сервере терминалов pc105. Из за данного несоответствия, в частности, возникает несколько глюков. Многие пишут что не могут справиться с настройкой локали на терминальном сервере. У некоторых пропадает русификация после переподключении к отвалившейся сессии и те пе.

Откроем в любом текстовом редакторе (я использую в примере редактор nano) файл конфигурации системы и исправим тип клавиатуры по умолчанию в соответствии с данными полученными от hwinfo:

Файл клавиатурных настроек программы XRDP 0.9.2 находится в файле
/etc/xrdp/xrdp_keyboard.ini. Эти данные прокси передает xRDP серверу как данные клиента который производит подключение. Откроем его и добавим в конец данного файла блок поддержки русской локали.

Предварительно исправив модель клавиатуры на верную model=pc104 (в оригнальной версии установлена pc105):

Добавляем в конец файла:

[rdp_keyboard_ru]
keyboard_type=4
keyboard_subtype=1
model=pc104
options=grp:alt_shift_toggle
rdp_layouts=default_rdp_layouts
layouts_map=layouts_map_ru

[layouts_map_ru]
rdp_layout_us=us,ru
rdp_layout_ru=us,ru

Подключаемся к терминальному серверу. Проверяем клавиатурные настройки:

$ Trying to build keymap using the following components:
keycodes: xfree86+aliases(qwerty)
types: complete
compat: complete
symbols: pc+us+ru:2+group(alt_shift_toggle)
geometry: pc(pc104)
xkb_keymap <
xkb_keycodes < include «xfree86+aliases(qwerty)» >;
xkb_types < include «complete» >;
xkb_compat < include «complete» >;
xkb_symbols < include «pc+us+ru:2+group(alt_shift_toggle)» >;
xkb_geometry < include «pc(pc104)» >;

Все в порядке, клавиатура определяется верно:

и появился русский язык с переключением по alt_shift. Закрываем сеанс оставляя его работать в фоне и переподключаемся к нему же снова чтобы проверить что не возникает известной проблемы при которой локаль пропадает при переподключении к уже открытому ранее сеансу.

В ubuntu старше 10.10, по умолчанию, за вывод звука отвечает сервер pulseaudio. В десктопных дистрибутивах он уже установлен. В серверных нет. Поэтому установим его.

Посмотрим и запишем номер версии пакета который по умолчанию установился в нашу систему:

Для начала скачаем исходники pulseaudio. Сделать это можно двумя способами.

1. Скачать общую версию с сайта разработчиков (freedesktop.org/software/pulseaudio/releases/) скачивать надо именно ту версию которую мы определили ранее. В нашем случае pulseaudio 8.0

2. Более правильно — подключить deb-src репозитории системы и получить исходники которые использовали авторы данного ubuntu дистрибутива.

По умолчаню ссылки на исходники в ubuntu отключены. Для подключения отредактируем файл списка репозиториев:

Необходимо удалить значки # перед всеми списками deb-src репозиториев.

$ E: Вы должны заполнить sources.list, поместив туда URI источников пакетов

Переходим в установочный каталог XRDP:

Исправляем make файл.

/pulseaudio* в данном случае не проходят. Необходимо точно прописать адрес каталога.

Замените admin на имя пользователя в Вашей системе. Сохраняем исправленный файл и делаем:

Если все выполнено верно в каталоге будут скомпилированы 2 новых библиотеки
module-xrdp-sink.so и module-xrdp-source.so.

Осталось только скопировать их в рабочий каталог с библиотеками сервера pulseaudio:

После перезапуска звук будет активирован.

Осталось установить любую удобную графическую оболочку. Для терминального сервера желательно что то не ресурсоемкое.

XFCE
Минимальный набор элементов:

Полный набор элементов:

LXDE
Минимальный набор элементов:

Полный набор элементов:

В зависимости от версии установленной графической оболочки, для её запуска возможно понадобится настроить файл .xsession

Готовый пакет для установки

XRDP v0.9.2 + скомпилированные библиотеки pulseaudio 8.0 + исправленный keyboard.ini файл для поддержки русификации. Те же кто не хочет сам собирать бакенд x11RDP v7.6 по этой же ссылке могут скачать готовый deb пакет бакенда xorg v.0.2.0. Порядок установки для совсем ленивых

Повторюсь что пакеты собирались практически на коленках и работа протестирована только
на ubuntu 16.04 server. Работоспособность данных .deb-пакетов на других системах не гарантирована.

Источник