Как мы проводим дистанционные семинары
Чем пользуемся
Видео: конкретно нам не нужно видеть говорящие головы.
Звук: выбрали Mumble, потому что:
- он свободный и притом кросс-платформенный (и мобильные клиенты тоже есть),
- его довольно легко настроить на клиентах (но лучше делать это заранее)
- предоставляет высокое качество звука
- достаточно неприхотлив к качеству сети
- шифрует связь через SSL (мелочь, а приятно).
Демо: нужно что-то показывать. Подошёл VNC:
- никаких ограничений на использование
- также кроссплатформен
- клиенты просто получают данные, куда стучаться, и присоединяются
- у каждого клиента есть возможность рулить демонстрацией, если он этого хочет.
Необходимые действия для организации семинара
Звук
Поднимаем сервер для Mumble, также известный как murmur (как это делается, рассмотрим на примере ALT).
Для этого установим murmur:
apt-get install murmur
Чтобы запустить сервер, достаточно сказать:service murmur start
Чтобы murmur запускался при каждой загрузке сервера, нужно попросить об этом init-систему вашего сервера.
Если у вас systemd (скорее всего), скажите от суперпользователя: systemctl enable murmur
Если у вас sysvinit, то команда другая: chkconfig murmur on
- В Mumble есть средства авторизации и тонкого контроля доступа к серверу как для пользователей, так и для администраторов, но они (не будучи слишком удобными в использовании) пригодны в полной мере для публичных серверов, а у нас — приватный. Мы не выставляем порт 64738 (порт Mumble-сервера по умолчанию) наружу, а на каждом клиенте пробрасываем этот порт на локальный через SSH:
client$ ssh -N mumble-server -L 8000:localhost:64738
В примере выше, пока команда выполняется, соединения на localhost:8000 приведут к соединению с mumble-server:64738 (запись localhost:64738 обрабатывается на mumble-server, на который заходим по ssh).
Вместо 8000 можно использовать любой свободный порт на вашей машине (можно и 64738, тогда Mumble-клиент подставит его автоматически)
На этапе подключения клиента к серверу адрес сервера будет localhost, а порт — выбранный вами (в примере 8000)
Каждый участник обзаводится mumble-клиентом (в ALT — пакет mumble), если ещё не, и проходит первоначальную настройку, следуя инструкциям на экране (если использовать русскую локаль, инструкции будут тоже на русском).
- Очень важно настроить порог SNR (Signal-Noise Ratio) активации передачи голоса правильно, чтобы не зашумлять эфир и не заглушать собеседников.
- Если в одной комнате сидит много участников, то, скорее всего, каждого будет слышно и через чужие микрофоны; в такой ситуации имеет смысл оставить включённым лишь один.
- При запуске клиента появится предложение выбрать сервер. Мы используем свой (вне ВМК), поднятый ранее и не указанный в списке; чтобы к нему подсоединиться, жмём "Добавить новый", вводим:
адрес сервера (если делали ssh -L, то адрес — localhost),
- пароль (общий на всех),
- свой никнейм (как хотим подписаться)
- Звуковая связь настроена. Активацию передачи по голосу можно заменить на активацию по кнопке или на постоянно включенный микрофон, если удобно.
Демонстрация виртуализованного окружения
В качестве демонстрационного стенда выступает Blade14, на который нет прямого доступа из-за пределов факультета. Это можно исправить, временно пробросив порт, например, средствами ssh. Для этого на blade14 выполним:
blade14$ ssh -N user@visible_host -R 9940:localhost:5940
с точностью до номеров портов (берём либо необходимые, либо удобные/свободные) и пары пользователь@адрес-сервера.
Пока команда выше продолжает выполнение, соединения откуда угодно к visible_host:9940 приведут именно на blade14:5940 (имя localhost воспринимается относительно локальной машины; в примере — blade14)
Нужно настроить VNC-сервер. Он уже встроен в qemu-kvm, в VirtualBox (далее на его примере).
Для нашего случая с VirtualBox: если на сервере стоит VirtualBox Extension Pack, то из GUI управление vnc-сервером недоступно, и придётся, предварительно заставив VB забыть о виртуалке, вставить в её конфигурацию следующие строчки (на место XML-элемента <RemoteDisplay />):
<RemoteDisplay allowMultiConnection="true"> <VRDEProperties> <Property name="TCP/Ports" value="5940"/> </VRDEProperties> </RemoteDisplay>- Добавить виртуалку обратно.
- Поднимаем виртуалку на стенде, если этого уже не сделали.
Соединяемся при помощи VNC-клиента, скажем, tigervnc; пароль (в нашем случае) пустой.
Пример с участием tigervnc под Linux:
vncviewer -shared visible_host:9940
где последним аргументом указываются адрес внешнего сервера и порт.Можно передать клиенту -viewonly, тогда нажатия клавиш и мышиные действия по экрану демонстрации не будут мешать демонстрирующему (-щим)
Подводные камни Сейчас в сизифе актуальный mumble, все проблемы ниже исправлены. -- ArsenyMaslennikov 2018-09-13 15:27:54 Отмечу, что на момент написания этих строк пакет murmur в Альте довольно плох.
С мурмуром не связано, но по теме: клиент mumble разбит на несколько бинарных пакетов с абсолютно одинаковым описанием (description): среди них mumble-plugins, mumble-protocol, например. Без определённых навыков и понимания устройства Mumble нельзя понять, нужен ли пакет в данной конкретной ситуации или нет.
Все эти недостатки вполне исправимы, но для исправления требуют вмешательства мейнтейнера.Лог по умолчанию вопреки FHS кладётся в /etc/murmur/murmur.log прямо рядом с конфигурационным файлом. (уместнее, например, /var/log/murmur.log или, как в Debian, /var/log/mumble-server/mumble-server.log). Не буду здесь описывать, почему это дурная практика, во избежание захламления страницы.
Сервер поддерживает автоматический сброс привилегий, но по умолчанию этого не делает (поле uname= конфига пусто); однако, init-скрипт наивно полагает, что сервис будет работать из-под пользователя _mumble, и пакет при установке его добавляет.
(Возможно, связано с предыдущим) service murmur status практически сразу после запуска сервиса клянётся, что он остановлен, хотя в дереве процессов murmurd виден. Попытки стартовать сервис заново просто добавят другой серверный процесс.
Для личных нужд murmur использует базу данных (по умолчанию sqlite, но есть возможность использовать и другие СУБД. Разработчики утверждают, что работа с другими СУБД хуже оттестирована). Из коробки путь. куда она ложится, не прописан вообще, и сервер отказывается продолжать работу. У пользователя _mumble домашняя директория проставлена в /var/lib/mumble-server; наверное, имеет смысл по умолчанию класть sqlite-базу данных туда (так делают в Debian). На вики апстрима предлагают класть её в /var/run/murmur.sqlite, но murmur с привилегиями пользователя _mumble не может писать напрямую в /var/run. Решать можно по разному; главное — следуя принятым правилам в ALT и здравому смыслу, предоставить конфигурацию по умолчанию, позволяющую серверу работать.
Чтобы работать с sqlite-БД, murmur использует libqt4-sql-sqlite. На неё проставлена зависимость в пакете с клиентом, но не проставлена в пакете murmur, хоть они и собираются из одного .src.rpm. Установка libqt4-sql-sqlite руками решила проблему. В апстрим-документации эта зависимость не описана.
Some nitpicking:
Description: Mumble voice chat server Murmur (also called mumble-server) is part of VoIP suite Mumble primarily intended for gamers. Murmur is server part of suite.MGIMO finished, didn't we?Here's a proposed rewrite:
Description: A low-latency encrypted VoIP server Murmur (also known as mumble-server) is the server component of the Mumble low-delay VoIP suite intended primarily for gaming. (*** here goes some general info about Mumble. It is customary in Debian, for example, to put _this_ info in the beginning and clarify the package role later. ***) It features noise suppression, encrypted connections for both voice and instant messaging, automatic gain control and low latency audio with support for multiple audio standards. Mumble includes an in-game overlay compatible with most open-source and commercial 3D applications.