Виртуализация приложений. Обзор технологии. Часть 2. Ericom PowerTerm WebConnect

Теперь пришла очередь рассказать о чудном продукте, таком как Ericom PowerTerm WebConnect. Он тоже умеет присылать с сервера картинки работающих там приложений.

Сразу скажу: продукт ужасен по своему пользовательскому интерфейсу (черт ногу сломит в настройках), а также у него просто ужасная документация. Замечательный пример по поводу того, как НЕ надо писать документацию. Я потратил 2 дня, чтобы разобраться, что там к чему, и вот пошаговая инструкция.

Нам понадобится две Windows - системы, из одной сделаем сервер приложений, а вторую будем использовать как клиентскую машину, запуская изображения работающих приложений с сервера.

(1) Скачиваем дистрибутив, предварительно ответив на вопросы дурацкой анкеты. В нее можно вводить всё, что угодно, никакие поля не проверяются, email можно вводить в виде абракадабры, но с обязательной собачкой посередине :) В результате заполнения этой анкеты дается прямая ссылка на дистрибутив, 251 Мб.

(2) Устанавливаем, выбирая режим Evaluate - нам дастся 30 дней на изучение продукта.
Установщик состоит из кучи продуктов, некоторые из которых взаимодействуют друг с другом, некоторые нет, есть даже такие продукты, которые устанавливаются в виде файла установщика.... И их надо потом еще раз устанавливать из каталога с продуктом... Понять, какие компоненты нужны для целей Application Streaming, а какие лишние, не представляется возможным, поэтому ставим всё, и на сервер, и на клиентские компьютеры.



В конце установки нажимаем Finish.

(3) Запуск и настройка на серверном компьютере.

Для сервера установленного программного обеспечения не достаточно, несмотря на то, что мы при установке выбрали опцию "установить всё". Нужно обязательно поставить еще вот этот компонент, который установился в виде инсталляшки:
C:\Program Files\Ericom Software\WebConnect 5.6\AddOns\TerminalServerAgent\PowerTermTerminalServerAgent.exe

Также на серверном компьютере нужно остановить (задизэблить) сервис Windows Firewall, потому что он не даст нам работать.

Запускаем Пуск - Программы - Ericom Software - PowerTerm WebConnect 5.6 - PowerTerm WebConnect Administration Tool. Появится окошко:

Нажимаем Cancel, потому что сервер еще не запущен. В главном окне запускаем сервер:

А уже потом выходим в меню Server-Connect, видим опять окошко авторизации, ничего там не меняем. Пароль пустой. Нажимаем Connect. Должно получиться зайти в админскую консоль, которая выглядит так:

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

Потом нажимаем на иконку с человеком и задаем пароль для юзера user. Также ставим галочку Free User.


Также редактируем пользователя Administrator, нужно поставить галочку Allow Concurrent Machines, иначе не получится сконфигурировать клиентов. Как только все клиенты настроены, эту галочку надо обратно снять, чтобы администратор не смог залогиниться в утилиту с другого компа (сможет только с сервера через соединение к localhost).

Теперь публикуем приложения, которые можно будет запускать через Remote Desktop с клиентских компьютеров:
Должно открыться вот такое окошко:
в нем ничего не меняем, нажимаем ОК, и дальше должно появиться окошко с выбором приложений для публикации, в котором выбираем приложения, которые будут использоваться удаленно юзерами.
Если это окошко не появилось, а вместо него появился MessageBox, который просит запустить Desktop View Service, то тут надо сделать так, как описано ниже. Вообще, интерфейс программы довольно поганый - она говорит, что надо запустить какой-то сервис, при этом абсолютно не понятно, как его запустить, где его взять, и почему она сама его не запустила, если он нужен... Есть подозрения, что он запускается сам при каких-то определенных условиях, например при вот этом.

Если не получилось опубликовать сразу несколько приложений, получится опубликовать приложения по одному (а после этого получится и много опубликовать). Для этого выбираем такой пункт меню:

Потом пробегаемся по мастеру:


Второй шаг. Многоточие около первого Edit Box может по странным причинам не работать, поэтому текст надо вбить от руки.


Далее несколько шагов интуитивны; на 7 шаге надо поставить галочку у Disk Drives - тогда жесткие диски клиента примонтируются к серверу.

Вот на этом шаге нельзя писать localhost в поле address, потому что тогда RemoteDesktop не сможет работать. Поэтому пишем IP адрес нашего сервера, все остальное не меняем:


На этом же экране можно выбрать Load Balancer - это именно та штука, которая позволяет перенаправлять клиентов на свободный сервер, потому что тут ограничение то же, что и для SeamlessRDP - один клиент использует один сервер, и второй клиент не может запустить приложение с того же самого сервера. Ему нужен другой сервер, на котором точно так же нет залогиненного юзера.

Доходим до последнего, 12-го шага. и тут обязательно надо нажать на кнопку Advanced, и прописать виндусовый логин и пароль для соединения с сервером.

Итак, все готово!
Вот что получилось после опубликования двух приложений на сервере:

(4) теперь настраиваем клиентские компьютеры.

Тривиального способа запустить Application Zone, по-видимому, нет, делать всё придется через {censored}.
Чтобы запустить Application Zone, нужно:
- Залогиниться с клиентсокго компа как администратор на сервере
- Запустить Application Zone
- В этом приложении включить галочку "запускать при старте Windows" и помесить иконку на рабочий стол
- потом можно запускать AppZone под непривилегированным пользователем.

Делаем. Логинимся на наш сервер под администратором. Не забываем указать правильный IP адрес сервера.
После логина нажимаем на этот пункт меню:
В трее запустится Application Zone, надо будет нажать на значок в трее и выбрать пункт Open Application Zone. Вот что получилось:
В меню Options надо выбрать Create a Shortcut on the Desktop, и собственно это всё. Теперь можно закрыть Administration Tool и на сервере запрещать администратору логиниться с удаленного компьютера.

Иконка, кстати, создалась на десктопе с нетривиальными параметрами (даже с буквами ю):
"C:\Program Files\Ericom Software\WebConnect 5.6\bin\PtAgent.exe" /CREDFILE=WebConnect_ю_192.168.5.43_4001ю.dat -efdю

(5) Запуск удаленных приложений с компьютеров клиентов

Разлогиниваемся с сервера!

Запускаем Application Zone по иконке и логинимся как user, т.е. непривилегированным пользователем, потом нажимаем на значок в трее и выбираем пункт Open Application Zone.

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


Звук передается тоже, правда прерывистый... занимаемый траффик 3 мегабита в секунду.

Виртуализация приложений. Обзор технологии. Часть 1. SeamlessRDP

Виртуализация отдельных приложений в варианте, когда картинка работающего на сервере приложения гонится с сервера на юзерское устройство, называется Application Streaming. При этом на клиентский компьютер не устанавливается код приложения ни в каком виде, пользователь просто видит интерактивную картинку с содержимым приложения.

Основные продукты на рынке, которые это умеют:
* Citrix XenApp (об нем в следующих выпусках; дистрибутив занимает 4,5 гига).
* Ericom PowerTerm WebConnect (об нем читайте в этом посте, он тоже платный)
* SeamlessRDP (опенсорс!). Об нем настоящая статья.

Что потребуется для работы:
1) Windows-Сервер в интернете (или в локальной сети). На него устанавливаем игры, приложения для использования пользователями. Для целей этой заметки используем локальный сервер 192.168.5.43.
2) Также на сервер ставим надстройку над RDP - SeamlessRDP. Распаковать архив на сервере в папку C:\SRDP.
3) rdesktop - нужно скачать и скомпилять под CygWin-ом. Эта утилита будет использоваться на компах пользователей.
4) X-сервер, любой, например Xming. Он тоже ставится на компах юзеров.

Условия:
- на сервере не должно быть залогиненного пользователя! Если там кто-то залогинен, то работать Application Streaming не будет.

Что делаем:
1) Запускаем X-сервер
2) Запускаем
rdesktop.exe -u Administrator -p пароль -a 16 -A -s "C:\SRDP\seamlessrdpshell.exe C:\Portables\Farm\fantastic farm.exe" 192.168.5.43
3) Играем через Application Streaming - это картинка с удаленного сервера, выглядит, как будто я запустил игру со своего компьютера.



Игра немножко тормозит, что естественно при передаче большого количества видеоданных по сети. Поток данных с этой игры я намерял в размере 2,7 мегабит в сек.
Если запустить офисные приложения, то тормозов не заметно.

При закрытии игры/приложения автоматически происходит разлогинивание пользователя с сервера, и сервер становится готов принимать новые соединения по SeamlessRDP.

Преимущества такого подхода: можно запускать Windows-приложения из-под Linux, поскольку команда rdesktop - родная для Linux, она есть в стандартном наборе утилит.

Причины вайнофобии

Вот так выглядит пользовательский интерфейс одного Windows-приложения, запущенного под Mac OS X 10.6.2 с использованием самого последнего Wine 1.2rc2. И это, кстати, не статическая страничка. Та же самая программа несколькими секундами позднее выглядит так, как показано на второй картинке. Это произошло после того, как был собран из исходников и установлен требующийся этому приложению libXrender-0.9.5. В этой заметке я попытаюсь провести анализ того, почему многим так страшно работать с Wine. Почему опытные разработчики открещиваются от wine? Я бы выделил несколько причин.

Во-первых, wine - это "не красиво". Это искусственное образование, которое, по сути, является попыткой придумать свой windows по опыту наблюдения над настоящей windows как над черным ящиком.
К примеру, в wine есть собственная реализация библиотеки msxml3. Эта библиотека зачем-то нужна при регистрации COM-компонентов (dll), и regsvr32 падает на unhandled exception при использовании самописной msxml3. Именно поэтому есть такой "черный ход", когда самописная msxml3 подменяется на настоящую, взятую с windows (т.н. "нативная"). С нативной либой все нормально.
Второй пример. Есть своя собственная реализация gdiplus. Эта библиотека нужна для работы с графикой. Так вот, самописная реализация не написана, похоже, чуть более чем на половину, поскольку простейшие тестовые примеры, использующие gdiplus, не работают. Доступный в исходных кодах пример использования gdiplus, который позволяет рисовать полигоны и потом рисовать между точками плавные линии, не работает! Полигоны рисуются, а вот перерисовывать прямые линии на кривые уже не может. Тут на помощь опять-таки приходит winetricks, когда с настоящей windows берется настоящая библиотека gdiplus. С ней все работает нормально.

Во-вторых, это очень сложно. Очень сложно вести разработку для wine, модифицировать его исходный код, ввиду следующих особенностей:
- нет однозначного отображения пространства функций из Windows в Linux/Mac.
- исходного кода очень много, сотни мегабайт.
- существуют нетривиальные зависимости между компонентами системы. Например, показанные на картинках выше "эффекты" - это дело рук Xrender, компонента X11, т.е. реализации алгоритмов добавления "теней" вокруг окошек на основе использования альфа-канала (alpha blend). Именно так: чтобы система умела рисовать тени вокруг окошек, пришлось собрать из исходников Xrender (а это значит собрать вот такие пакеты в таком порядке: randrproto-1.3.1.tar.bz2 xineramaproto-1.2.tar.bz2 libXext-1.1.1.tar.bz2 libXfixes-4.0.4.tar.bz2 fixesproto-4.1.tar.bz2 compositeproto-0.4.1.tar.bz2 libICE-1.0.6.tar.bz2 X11-xshape-0.1.1.tar.gz libSM-1.1.1.tar.bz2 libXcomposite-0.4.1.tar.bz2 libXinerama-1.1.tar.bz2 libXrandr-1.3.0.tar.bz2 libXxf86vm-1.1.0.tar.bz2 libXi-1.3.tar.bz2 libXcursor-1.1.10.tar.bz2 renderproto-0.11.tar.bz2 libXau-1.0.5.tar.bz2 libpthread-stubs-0.3.tar.bz2 xcb-proto-1.6.tar.bz2 libxcb-1.6.tar.bz2 xtrans-1.2.5.tar.bz2 xextproto-7.1.1.tar.bz2 kbproto-1.0.4.tar.bz2 inputproto-2.0.tar.bz2 xproto-7.0.17.tar.bz2 libX11-1.3.3.tar.bz2 libXrender-0.9.5.tar.bz2 - 7 мб сильно сжатых исходников). И вот теперь получается, что в каком-то из этих пакетов ошибка, приводящая к такой вот красоте, как на картинках. Т.е. получается, что помимо исходников самого wine (126 мб), требуется еще ковыряться в багах X11 и возможно не только его.
- существуют "баги на багах, которые дают фичу". То есть бага в windows библиотеках и в приложениях, в результате все работает как надо. А если перенести это все в wine, то работать все перестает.

"Сложно" и "не красиво" это проблемы первого порядка. Если не иметь опыта управления проектами по разработке программного продукта, то эти две проблемы могут остановить любого.

Мне же видится, что с этими проблемами можно что-то сделать, чтобы они не казались такими страшными. На мой взгляд, это:
- разработка системы юнит-тестирования всего. Вообще всего. Это главная проблема, потому что это очень долго и трудоемко, но без этого никуда. Я подозреваю, что в самом "логове" (Microsoft) очередная сборка операционной системы проходит в буквальном смысле миллионы автоматических тестов. Тестируется каждый метод, каждая функция каждой библиотеки, и зоркие глаза тестовых скриптов внимательно следят за тем, чтобы все было как ожидается в тесте. При обнаружении баги проблемная dll локализуется, бага исправляется, запускается перетестирование.
В wine ничего этого, похоже, нет. Есть 17-летняя работа по написанию этого wine, но нет тестов. Странно. В их понимании, видимо, "тестирование" - это запуски разных программ под wine и присваивание им уровней совместимости "золотой", "серебряный", "бронзовый" - т.е. функциональное тестирование, а не юнит-тестирование.
- декомпозиция всех фич винды на маленькие тестовые примеры, эксплуатирующие одну конкретную фичу типа построения сплайнов по нескольким точкам.

Вот если иметь перед собой набор из 5000 фич, которые не работают в wine, и планомерно, хладнокровно, фиксить эти фичи одна-за-одной, то будет прогресс. Но это очень дорого по людям и затратам. И поэтому такой вариант не случится, поскольку он не окупит затрат.

Люди из WineSkin сделали уже очень многое. Они как раз решают две задачи, важные с точки зрения практического применения wine под Mac OS:
- они вкручивают в него собственную сборку X11
- добавляют обертку для представления wine + win приложение в качестве настоящего приложения Mac, с маковским меню.

На данный момент я вижу работу в использовании наработок wineskin + прохаченный winetricks'ом набор библиотек (т.е. некоторые dll подменены на настоящие). Но это не решит всех проблем. Рано или поздно, придется ковыряться в этом наборе из сотен мегабайт исходного кода... Вот скажем, где зарыта бага, ведущая к таким красивым картинкам? Ответ нетривиальный...

Сборка вина под тигром

Наконец-то удалось собрать wine под Mac OS Tiger 10.4.11. Не думал, что это представляет из себя такие сложности.

Почему Tiger? Потому, что у меня в виртуальной машине более старшие версии хакинтоша (Leopard, Snow Leopard) не ставятся: уже на момент запуска инсталлятора идет бесконечный ребут. Подозрения на то, что этому инсталлятору нужна поддержка VT-x в процессоре.

Итак, что нам потребуется.
XCode 2.5 - на более старых версиях не собирается вообще. Эту версию Xcode придется скачать и установить, т.к. на установочном диске идет версия 2.4.1. (Для leo нужна уже другая версия Xcode, 3.1.4).
flex-2.5.35
git-1.7.1
freetype-2.3.12
zlib-1.2.5
fontforge
pkgconfig-0.18
fontconfig-2.8.0 - конфигурировать с префиксом /usr/X11R6
jpeg-8b
libpng-1.4.2
tiff-3.9.2


Потом скачиваем последние исходники wine:

git clone git://source.winehq.org/git/wine.git ~/wine-git

И после этого все должно собраться. Сборка идет оочень долго: на 2 ггц компе это целый день. Как видим на скриншоте, папка с исходниками wine после его компиляции занимает 770 мегабайт, а папка с установленным wine - 180 мегабайт.

Далее такие настройки для запуска wine:

export DISPLAY=:0.0
x&
xhost +local:
export WINEPREFIX=/Users/danx/Public/work/.wine
export PATH=/Users/danx/Public/work/bin:$PATH
winecfg (здесь согласиться установить gecko)