Я рассказывал в своих заметках о установке, настройке, масштабировании и о джобах в Jenkins-е. В голову пришло еще то, что нужно еще и иметь бэкапы для того, чтобы можно было откатится назад. Я нагуглил пару решений. Но еще не решил какое лучше. По этому, расскажу о них.

Полезное чтиво:

Установка Jenkins в Unix/Linux

Работа с Jenkins-CLI в Unix/Linux

Установка Jenkins и Jenkins-slave в Unix/Linux

Настройка языка в Jenkins

Создание Jenkins backup/restore в Unix/Linux

И так, нам понадобится установить плагин(ы) (можно и один на выбор, я использовал несколько для сравнения):

• Thin backup
• Backup Plugin
• Periodic Backup
• SCM Sync configuration

Можно заюзать и другие решения:

• Использовать Git и взять «$JENKINS_HOME» под него.
• Написать BASH скрипт и создать джобу на ее выполнение.

Перейдем к решениям!

Использование Thin backup плагина для backup/restore Jenkins-а в Unix/Linux

Переходим «Manage Jenkins» -> «Manage Plugins» и устанавливаем «Thin backup». Я обычно всегда перезапускаю дженкинс для того, чтобы применились все настройки и все работало.

PS: Для перезагрузки дженкинс-сервера, я использую «Restart Safely» плагин.

Настройки бекапа, переходим в «Manage Jenkins» -> «ThinBackup»:

В данном плагине имеются:

• Backup Now — Кнопка чтобы сделать бекап сейчас.
• Restore — Служит для рестора данных.
• Settings — Настройка для бэкапа.

Начнем с настройки, нажимаем по нему:

Я отметил нужные мне поля и нажал на кнопку «Save». Т. е у меня будут выполнятся бэкапы по заданному расписанию и складыватся в «/backups» папку. Теперь можно запустить «Backup now» чтобы выполнился бэкап.

Вот и все. Можно юзать данный плагин для бэкаа и рестора.

Использование Backup Plugin плагина для backup/restore Jenkins-а в Unix/Linux

Переходим «Manage Jenkins» -> «Manage Plugins» и устанавливаем «Backup plugin». Я обычно всегда перезапускаю дженкинс для того, чтобы применились все настройки и все работало.

Настройки бекапа, переходим в «Manage Jenkins» -> «Backup manager»:

В данном плагине имеются:

• Setup — Служит для настройки бэкапов.
• Backup Hudson configuration — Чтобы создать бэкап.
• Restore Hudson configuration — Для рестора бэкапа.

Я привел настройку к такому виду:

После настроек нажимаем на «Save». Нажимаем на «Backup Hudson configuration» для создания бэкапа.

Использование Periodic Backup плагина для backup/restore Jenkins-а в Unix/Linux

Переходим «Manage Jenkins» -> «Manage Plugins» и устанавливаем «Periodic Backup». Я обычно всегда перезапускаю дженкинс для того, чтобы применились все настройки и все работало.

Настройки бекапа, переходим в «Manage Jenkins» -> «Periodic Backup Manager»:

Плагин не сконфигурирован и его нужно отконфигурить. Что я и сделаю сейчас, нажимаем на «Configure»:

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

Использование SCM Sync configuration плагина для backup/restore Jenkins-а в Unix/Linux

Переходим «Manage Jenkins» -> «Manage Plugins» и устанавливаем «SCM Sync configuration». Я обычно всегда перезапускаю дженкинс для того, чтобы применились все настройки и все работало.

Создам проект в гитлабе, например «configurations/jenkins».В данной проекте я буду хранить все настройки.

Переходим в «Manage Jenkins» -> «Configure System» и находим поле «SCM» и заполняем поля. У меня не получилось подружится с этим плагином вообще. Снес его!

Использование bash-скрипта для backup/restore Jenkins-а в Unix/Linux

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

Переходим «Manage Jenkins» -> «Manage Plugins» и устанавливаем «Exclusive Execution». Я обычно всегда перезапускаю дженкинс для того, чтобы применились все настройки и все работало. Создам структуру: Projects->Configurations. Т.е папка Projects в ней будут проекты, в данном случае «Configurations» — конфиги (Для создания папки, нажмите «New item» и выбирете «folder»).

Переходим в проект и нажимаем на «New item» и кликаем по «Freestyle project». Вводим имя для проекта, у меня — «jenkins-backup» и нажимаем на «OK»:

Потом переходим в созданный проект и нажимаем на «Configure» и находим поле «Source Code Management» и прописываем УРЛ где будет лежать скрипт для бэкапа у меня это готовое решение какого-то чела, например:

Идем дальше и переходим во «Build Triggers» вкладку и заполним:

Т.е заполним переодичность с которой будет запускаться скрипт.sh1 lines

H 3 * * *

После этого переходим во «Build» вкладку и затем, из списка выбираем «Execute shell». и прописываем параметры для запуска:

Добавляем в поле следующий текст:sh1 lines

./jenkins-backup.sh $JENKINS_HOME /backups/backup_`date +"%Y_%m_%d_%H:%M:%S"`.tar.gz

И на этом все, нажимаем на «Save». После этого, будет выполнятся бекап по заданному времени. Если есть необходимость, то можно запустить джобу маннуалли (Нажав на «Build Now»).

PS: Можно сделать бэкап-ротейт чтобы все старые бэкапы удалялись автоматом, например, можно добавить еще один «Execute shell» команду:sh1 lines

find /backups/backup_* -mtime +7 -delete

Т.е бэкапы будут хранится 7 дней, остальные будут удалены.

Вот еще один пример скрипта, который можно использовать:sh42 lines

#!/bin/bash

# Setup
#
# - Create a new Jenkins Job
# - Mark "None" for Source Control Management
# - Select the "Build Periodically" build trigger
#   - configure to run as frequently as you like
# - Add a new "Execute Shell" build step
#   - Paste the contents of this file as the command
# - Save
#  
# NOTE: before this job will work, you'll need to manually navigate to the $JENKINS_HOME directory 
# and do the initial set up of the git repository.  
# Make sure the appropriate remote is added and the default remote/branch set up.
#  

# Jenkins Configuraitons Directory
cd $JENKINS_HOME

# Add general configurations, job configurations, and user content
git add -- *.xml jobs/*/*.xml userContent/*

# only add user configurations if they exist
if [ -d users ]; then
    user_configs=`ls users/*/config.xml`

    if [ -n "$user_configs" ]; then
        git add $user_configs
    fi
fi

# mark as deleted anything that's been, well, deleted
to_remove=`git status | grep "deleted" | awk '{print $3}'`

if [ -n "$to_remove" ]; then
    git rm --ignore-unmatch $to_remove
fi

git commit -m "Automated Jenkins commit"

git push -q -u origin master

Как по мне, все тут логично и понятно что он делаеет… Аналогичным способом можно сделать джобу и запускать переодически. Тем самым, все конфиг-файлы, будут попадать в гит.

Вывод: Я протестировал несколько плагинов и выбрал — использовать скрипты или Thin backup, Periodic Backup плагины. Но если есть другие решения, — пишите, дополню материал.

Я для клиента писал вот такой скрипт:sh38 lines

#!/usr/bin/env bash


# JENKINS_HOME
#  +- config.xml     (jenkins root configuration)
#  +- *.xml          (other site-wide configuration files)
#  +- userContent    (files in this directory will be served under your http://server/userContent/)
#  +- fingerprints   (stores fingerprint records)
#  +- nodes          (slave configurations)
#  +- plugins        (stores plugins)
#  +- secrets        (secretes needed when migrating credentials to other servers)
#  +- workspace (working directory for the version control system)
#      +- [JOBNAME] (sub directory for each job)
#  +- jobs
#      +- [JOBNAME]      (sub directory for each job)
#          +- config.xml     (job configuration file)
#          +- latest         (symbolic link to the last successful build)
#          +- builds
#              +- [BUILD_ID]     (for each build)
#                  +- build.xml      (build result summary)
#                  +- log            (log file)
#                  +- changelog.xml  (change log)

echo "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~";
echo "==================== Jenkins backup ====================";
echo "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~";

JENKINS_DIR="/mnt/data/jenkins"
JENKINS_BACKUP_DIR="/mnt/data/jenkins_backup"

cp -r ${JENKINS_DIR}/*.xml ${JENKINS_BACKUP_DIR}
cp -r ${JENKINS_DIR}/userContent ${JENKINS_BACKUP_DIR}
cp -r ${JENKINS_DIR}/fingerprints ${JENKINS_BACKUP_DIR}
cp -r ${JENKINS_DIR}/nodes ${JENKINS_BACKUP_DIR}
cp -r ${JENKINS_DIR}/plugins ${JENKINS_BACKUP_DIR}
cp -r ${JENKINS_DIR}/secrets ${JENKINS_BACKUP_DIR}
cp -r ${JENKINS_DIR}/workspace ${JENKINS_BACKUP_DIR}
cp -r ${JENKINS_DIR}/jobs ${JENKINS_BACKUP_DIR}

Проверялось, — работает!

Резервное копирование для Jenkins

Все, кто занимается задачами CI/CD, так или иначе знают про Jenkins, даже если им посчастливилось не иметь с ним дела.

Этот непотопляемый кадавр продолжает жить и процветать по следующим причинам:

• гибкость настроек (от настраиваемых диалоговых окон до встроенного Groovy);
• архитектура с поддержкой плагинов и обширный набор готовых плагинов на все случаи жизни;
• и самое главное — большой накопленный объём пользовательских проектов, которые проще продолжать развивать и поддерживать в среде Дженкинса, чем пытаться мигрировать на более современные и приятные платформы.

Очевидно, что чем важнее данные внутри Дженкинса для тех, кто им пользуется, тем актуальнее для них резервное копирование этих данных.

Однако здесь возникают два небольших препятствия:

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

Поэтому, взяв за основу один из таких костылей, мы написали свой собственный.

Список предварительных пожеланий к нему был примерно таким:

• резервная копия должна иметь минимальный размер и максимальную скорость создания (например, дамп виртуальной машины или снимок ZFS с сотнями гигабайт проектов не годится);
• после восстановления нам достаточно иметь полностью настроенный сервер без предыдущего состояния — который знает, как выполнять новые job’ы, но ничего не помнящий про старые;
• поскольку настройки имеют текстовый вид, пусть они сохраняются в Git-репозиторий;
• если Jenkins предназначен для автоматического выполнения заданий, пусть самостоятельно выполняет всю работу по своему обслуживанию.

Общая схема:

• в $JENKINS_HOME создаётся Git-репозиторий;
• на Git-сервере для него создаётся origin (далее приводятся настройки для Gitlab);
• в Дженкинсе создаётся периодическое задание, которое сохраняет в Git ключевые файлы;
• для уменьшения размера от плагинов сохраняются только манифесты, при восстановлении плагины скачиваются заново.

Сначала создайте пользователя и репозиторий в Gitlab’e:

• пользователь = jenkins-backup-robot;
• репозиторий = jenkins-configs;
• URL репозитория скопируйте в буфер обмена;
• откройте Repository => Settings => Members;
• назначьте jenkins-backup-robot мантейнером (иначе Gitlab не даст сделать ему первый push в пустой репозиторий).

Теперь идите в командную строку сервера, на котором работает Jenkins:

• нам требуется создать SSH-ключ и Git-репозиторий:

sudo -Hiu jenkins

cd ~

git init

git config --global user.name Jenkins

git config --global user.email "jenkins@$(hostname -f)"

git remote add origin ВСТАВЬТЕ_ЗДЕСЬ_URL_GIT_РЕПОЗИТОРИЯ

test -s ~/.ssh/id_rsa.pub || ssh-keygen

cat ~/.ssh/id_rsa.pub

Созданный SSH-ключ надо импортировать в Gitlab:

• Это делается в разделе Admin => Users => jenkins-backup-robot => Impersonate => Personal Settings => SSH keys.

Создайте в Дженкинсе новое задание:

• Name: Backup Jenkins configs to Git
• Type: Free job
• Label: master
• SCM: None
• Build: Build Periodically
• Schedule: 20 04 * * *
• Build step: Execute Shell
• Command:

#!/bin/sh -e



cd "$JENKINS_HOME"



# Add general configurations, secrets, job configurations, nodes, user content, users and plugins info:

ls -1d *.xml secrets/ jobs/*/*.xml nodes/*/*.xml userContent/* users/*/config.xml 

    plugins/*/META-INF/MANIFEST.MF 2>/dev/null | grep -v '^queue.xml$' | xargs -r -d 'n' git add --



# Track deleted files:

LANG=C git status | awk '$1 == "deleted:" { print $2; }' | xargs -r git rm --ignore-unmatch



LANG=C git status | grep -q '^nothing to commit' || {

    git commit -m "Automated Jenkins commit at $(date '+%Y-%m-%d %H:%M')"

    git push -q -u origin master

}

• SAVE

Пояснения:

• Метка “master” нужна, если у Дженкинса есть slave-узлы. Если их нет, метку в задании можете не указывать. Если они есть, то в списке узлов отредактируйте свойства мастера и в поле “Labels” добавьте “master”. Если вы этого не сделаете, Дженкинс попытается выполнять задание через агентов на всех узлах, а это явно не то, что нам требуется.
• Если для подключения к Git-серверу используется SSH, перед выполнением задания не забудьте подключиться к нему вручную, чтобы git push не завершался с ошибкой из-за StrictHostKeyChecking.

Заключительный шаг в Gitlab’e после успешного git push:

• в свойствах репозитория откройте раздел Members и понизьте уровень доступа для Дженкинса с Maintainer до Developer;
• в Settings => Repository => Protected branches поменяйте для ветки “master” разрешение “Allow to push” с Maintainers на Maintainers+Developers.

Восстановление плагинов:

• Т.к. мы сохраняем только манифесты плагинов, после восстановления из резервной копии нам потребуется просканировать каталог с манифестами и составить список команд для загрузки дистрибутивов:

sudo -Hiu jenkins

cd ~/plugins/

gawk 'BEGIN     { RS = "rn" }

      BEGINFILE { n = v = "" }

      ENDFILE   { printf "curl -sS -L -O http://updates.jenkins-ci.org/download/plugins/%s/%s/%s.hpin", n, v, n }

      $1 == "Short-Name:"     { n = $2 }

      $1 == "Plugin-Version:" { v = $2 }

    ' ./*/META-INF/MANIFEST.MF > ./download_all_plugins.sh

• Обратите внимание, что вместо awk используется gawk (GNU awk), т.к. классический awk не понимает BEGINFILE и ENDFILE. В некоторых дистрибутивах gawk устанавливается по умолчанию, в некоторых его потребуется установить вручную.
• Если gawk отработает без ошибок, запустите сгенерированный им файл:

sudo -Hiu jenkins

cd ~/plugins/

gawk 'BEGIN     { RS = "rn" }

      BEGINFILE { n = v = "" }

      ENDFILE   { printf "curl -sS -L -O http://updates.jenkins-ci.org/download/plugins/%s/%s/%s.hpin", n, v, n }

      $1 == "Short-Name:"     { n = $2 }

      $1 == "Plugin-Version:" { v = $2 }

    ' ./*/META-INF/MANIFEST.MF > ./download_all_plugins.sh

• Самостоятельно распаковывать и устанавливать скачанные hpi-файлы не требуется — перезапустите Дженкинс и он сделает это сам.

Источники: https://linux-notes.org/sozdanie-jenkins-backup-restore-v-unix-linux/ и https://cdnnow.ru/blog/jenkins-backup/

Jitsi Meet — это бесплатное программное обеспечение для видеоконференций с открытым исходным кодом на базе WebRTC, которое работает на Linux, macOS, Windows, iOS и Android. Если вы не доверяете Zoom, вы можете запустить собственную платформу для видеоконференций на собственном сервере. Преимущество Jitsi Meet заключается в том, что все ваши данные передаются только через ваш сервер, а шифрование TLS обеспечивает защиту от перехвата и прослушивания. Это руководство покажет вам, как установить Jitsi Meet на сервер Ubuntu 18.04 и 20.04, а также Debian 10.

ОСОБЕННОСТИ JITSI MEET

• Совершенно бесплатно
• Поделитесь экраном своего компьютера с другими (Screensharing)
• Режим докладчика, который позволяет одновременно использовать экран и камеру
• Вы можете поделиться системным звуком во время демонстрации экрана
• Вы можете назначить авторизованных пользователей модераторами. Модератор может отключить звук у каждого участника одним щелчком мыши
• Связь по сети зашифрована с использованием DTLS-SRTP
• Сквозное шифрование
• Вы можете установить пароль для своей конференции, чтобы предотвратить вход случайных незнакомцев
• Запишите конференцию и сохраните ее в Dropbox
• Транслируйте на YouTube Live и сохраняйте запись на YouTube
• Приложения для Android и iOS
• Текстовый чат
• Вы можете поделиться текстовым документом
• Телефонный доступ к конференции
• Исходящий вызов телефонному абоненту
• Вы можете встроить вызов Jits Meet на любую веб-страницу с помощью всего нескольких строк кода

СИСТЕМНЫЕ ТРЕБОВАНИЯ

Вам понадобится:

• Linux сервер и non-root user с привилегиями sudo
• Доменное имя, указывающее на ваш сервер

ШАГ 1. УСТАНОВИТЕ JITSI MEET ИЗ ОФИЦИАЛЬНОГО РЕПОЗИТОРИЯ ПАКЕТОВ

Jitsi Meet не включен в репозиторий Ubuntu по умолчанию. Мы можем установить его из официального репозитория пакетов Jitsi, который также содержит несколько других полезных программных пакетов. Войдите на свой сервер через SSH, затем выполните следующую команду, чтобы добавить официальный репозиторий Jitsi.

echo 'deb https://download.jitsi.org stable/' | sudo tee /etc/apt/sources.list.d/jitsi-stable.list

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

wget -qO -  https://download.jitsi.org/jitsi-key.gpg.key | sudo apt-key add -

Поскольку для репозитория Jitsi требуется HTTPS-соединение, нам нужно установить пакет apt-transport-https, чтобы APT установил HTTPS-соединение с репозиторием Jitsi.

sudo apt install apt-transport-https

Затем обновите локальный индекс пакета и установите Jitsi Meet в Ubuntu.

sudo apt update

sudo apt install jitsi-meet

Во время установки вам необходимо ввести имя хоста для вашего экземпляра Jitsi. Это имя хоста, которое будет отображаться в адресной строке веб-браузера, когда посетители присоединятся к вашей видеоконференции. Вы можете использовать описательное имя хоста, например meet.example.com.

На следующем экране вы можете выбрать создание нового самозаверяющего сертификата TLS (Generate a new self-signed certificate), чтобы позже вы могли получить и установить доверенный сертификат Let’s Encryption.

В процессе установки будут настроены некоторые параметры ядра Linux, которые сохраняются в файле /etc/sysctl.d/20-jvb-udp-buffers.conf. После завершения установки Jitsi Meet автоматически запустится. Вы можете проверить его статус с помощью:

systemctl status jitsi-videobridge2

Пример вывода:

? jitsi-videobridge2.service - Jitsi Videobridge

   Loaded: loaded (/lib/systemd/system/jitsi-videobridge2.service; enabled; vendor preset: enabled)

   Active: active (running) since Fri 2020-04-24 12:11:13 UTC; 3min 27s ago

 Main PID: 3665 (java)

    Tasks: 37 (limit: 65000)

   CGroup: /system.slice/jitsi-videobridge2.service

           L-3665 java -Xmx3072m -XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp Dnet.java.sip.communicator.SC_HOME_DIR_LOCATION=/etc/jitsi -Dnet.java.sip.communicator.SC_HO	

Пакет jitsi-meet также извлекал другие пакеты в качестве зависимостей, например

• openjdk-8-jre-headless: среда выполнения Java. Это необходимо, потому что Jitsi Meet написан на языке Java.
• jicofo: Jitsi Conference Focus (systemctl status jicofo)
• prosody: Легкий сервер Jabber / XMPP (systemctl status prosody)
• coturn: сервер TURN и STUN для VoIP (systemctl status coturn)

ШАГ 2. ОТКРОЙТЕ ПОРТЫ В БРАНДМАУЭРЕ

Jitsi Meet прослушивает несколько портов UDP, что можно увидеть с помощью следующей команды. (Если на вашем сервере Ubuntu нет команды netstat, вы можете запустить команду sudo apt install net-tools, чтобы установить ее.)

sudo netstat -lnptu | grep java

Чтобы участники могли присоединиться к видеоконференции из веб-браузера, вам необходимо открыть TCP-порт 80 и 443. А для передачи видео по сети откройте UDP-порт 10000 и 5000. Если вы используете брандмауэр UFW, запустите следующую команду, чтобы открыть эти порты.

sudo ufw allow 80,443/tcp

sudo ufw allow 10000,5000/udp

ШАГ 3. ПОЛУЧИТЕ ДОВЕРЕННЫЙ СЕРТИФИКАТ LET’S ENCRYPT TLS

Перейдите в службу хостинга DNS (обычно это ваш регистратор домена), чтобы создать запись DNS A для вашего имени хоста Jitsi (meet.example.com). Затем запустите следующий скрипт, чтобы получить доверенный сертификат Let’s Encrypt TLS:

sudo /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh

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

This script will:

- Need a working DNS record pointing to this machine(for domain jitsi.example.com)

- Download certbot-auto from https://dl.eff.org to /usr/local/sbin

- Install additional dependencies in order to request Let’s Encrypt certificate

- If running with jetty serving web content, will stop Jitsi Videobridge

- Configure and reload nginx or apache2, whichever is used

- Configure the coturn server to use Let's Encrypt certificate and add required deploy hooks

- Add command in weekly cron job to renew certificates regularly



You need to agree to the ACME server's Subscriber Agreement (https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf)

by providing an email address for important account notifications

Enter your email and press [ENTER]:

Если все в порядке, вы увидите следующее сообщение, указывающее, что сертификаты TLS были успешно получены и установлены.

Обратите внимание, что этот сценарий использует запрос http-01, что означает, что ваш веб-сервер Apache или Nginx должен прослушивать порт 80 общедоступного IP-адреса. Если ваша серверная среда не поддерживает вызов http-01, вам не следует запускать приведенный выше сценарий. Вам нужно использовать другие типы задач. В этом случае используем вызов DNS.

sudo certbot --agree-tos -a dns-cloudflare -i nginx --redirect --hsts --staple-ocsp --email me@example.com -d meet.example.com

Где:

• --agree-tos: примите условия использования.
• -a dns-cloudflare: используем плагин DNS cloudflare для аутентификации, потому что используем службу Cloudflare DNS.
• -i nginx: использовать плагин nginx для установки сертификата TLS. Если вы используете Apache, вам необходимо заменить nginx на apache.
• --redirect: принудительно использовать HTTPS с помощью 301 редиректа.
• --hsts: добавлять заголовок Strict-Transport-Security к каждому ответу HTTP. Заставить браузер всегда использовать TLS для домена. Защищает от удаления SSL/TLS.
• --staple-ocsp: включает сшивание OCSP. Допустимый ответ OCSP прикреплен к сертификату, который сервер предлагает во время TLS.

ШАГ 4. ВКЛЮЧИТЕ HTTP2

HTTP2 может улучшить скорость загрузки веб-страницы. Чтобы включить HTTP2 в Nginx, отредактируйте файл конфигурации виртуального хоста.

sudo nano /etc/nginx/sites-enabled/meet.example.com.conf

Найдите следующие две строки.

listen 443 ssl;

listen [::]:443 ssl;

Добавьте http2 в конце каждой строки.

listen 443 ssl http2;

listen [::]:443 ssl http2;

Сохраните и закройте файл. Затем перезагрузите Nginx, чтобы изменения вступили в силу.

sudo systemctl reload nginx

ШАГ 5. НАЧНИТЕ НОВУЮ ОНЛАЙН-ВСТРЕЧУ

Теперь посетите https://meet.example.com, и вы сможете начать конференцию. Для передачи звука вам необходимо разрешить веб-браузеру использовать ваш микрофон. А для передачи видео вам необходимо разрешить веб-браузеру доступ к вашей камере.

Дайте вашей встрече название и нажмите кнопку Go. После начала собрания вы можете при желании установить пароль для собрания.

ШАГ 6. НАСТРОЙТЕ АУТЕНТИФИКАЦИЮ ПОЛЬЗОВАТЕЛЯ

По умолчанию любой может перейти к вашему серверу Jitsi Meet, создать комнату и начать собрание. Чтобы настроить аутентификацию пользователя, отредактируйте файл конфигурации Prosody.

sudo nano /etc/prosody/conf.d/meet.example.com.cfg.lua

Найдите следующую строку.

authentication = "anonymous"

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

authentication = "internal_plain"

Однако мы не хотим, чтобы участники вводили имя пользователя и пароль при присоединении к конференции, поэтому нам нужно создать анонимный вход для гостей, добавив следующие строки в конец этого файла. Обратите внимание, что вам не нужно создавать запись A DNS для guest.meet.example.com.

VirtualHost "guest.meet.example.com"

    authentication = "anonymous"

    c2s_require_encryption = false

Сохраните и закройте файл. Затем отредактируйте файл конфигурации Jitsi Meet.

sudo nano /etc/jitsi/meet/meet.example.com-config.js

Найдите следующую строку:

// anonymousdomain: 'guest.example.com',

Удалите двойные косые черты и измените гостевой домен. Замените meet.example.com своим настоящим именем хоста Jitsi Meet.

anonymousdomain: 'guest.meet.example.com',

Сохраните и закройте файл. Затем отредактируйте файл конфигурации Jicofo.

sudo nano /etc/jitsi/jicofo/sip-communicator.properties

Добавьте следующую строку в конец этого файла.

org.jitsi.jicofo.auth.URL=XMPP:meet.example.com

Сохраните и закройте файл. Перезапустите службы systemd, чтобы изменения вступили в силу.

sudo systemctl restart jitsi-videobridge2 prosody jicofo

Чтобы создать учетные записи пользователей в Jisi Meet, выполните следующую команду. Вам будет предложено ввести пароль для нового пользователя.

sudo prosodyctl register username meet.example.com

Теперь, если вы создаете комнату в Jitsi Meet, вам нужно будет ввести имя пользователя и пароль.

СОВЕТЫ ПО УСТРАНЕНИЮ НЕПОЛАДОК

Если вы столкнулись с ошибками, вы можете проверить журнал ошибок Nginx (/var/log/nginx/error.log), чтобы узнать, что не так. Также проверьте журналы служб systemd.

sudo journalctl -eu jitsi-videobridge2

sudo journalctl -eu prosody

sudo journalctl -eu jicofo	

Если вы видите ошибку You have been disconnected (Вы были отключены) при запуске собрания в Jitsi, возможно, вы забыли изменить meet.example.com на свое настоящее имя хоста Jitsi Meet в файлах конфигурации.

ОПЦИОНАЛЬНО: НАСТРОИТЬ JIGASI ДЛЯ ТЕЛЕФОННОГО НАБОРА ИЛИ ИСХОДЯЩЕГО ВЫЗОВА

Jitsi предлагает телефонный интерфейс, который позволяет пользователям подключаться к конференции или делать звонки с напоминанием. Установите пакет jigasi (шлюз Jitsi для SIP).

sudo apt install jigasi

Во время установки вам нужно будет ввести свое имя пользователя и пароль SIP. Если у вас его нет, вы можете создать бесплатную учетную запись SIP на сайте OnSIP.com.

Если вы настроили аутентификацию пользователя на шаге 6, вам необходимо отредактировать файл конфигурации Jigasi.

sudo nano /etc/jitsi/jigasi/sip-communicator.properties

Найдите следующие строки.

# org.jitsi.jigasi.xmpp.acc.USER_ID=SOME_USER@SOME_DOMAIN

# org.jitsi.jigasi.xmpp.acc.PASS=SOME_PASS

# org.jitsi.jigasi.xmpp.acc.ANONYMOUS_AUTH=false

Раскомментируйте их и введите учетную запись и пароль, которые вы создали на шаге 6.

org.jitsi.jigasi.xmpp.acc.USER_ID=user1@meet.example.com

org.jitsi.jigasi.xmpp.acc.PASS=user1_password

org.jitsi.jigasi.xmpp.acc.ANONYMOUS_AUTH=false	

Сохраните и закройте файл. Перезапустите службу jigasi systemd.

sudo systemctl restart jigasi

ОПЦИОНАЛЬНО: НАСТРОИТЬ COTURN

Если во время установки Jitsi Meet вы видите следующее сообщение, вам необходимо настроить Coturn, чтобы он работал правильно.

Warning! Could not resolve your external ip address! Error:^

Your turn server will not work till you edit your /etc/turnserver.conf config file.

You need to set your external ip address in external-ip and restart coturn service.

Отредактируйте файл конфигурации Coturn.

sudo nano /etc/turnserver.conf

Найдите следующую строку.

external-ip=127.0.0.1

Замените 127.0.0.1 общедоступным IP-адресом вашего сервера. Сохраните и закройте файл. Затем перезапустите Coturn.

sudo systemctl restart coturn

ИТОГИ

Готово! Мы успешно установили Jitsi Meet на наш Linux сервер.

Источник: https://wiki.merionet.ru/servernye-resheniya/83/rukovodstvo-po-ustanovke-jitsi-meet-v-linux/