VDS защищается от неопытных пользователей

Похоже, системные администраторы в немецких дата-центрах сделали всё возможное, чтобы не дать неопытному человеку самостоятельно поднять сервер на VDS (скорее всего они пойдут в платную техподдержку).
Вот пример: провайдер interserver.ru. Чтобы поднять обычный LAMP сервер на SUSE11.3, пришлось столкнуться со следующим:
1) "Контейнер" (операционная система) содержит крайне урезанный набор пакетов. Практически ничего нет. это конечно хорошо, ничего лишнего, поскольку каждый мегабайт на счету, но... YaST2 не работает:


Это связано с тем, что не установлен пакет yast2-ncurses-pkg и в графическом интерфейсе yast его никак не установить.

2) Делаем попытку каким-то образом установить недостающий пакет, не используя установщиков с интерфейсом пользователя. На счастье в SuSE есть такая утилита командной строки, как zypper.
Но для начала надо его настроить, добавив репозитории. Тоже не всякий виндовый юзер сообразит как это делается. Вот так:
zypper ar -n suse11.3 http://ftp.gwdg.de/pub/linux/misc/packman/suse/11.3/ suse11.3
zypper ar -n opensuse11.3 http://download.opensuse.org/distribution/11.3/repo/oss/suse/ opensuse11.3

3) Далее, нас, как оказывается, не спасает даже команда zypper in yast2-ncurses-pkg.
Понимаем, что это было зря, поскольку теперь yast выдает ошибку "Error while creating client module sw_single"... Забиваем окончательно на yast, эту команду не вводим, чтобы не устанавливались лишние пакеты. Переходим на командную строку zypper. Все-таки командная строка - сила!

4) Ура. Мы на втором уровне :) и теперь снова можем ставить недостающий софт на VDS! делаем это:
zypper in mysql php php5-mysql mcrypt apache2-mod_php5

Далее оказывается, что установить mysql на автозапуск командой chkconfig mysql 3 невозможно, поскольку есть бага в самом скрипте крона!

# chkconfig mysql 3
insserv: warning: script 'S10vzquota' missing LSB tags and overrides
insserv: warning: script is corrupt or invalid: /etc/init.d/rc6.d/S00vzreboot
insserv: warning: script 'vzquota' missing LSB tags and overrides
insserv: warning: script 'S10vzquota' missing LSB tags and overrides
insserv: warning: script is corrupt or invalid: /etc/init.d/rc6.d/S00vzreboot
insserv: warning: script 'vzquota' missing LSB tags and overrides
insserv: FATAL: service boot.shm has to exists for service boot.rootfsck
insserv: exiting now!
/sbin/insserv failed, exit code 1

Вставляем в начало скрипта /etc/init.d/rc6.d/S00vzreboot комменты так, как написано тут:
http://serverfault.com/questions/248325/debian-squeeze-vzquota
Это избавит нас от части ошибок.

Далее, делаем такие две команды:
# mv /etc/init.d/rc6.d/S00vzreboot /etc/init.d/vzreboot
# ln -s /etc/init.d/vzreboot /etc/init.d/rc6.d/S00vzreboot
(спасибо http://accessdlab.blogspot.com/2010/06/s00vzreboot-trouble.html за решение)

Это приведет нас к такому сообщению об ошибке. Уже лучше:

# chkconfig mysql 3
insserv: FATAL: service boot.shm has to exists for service boot.rootfsck
insserv: exiting now!
/sbin/insserv failed, exit code 1

Эта ошибка из-за того, что в файле /etc/init.d/boot.rootfsck написано:

# Required-Start: boot.shm

А сервиса boot.shm в контейнере suse-11.3 нет. Поэтому просто удаляем слово boot.shm оттуда.

Всё, после этого установить mysql как сервис получается, ура!

перезапускаем апач:
service apache2 restart

И всё, LAMP работает, т.е. скрипты на PHP можно писать и тестировать.

Виртуализация приложений. Обзор технологии. Часть 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)

Пакетное перекодирование видео: cmd.exe + virtual dub + avisynth

В этом посте я расскажу, как правильно переконвертировать видео в нужный формат, используя только опен-сорсовые решения. Переконвертация будет на примере видео роликов от 5DMk2.

Для работы потребуются:
* Windows XP
* Avisynth, скачать и установить c одноименного сайта в домене org
* Virtual Dub, лежит тоже на своем сайте.
* K-lite codec pack с набором DirectShow кодеков

Ависинт используется для того, чтобы виртуал даб открывал неизвестные ему видеофайлы - а таких сейчас большинство: например, MOV, MKV файлы с кодеком H.264 и др.

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

Итак, шаги:
(1) Настраиваем кодеки:
Пуск->Программы->K-Lite Codec Pack->Configuration->ffdshow audio decoder -- ставим вот это поле в "all supported", иначе звука в видеоролике не будет:

Пуск->Программы->K-Lite Codec Pack->Configuration->ffdshow video decoder
Здесь надо сделать такие настройки для правильного декодирования цвета:


(2) Пишем простенький скрипт на ависинте, и сохраняем этот текст в файл с именем "3.avs":

DirectShowSource("PROCESS.MOV", fps=30).ConvertToYUY2(matrix="Rec709").TemporalSoften(4,4,8,15,2)

Параметр fps задает частоту кадров исходного видео, если она по каким-то причинам некорректно самоорпеделится. Тут важным параметром является matrix, который правильно конвертирует цвета.

(3) Далее открываем этот текстовый файл в virtual dub как видео, переключаем в меню Audio в Fill Processing Mode, потом Audio->Compression выставляем в AC3 384 Kbit/s (тут можно выбрать нужный аудио кодек по желанию; мои эксперименты показывают, что если выбрать MP3, то будет рассинхронизация аудио и видео в фильме).

(4) Выставляем компрессию видео: Video->Compression. Я выбираю XVID кодек и выставляю его настройки так:


(5) Теперь самое интересное: нажимаем File->Save as AVI и не забываем поставить внизу галочку.


(6) Потом переходим в File->Job Control и выбираем в этом меню пункт Save Job List и сохраняем файл описания будущей перекодировки как process.job.

(7) Теперь редактируем файл process.jobs - меняем вот эти строки

VirtualDub.subset.Clear();
VirtualDub.subset.AddRange(0,100);
VirtualDub.video.SetRange();
VirtualDub.project.ClearTextInfo();
// -- $reloadstop --
VirtualDub.SaveAVI("E:\\Photo\\2009_11_28\\MVI_0034.avi");

на такие:

VirtualDub.subset.Delete();
VirtualDub.video.SetRange();
VirtualDub.project.ClearTextInfo();
// -- $reloadstop --
VirtualDub.SaveAVI(VirtualDub.params[0]);

Все остальные строчки оставляем без изменения.

(8) Теперь все готово для автоматической перепаковки видеофайлов. Это будет делать вот этот скрипт:

@echo off                           

del /q /s PROCESS.MOV >nul 2>&1
FOR %%i IN (*.mov) do (
 if not exist %%~ni.avi (
   echo.
   echo.
   echo Re-compressing %%i
   ren %%i PROCESS.MOV
   set TM=!TIME::=!
   "C:\Program Files\VirtualDub\vdub.exe" /i recode.job %%~ni.avi  >nul
   set TM2=!TIME::=!
   set /A RES=!TM2:~0,2!*3600 + !TM2:~2,2!*60 + !TM2:~4,2! - !TM:~0,2!*3600 - !TM:~2,2!*60 - !TM:~4,2!
   set /A HRS=!RES! / 3600
   set /A MINS=!RES! - !HRS!*3600
   set /A MINS=!MINS! / 60
   set /A SECS=!RES! - !HRS!*3600 - !MINS!*60
   if !MINS! LSS 10 set MINS=0!MINS!
   if !SECS! LSS 10 set SECS=0!SECS!
   echo Elapsed time !HRS!:!MINS!:!SECS!
   ren PROCESS.MOV %%i
 )
)

Этот скрипт написан на языке командного интерпретатора cmd.exe. Чтобы он правильно работал, надо создать в реестре вот этот ключик DelayedExpansion = 1:

Этот ключик говорит о том, чтобы cmd.exe использовал отложенное связывание переменных со значениями. Это необходимо, т.к. иначе внутри цикла переменные бы не обновлялись. Чтобы они стали обновляться, необходимо обращаться к ним по имени типа !VAR! а не %VAR%.

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

Red5+ openfire + Jetty + mjsip = red5phone

Вот и настал день, когда я познакомился с Red5 на деле. Никогда не думал, что это произойдет 12 августа 2009 года. Сказать откровенно, эта технология заинтересовала меня пару месяцев назад, и я даже делал дежурные лукапы в википедии насчет того, что же это такое. Еще тогда я понял что это что-то нереально крутое, но поскольку не было необходимости эти технологии применять, то я благополучно оставил их в покое.

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

Сначала я не подозревал ничего загадочного и свято верил в то, что на флеше можно писать SIP user agent-ов... Даже предполагал о существовании какой-то реализцации SIP стека, портированного под адобовский Action Script.

Но не тут-то было. Еще по опыту программирования на Swift 3D я знал, что флеш (точнее, flex) - настолько тупой язык, что не умеет делать ничего кроме анимации и проигрывания аудио (т.е. видео ролик - формат flv это он и есть), плюс работа с клавиатурой и мышью. Как же видеоролик может работать как SIP soft phone?

Разгадка оказалась гениальная.

Начну с небольшой теории. Флеш - это клиент RTMP, т.е. потребитель стримингового аудио и видео, которое в простейшем случае просто хранится на сервере, льется в флеш клиента и таким образом получается та самая анимация во флеш-роликах.
Так вот. для того, чтобы флеш работал как SIP телефон, необходим Flash Server, или RTMP сервер. Red5 это и есть Flash Server.

Red5 написан на Java. Он сидит на компе-сервере, рядом с ним сидит сервлет-контейнер Jetty, который фактически является не чем иным, как веб-сервером, способным у себя на сервере исполнять Java-сервлеты.
Вот эта дружная парочка Red5 + Jetty может жить как сама по себе (это называется standalone Red5 server), либо они могут паратизировать внутри openfire.
Openfire это XMPP сервер (т.е. Jabber-сервер), но для него существует плагин Red5.

Итак, гремучая смесь openfire + red5 + Jetty сидит на сервере, она написана на Java, требует себе Java SE JDK 1.6, и также внутри red5 зашит mjsip - опен-сорсовый java-вский SIP стек.
Вот и разгадка головоломки. За SIP соединение с телефонным сервером отвечает mjsip стек внутри Java-вского приложения Red5 (кстати, он стоит как web service на Jetty). Red5 занимается перепаковкой RTP пакетов с payload (со звуком или видео) в протокол RTMP и стримит эти данные на флешовый "телефон" в клиентском браузере. В обе стороны от флеша до red5 и обратно ходят управляющие сообщения, которые на стороне red5 преобразуются в SIP сообщения.
Таким образом, все флешовые софт-телефоны, на самом-то деле, живут внутри red5 на стороне сервера, а на клиентской стороне висят только их флешовые анимашки.

Ну а теперь к практическому занятию. Давайте соединим FreeSWITCH и флешовый телефон. Для этого нам потребуется такие компоненты (ставить в указанном порядке):
1) FreeSWITCH в поставляемой по дефолту настройке
2) Java SE JDK 1.6 последняя. На момент написания поста была последняя Update 16, скачиваем и ставим: http://java.sun.com/javase/downloads/index.jsp
3) openfire. С ним все проще, т.к. внутри него уже есть Jetty и поэтому отдельный веб-сервер (Jetty, Tomcat или JBoss) и отдельный Red5 сервер ставить не надо. Скачиваем и ставим последнюю версию openfire отсюда: http://www.igniterealtime.org/projects/openfire/index.jsp. На момент написания поста последняя версия была 3.6.4.
4) Red5 openfire plugin: Скачиваем с сайта http://www.igniterealtime.org/projects/openfire/plugins-beta.jsp. Он помечен как beta, вот прямая ссылка. Скачиваем этот файл и подкладываем его в папку "C:\Program Files\Openfire\plugins\"

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

Далее запускаем openfire, заходим на страницу его администрирования и прощелкиваем все пункты кнопкой Далее. Тут важно именно щелкать эти кнопки по-порядку, а не пропускать некоторые - иначе openfire (точнее Jetty) вылетает в server failure.
После прощелкивания админки все готово к работе. Сформируется такой адрес для Red5: http://localhost:7070/red5/. Вот на этот адрес и надо зайти из браузера.

Все. Мы увидели в веб-страничке flash softphone, который надо зарегистрировать на FreeSWITCH и можно будет делать звонки.

Но! тут один нюанс: в этом софтфоне (он называется red5phone) бага, он не умеет авторизовываться, если пароль не пустой. Поэтому надо сделать пустой пароль для вашего внутреннего номера:
"C:\Program Files\FreeSWITCH\conf\directory\default\1000.xml"




Потом запускаем FreeSWITCH, прописываем в red5phone такие параметры:

Здесь IP-адрес - это адрес, на котором установлен FreeSWITCH, и voila!

Можно звонить! Вот показан пример как я с обычного софтфона звоню на флешфон:


Насчет глючности Red5Phone - радует что для него доступны исходные коды. Счастье есть :)

Follow-up касательно сообщения из первого поста про flaphone: "пока не разобрался, почему flaphone не может коннектиться к моему телефонному серверу".
Все теперь понятно, почему: потому что чтобы flaphone звонил, ему тоже нужен RTMP сервер! И поэтому он жестко завязан в коде на свой родной Netconnector URL своего RTMP сервера.
Кстати, flaphone сначала использовал именно Red5 в качестве RTMP сервера, потом они перешли на коммерческий продукт Wowza, а сейчас и вовсе сами написали свою реализацию RTMP сервера.