Различия между версиями 8 и 9
Версия 8 от 2018-01-11 21:59:54
Размер: 13922
Редактор: ArsenyMaslennikov
Комментарий:
Версия 9 от 2018-09-13 12:30:10
Размер: 13885
Редактор: ArsenyMaslennikov
Комментарий:
Удаления помечены так. Добавления помечены так.
Строка 38: Строка 38:
   ''Сейчас в сизифе актуальный mumble, все проблемы ниже исправлены.'' -- ArsenyMaslennikov <<DateTime(2018-09-13T12:27:54Z)>>
Строка 39: Строка 40:
   ''Вчера в альт был собран исправленный src-пакет с клиентом и сервером, пока в карман.'' -- ArsenyMaslennikov <<DateTime(2018-01-11T18:59:54Z)>>

Как мы проводим дистанционные семинары

Чем пользуемся

Видео: конкретно нам не нужно видеть говорящие головы.

Звук: выбрали Mumble, потому что:

  • он свободный и притом кросс-платформенный (и мобильные клиенты тоже есть),
  • его довольно легко настроить на клиентах (но лучше делать это заранее)
  • предоставляет высокое качество звука
  • достаточно неприхотлив к качеству сети
  • шифрует связь через SSL (мелочь, а приятно).

Демо: нужно что-то показывать. Подошёл VNC:

  • никаких ограничений на использование
  • также кроссплатформен
  • клиенты просто получают данные, куда стучаться, и присоединяются
  • у каждого клиента есть возможность рулить демонстрацией, если он этого хочет.

Необходимые действия для организации семинара

Звук

  1. Поднимаем сервер для Mumble, также известный как murmur (как это делается, рассмотрим на примере ALT).

    1. Для этого установим murmur:

        apt-get install murmur
      Чтобы запустить сервер, достаточно сказать:
        service murmur start

      Чтобы murmur запускался при каждой загрузке сервера, нужно попросить об этом init-систему вашего сервера.

      • Если у вас systemd (скорее всего), скажите от суперпользователя: systemctl enable murmur

      • Если у вас sysvinit, то команда другая: chkconfig murmur on

    2. В Mumble есть средства авторизации и тонкого контроля доступа к серверу как для пользователей, так и для администраторов, но они (не будучи слишком удобными в использовании) пригодны в полной мере для публичных серверов, а у нас — приватный. Мы не выставляем порт 64738 (порт Mumble-сервера по умолчанию) наружу, а на каждом клиенте пробрасываем этот порт на локальный через SSH:
        client$ ssh -N mumble-server -L 8000:localhost:64738
    3. В примере выше, пока команда выполняется, соединения на localhost:8000 приведут к соединению с mumble-server:64738 (запись localhost:64738 обрабатывается на mumble-server, на который заходим по ssh).

    4. Вместо 8000 можно использовать любой свободный порт на вашей машине (можно и 64738, тогда Mumble-клиент подставит его автоматически)

    5. На этапе подключения клиента к серверу адрес сервера будет localhost, а порт — выбранный вами (в примере 8000)

  2. Каждый участник обзаводится mumble-клиентом (в ALT — пакет mumble), если ещё не, и проходит первоначальную настройку, следуя инструкциям на экране (если использовать русскую локаль, инструкции будут тоже на русском).

    • Очень важно настроить порог SNR (Signal-Noise Ratio) активации передачи голоса правильно, чтобы не зашумлять эфир и не заглушать собеседников.
    • Если в одной комнате сидит много участников, то, скорее всего, каждого будет слышно и через чужие микрофоны; в такой ситуации имеет смысл оставить включённым лишь один.
  3. При запуске клиента появится предложение выбрать сервер. Мы используем свой (вне ВМК), поднятый ранее и не указанный в списке; чтобы к нему подсоединиться, жмём "Добавить новый", вводим:
    • адрес сервера (если делали ssh -L, то адрес — localhost),

    • пароль (общий на всех),
    • свой никнейм (как хотим подписаться)
  4. Звуковая связь настроена. Активацию передачи по голосу можно заменить на активацию по кнопке или на постоянно включенный микрофон, если удобно.

Демонстрация виртуализованного окружения

  1. В качестве демонстрационного стенда выступает Blade14, на который нет прямого доступа из-за пределов факультета. Это можно исправить, временно пробросив порт, например, средствами ssh. Для этого на blade14 выполним:

     blade14$ ssh -N user@visible_host -R 9940:localhost:5940

    с точностью до номеров портов (берём либо необходимые, либо удобные/свободные) и пары пользователь@адрес-сервера.

    Пока команда выше продолжает выполнение, соединения откуда угодно к visible_host:9940 приведут именно на blade14:5940 (имя localhost воспринимается относительно локальной машины; в примере — blade14)

  2. Нужно настроить VNC-сервер. Он уже встроен в qemu-kvm, в VirtualBox (далее на его примере).

    1. Для нашего случая с VirtualBox: если на сервере стоит VirtualBox Extension Pack, то из GUI управление vnc-сервером недоступно, и придётся, предварительно заставив VB забыть о виртуалке, вставить в её конфигурацию следующие строчки (на место XML-элемента <RemoteDisplay />):

        <RemoteDisplay allowMultiConnection="true">
            <VRDEProperties>
                <Property name="TCP/Ports" value="5940"/>
            </VRDEProperties>
        </RemoteDisplay>
    2. Добавить виртуалку обратно.
    3. Поднимаем виртуалку на стенде, если этого уже не сделали.
    4. Соединяемся при помощи VNC-клиента, скажем, tigervnc; пароль (в нашем случае) пустой.

      • Пример с участием tigervnc под Linux:

           vncviewer -shared visible_host:9940
        где последним аргументом указываются адрес внешнего сервера и порт.
      • Можно передать клиенту -viewonly, тогда нажатия клавиш и мышиные действия по экрану демонстрации не будут мешать демонстрирующему (-щим)

Meetings/762/RemoteDemoMeeting (последним исправлял пользователь ArsenyMaslennikov 2018-09-13 12:30:10)