RX@Etersoft (ex. NX) Новые сведения.

Много байт утекло с тех пор, когда был написан пост о процессе установки и настройки NX-сервера на сервере с Debian'ом. Не скажу, что кардинально все поменялось, но кое-что освежить стоит.

Итак, на сегодняшний день по-прежнему практически единственным средством реализовать терминальный linux-сервер остается решение от NoMachine. Простота развертывания, защищенность передачи данных сеанса, скромные требования к ширине канала - все это в комплексе и без финансовых  затрат на ПО (при использовании свободных версий, конечно)  реализуется с помощью пары nxserver+nxclient. К тому же клиентская часть кросплатформенна, что во многом имеет определяющее значение.

В своей практике я использую решение от компании "Этерсофт", сейчас это два пакета - сам сервер nx-3.4.0, и их доделки-допилки - rx-etersoft. Выбрать сборку для своего дистрибутива (ссылки даны для Debian 5.0 Lenny) можно там же, поднявшись на пару уровней выше. Установка по сравнению с прошлым постом упростилась - нужно установить эти два пакета и выполнить команду rxsetup (и то и другое, конечно же, от имени суперпользователя). В директории, откуда rxsetup выполнялся, создастся файл rxsetup.log, заглянув в который, можно поглядеть подробности установки и справиться о наличии ошибок. 

Да, в некоторых дистрибутивах в базовой поставке отсутствует netcat и expect, которые используются в работе rx, поэтому их следует установить. Пару раз сталкивался, что отсутствовал пакет binutils, который также необходим для корректной настройки и работы rx-сервера. Таким образом, получатся такая последовательность команд:

delayer@inspire:~$ mkdir rxtemp

delayer@inspire:~$ cd rxtemp

delayer@inspire:~/rxtemp$ wget -c ftp://ftp.etersoft.ru/pub/Etersoft/RX%40Etersoft/1.1.1/Debian/5.0/nx_3.4.0-eter13.3debian_i386.deb

delayer@inspire:~/rxtemp$ wget -c ftp://ftp.etersoft.ru/pub/Etersoft/RX%40Etersoft/1.1.1/Debian/5.0/rx-etersoft_1.1.1-eter8debian_i386.deb

delayer@inspire:~$ su -

inspire:/home/delayer/rxtemp# aptitude update && aptitude install netcat expect binutils

inspire:/home/delayer/rxtemp# dpkg -i nx_3.4.0-eter13.3debian_i386.deb rx-etersoft_1.1.1-eter8debian_i386.deb

inspire:/home/delayer/rxtemp# rxsetup

inspire:/home/delayer/rxtemp# /etc/init.d/freenx-restart

Теперь можно ставить на клиентскую рабочую станцию клиента - или "ванильного" от NoMachine (win, lin), или сборку "community edition" (win), которую усиленно пилят резиденты unixforum-a во главе с dimbor'ом (за что и огромный респект, ибо попилено немеряно). Уточню, что хотя сборки NXClientCE можно взять не только в соотвествующих ветках самого unixforum'а, но и на ftp-сервере "Этерсофта" (там же, где и rx), сама компания к разработке этого продукта отношения не имеет. Это неочевидно, но тем не менее.

Практика использования rx показала, что нет надобности делать nxserver --adduser, все прекрасно и "из коробки" работает с существующими системными (или ldap) пользователями. Авторизация происходит аналогично обычному ssh-логину, с той лишь разницей, что сначала по ключу авторизуется специальный пользователь nx, а от его имени уже происходит дальнейшая авторизация заданного в настройках подключения пользователя. 

В качестве клиента я бы рекомендовал использовать сборку Community Edition, так в ней поправлены многие проблемы с раскладкими, кодировками, буфером обмена, работой в rootless-режиме и много чего еще. Всю биографию NXClientCE можно попытаться осилить - труд "Курощение.." находится тут.

Предложенная связка уже не первый год работает более чем в двух десятках различных организаций Кирова и области, "боевой" опыт использования имеет место быть. Как показывает статистика посещений моей странички, прошлый пост по этой теме практически с момента публикации держится в топе посещаемости относительно всех остальных заметок  Посему тема, выходит, достаточно востребована и популярна.

Basic VS Premium?

Возник вопрос - чем конкретно различаются Win 7 Home Basic и Home Premium. Беглый поиск выдал хорошую ссылку по сабжу, где различия в функционале всей линейки Win 7 представлены в табличной форме.
Опечалило, что даже в Home Premium нет XP Mode, которая меня пару раз спасала. В итоге получается, что единственным критичным (на мой взгляд) недостатком HB является отсутствие поддержки мультитача (многие тачпады его уже умеют), ну и Аэро, да, для эндюзера сие в подавляющем большинстве случаев важно. ;)

Настройка резервного интернет-канала

Задача: Есть некий сферический сервер в вакууме, который занимается раздачей интернетов. Интернетов имеется два: толстый и безлимитный - для хорошей и повседневной жизни, а также хилый и помегабайтный - для годины тяжелой. И хочется простого человеческого счастья - вечного интернета. А именно, пока все хорошо, жить на толстом канале, а если он упал, резво переключиться на хилый, не забыв следить за состоянием основного, дабы возвернуться на него по появлении линка.

Как ни странно, на просторах Сети мне так и не удалось найти простого и доступного решения такой, казалось бы, частой возникающей задачи. Нет, варианты решения присутствуют, например, вот тут есть неплохой скрипт на баше, замечательно комментированный. Можно использовать его, можно упростить или усложнить в зависимости от ситуации, с логикой у меня проблем не возникло, код понятный. В иных местах советуют договориться с провайдерами, прикупить AS у RIPE, затариться цисками, etc.

Однако можно обойтись и одной quagga'ой. Да, это мощнейший инструмент, поддерживающий большинство (если не все) протоколов маршрутизации (OSPF, RIP, RIPng, BGP-4), и использовать его в качестве исключительно монитора состояния аплинка и смены маршрута по умолчанию, возможно, неоптимально. Однако найти более простой инструмент для этого функционала мне не удалось, поэтому будем работать с ней. К тому же, в дальшейшем планируется развитие сети, и OSPF будет очень полезным.

Итак, я не буду углубляться в архитектуру и возможности Quagga, об этом можно почитать как на оффсайте, так и в материалах по ней в Сети. Скажу лишь, что буду использовать только демон zebra, который занимается непосредственно таблицами маршрутизации и умеет следить за состоянием сетевых интерфейсов. Собственно, требуется мониторить состояние (подключено/неактивно) двух интерфейсов (eth200 - "толстый инет", ppp200 - "хилый инет") и при неактивности первого переключаться на второй, а при возвращении линка - восстанавливать первоначальное состояние.

Всех дел - создать zebra.conf следующего содержания:

! -*- zebra -*-
!
! zebra sample configuration file
!
hostname zebra
password zebra
enable password ezebra
!
! Interface's description.
!
interface ppp200
description beeline gprs
link-detect
!
interface eth200
description multinex vlan
link-detect
!
ip route 0.0.0.0/0 23.45.67.89 1
ip route 0.0.0.0/0 ppp200 2
ip route 0.0.0.0/0 null0 255
!
log file /var/log/quagga/zebra.log

Поля hostname, password, enable password заполняются произвольно, смысл понятен из названий. Описания интерфейсов: interface - имя интерфейса, за которым следим, description - его описание (для себя), link-detect - включение слежения за состоянием соединения. Маршруты: описываем множественный маршрут по умолчанию, последняя цифра - метрика (меньше - важнее). Если живы оба интерфейса, прописывается маршрут с меньшим значением метрики.
Далее в /etc/quagga/zebra.conf включаем демон zebra:

zebra=yes

Теперь запускаем кваггу и подключаемся с ней telnet'ом:

/etc/init.d/quagga start
Loading capability module if not yet done.
Starting Quagga daemons (prio:10): zebra.
telnet localhost 2601

Если оба линка активны, то в список статических маршрутов выглядеть примерно так:

zebra> show ip route static
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       I - ISIS, B - BGP, > - selected route, * - FIB route

S   0.0.0.0/0 [255/0] is directly connected, Null0, bh
S   0.0.0.0/0 [2/0] is directly connected, ppp200
S>* 0.0.0.0/0 [1/0] via 23.45.67.89, eth200

Звездочка показывает, какой маршрут в данный момент используется. Если сейчас выдернуть провод из eth200, звездочка переместится на ppp200. При возвращении линка в eth200 маршрут снова переместится, так как метрика у eth200 выше. В момент запуска зебры этой звездочки может и не быть, если демону не приходилось выбирать маршрут.
P.S.: Данное решение также не лишено недостатков. Так как переключение маршрутов основано на состоянии линка, то при проблемах программного харакактера у провайдера (eth200) активный линк не дает гарантии наличия интернета. С ppp-интерфейсами тут проще, они при потере связи с концентратором падают. Все это стоит иметь в виду при построении своей сети.

MediaTomb и Samsung LNA+

Выяснилось, что при умолчальных настройках DLNA-сервер Mediatomb (в итоге именно на его пал выбор, ибо minidlna ни под каким соусом не кушал у меня .mkv, rygel безбожно тормозил и тоже фыркал на некоторые "матроски", а других я и не знаю)  и LNA+-клиент Samsung'a (LCD-телек пятой серии) знать друг друга не видят. Уж чья реализация протокола кривая, не так и важно. Главное, что лечится добавлением в /etc/mediatomb/config.xml:

<custom-http-headers>
   <add header="X-User-Agent: redsonic"/>
 </custom-http-headers>

Далее оказалось, что при проигрывании медиа-контента товарищ телек ведет себя как телек, а не как медиапроигрыватель, а именно - не дает нажать на паузу и перемотать. Правильнее сказать, не реагирует на нажатия соответствующих кнопок пульта. Это лечится таким образом (в том же config.xml):

<custom-http-headers><add header="X-User-Agent: redsonic"/>
 <add header="transferMode.dlna.org: Streaming"/>
 <add header="contentFeatures.dlna.org: DLNA.ORG_OP=01;DLNA.ORG_CI=0;DLNA.ORG_FLAGS=01500000000000000000000000000000"/>
</custom-http-headers>

В интернетах встречал строчку с "017...." - так вот с ней пауза-перемотка не работают. Признаться, в такой конфигурации тоже не все гладко: Пауза-Воспроизведение начинают работать, однако перемотка включается не спецклавишами, а центральным крестиком (влево-вправо соответственно), плюс пультовый "ентер" дублирует паузу. Но лучше так, чем никак. К тому же телек дает соответствующую функциональную подсказку, что нажать ;)

И еще один момент напоследок из того, что пока не выветрилось из головы в процессе знакомства с MediaTomb'ом - следующие строки добавляют в значки файлов филмов кадры из этих фильмов.

<ffmpegthumbnailer enabled="yes">
     <thumbnail-size>128</thumbnail-size>
     <seek-percentage>5</seek-percentage>
     <filmstrip-overlay>yes</filmstrip-overlay>
     <workaround-bugs>no</workaround-bugs>
 </ffmpegthumbnailer>

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

З.Ы.: xml-код вставлен с помощью сервиса QuickEscape.

openfire LSB-init

Недавно зарелизившийся openfire-3.7.0 (да и более старые версии) при установке в среде Debian Lenny/Squeeze складывает в /etc/init.d скрипт запуска "старого образца", который не проходит проверку LSB, о чем ОС неустанно повторяет.

update-rc.d: warning: /etc/init.d/openfire missing LSB information

И если в Lenny на это можно не обращать внимания, то в Squeeze уже подобное несоответствие может вызвать проблему совместимости с dependency based boot, используемой в этом релизе по умолчанию. Полечить можно вручную, почитав, к примеру, тут. Однако, как обычно бывает в мире FOSS, "все уже украдено до нас": имеется патч, LSB-ирующий умолчальный init-script.