オープンソースなWeb会議システム Jitsi Meet Server インストール

Openmeetingsのフル機能がライセンス的な意味で会社で使えなくなって2ヶ月がたとうとしているある日曜日、オープンソースなWeb会議システムを試してみようと考えた。

その名は Jitsi Meet で、なんか面白そうな感じがする。

※今回、Chromeでカメラが使えない問題が発生した。どうやら、JitsiでもChromeでもなくWindowsが原因だった模様、解決できた。これは仕方ないかなぁ…最後の方で顛末を記している。





Jitsi Meetの特徴は、インストールが簡単であること。また、ブラウザでアクセスすれば簡単に会議室が開け、そのURLに他の人がアクセスするだけで会議に参加できること。
画面の共有はできるがOpenmeetingsのように相手に制御を渡すことはできない。また、Openmeetingsのようなホワイトボード機能やスケジュール機能はない。
Flash Playerは使わないし、JNLPを使うこともないので、追加で何かをインストールする必要もなさそう。

ってな具合。とっても良いと思う。

やること。

 

学習

まずは学習だ。
Jitsi / New tutorial: Installing Jitsi Meet on your own Linux Server
Youtubeは凄いなー、テロップを自動で出すだけでなく、それを翻訳できる訳で…俺でもわかる!

このチュートリアルは Ubuntu 16.04 LTS へのインストールをしているようなので、仮想環境で作成。
インストール時にはOpenSSH Serverを選択し、インストール後に以下を行う。

  • アップデートを全部インストールしておく。
  • SSHで接続できるようにする。

チュートリアルでは以下が説明されていた…ように思われる。

  • ルートユーザーでアクセスできるようにする。
    この後の操作は su – した後に行われている。
  • ファイアウォールでTCPの22,80,443、およびUDPの10000-20000を解放する。
    ufw enable
    ufw allow in ssh
    ufw allow in 80/tcp ←でも80番ポートは使わないんじゃね?
    ufw allow in 443/tcp
    ufw allow in 10000:20000/udp ←ビデオ会議だけなら10000/udpでOKだった。2020/06/05追記
  • モジュールをインストールするために鍵を読み込み、リポジトリを登録する。
    鍵をダウンロードする。
    wget https://download.jitsi.org/jitsi-key.gpg.key
    鍵を追加する。
    apt-key add jitsi-key.gpg.key
    ※本当は鍵を確認する手順が説明されているけど、ここでは省略した。
  • リポジトリを追加する。
    echo ‘deb https://download.jitsi.org stable/’ > /etc/apt/sources.list.d/jitsi-stable.list
    SSLによる暗号化を必要とするので、サーバーの証明書を用意する。
    すでにあるものを使ったり、Let’s Encryptを利用したり、自己署名証明書を利用する。
  • WebサーバーはnginxやApacheが利用できる、ブリッジさせる感じ?先にインストールしておく。パッケージインストール時に必要な設定がなされる。
    apt install nginx
    apt install apache2
  • パッケージをインストールする。
    apt update
    apt install jisti-meet
  • インストーラーがホストについて訪ねてくる。
    FQDN名やIPアドレスを入力する。IPアドレスを入力すると、その後はIPアドレスしか受け付けない。
    証明書はどうするか訪ねてくる。
    チュートリアルは生成することを選んでいる。
    うちの場合は自己署名証明書を使うので、I want to use my own certificate を選べば良さそう。
  • ブラウザでアクセスして試す。

 

インストール

Ubuntu16.04でホスト名が使える場合

とりあえず、やってみた。
SSLが必要だから、事前にサーバーの証明書を用意しておく。ウチではオレオレ証明書を使っているので過去記事ベースに作成Let’s Encryptで証明書を取ることができる環境ならこれを使ってもいい
2020/03/27追記 ActiveDirectoryで管理されたネットワークなら、サーバーの管理者に「サーバー証明書署名要求」を送り、署名してもらったものを設置すれば、ドメインに参加しているPCから警告なしにアクセスができる。上記オレオレ証明書に関する投稿で書いたやり方で要求を作って運用できている。

$ sudo passwd ← rootのパスワード設定
$ su - ← rootになる
# ufw enable ← ファイアウォール設定
# ufw allow in ssh
# ufw allow in 443/tcp
# ufw allow in 10000:20000/udp ←ビデオ会議だけなら10000/udpでOK 2020/06/05追記
# ufw status ← 設定結果の確認
# wget https://download.jitsi.org/jitsi-key.gpg.key ← GPGキーのダウンロード
# apt-key add jitsi-key.gpg.key ← GPGキーの登録
# echo 'deb https://download.jitsi.org stable/' > /etc/apt/sources.list.d/jitsi-stable.list ← リポジトリ追加
# apt update
# apt install nginx   ← WebサーバーにNginxを使う場合(どちらか一方)
# apt install apache2 ← WebサーバーにApacheを使う場合(どちらか一方)
# apt install jitsi-meet

インストール中の問い合わせ
The hostname of the current installation:
→ temp.hogeserver.hogeddns.jp

SSL certificate for the Jitsi Meet instance
→ I want to use my own certificate ※この選択はチュートリアルとは違っている

Full local server path to the SSL key file:
→ /etc/ssl/temp.hogeserver.hogeddns.jp.key ※SSLキーファイルをこのタイミングで要求している

Full local server path to the SSL certificate file:
→ /etc/ssl/temp.hogeserver.hogeddns.jp.crt ※SSL証明書ファイルをこのタイミングで要求している

これでインストールは終了。だけど、再起動しないとうまく動かない。

# reboot

 

ブラウザから https://temp.hogeserver.hogeddns.jp にアクセスするとサービスに接続できる。
会議名を適当に入れて会議室を作る…すると、マイクとカメラへのアクセスを求められる。

これだけで起動するし動作する。超簡単。

ちなみに、Apacheの場合、以下のようなサイトが作られて有効になっていた。
/etc/apache2/sites-enabled/temp.hogeserver.hogeddns.jp.conf
<VirtualHost *:80>
    ServerName temp.hogeserver.hogeddns.jp
    Redirect permanent / https://temp.hogeserver.hogeddns.jp/
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>

<VirtualHost *:443>

  ServerName temp.hogeserver.hogeddns.jp

  SSLProtocol TLSv1 TLSv1.1 TLSv1.2
  SSLEngine on
  SSLProxyEngine on
  SSLCertificateFile /etc/ssl/temp.hogeserver.hogeddns.jp.crt
  SSLCertificateKeyFile /etc/ssl/temp.hogeserver.hogeddns.jp.key
  SSLCipherSuite "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
  SSLHonorCipherOrder on
  Header set Strict-Transport-Security "max-age=31536000"

  DocumentRoot "/usr/share/jitsi-meet"
  <Directory "/usr/share/jitsi-meet">
    Options Indexes MultiViews Includes FollowSymLinks
    AddOutputFilter Includes html
    AllowOverride All
    Order allow,deny
    Allow from all
  </Directory>

  ErrorDocument 404 /static/404.html

  Alias "/config.js" "/etc/jitsi/meet/temp.hogeserver.hogeddns.jp-config.js"
  <Location /config.js>
    Require all granted
  </Location>

  ProxyPreserveHost on
  ProxyPass /http-bind http://localhost:5280/http-bind/
  ProxyPassReverse /http-bind http://localhost:5280/http-bind/

  RewriteEngine on
  RewriteRule ^/([a-zA-Z0-9]+)$ /index.html
</VirtualHost>

 

これらの設定をいろんなところに探しにいって、古い情報なのか新しい情報なのか確認しながら試行錯誤しなきゃならない…としたら大変だ。その点、このパッケージは本当に簡単に使えるので感謝である。

 

Ubuntu18.04でホスト名が使える場合

あまりに簡単だったから会社でも使ってみたい。
ホスト名を同じにしてSSLは16.04の時に作ったものを流用、パッケージは全てアップデートしておいた。
Ubuntu16.04との違いは、openjdk-8-jre-headlessを手でインストールすること。

$ sudo passwd ← rootのパスワード設定
$ su - ← rootになる
# ufw enable ← ファイアウォール設定
# ufw allow in ssh
# ufw allow in 443/tcp
# ufw allow in 10000:20000/udp ←ビデオ会議だけなら10000/udpでOK 2020/06/05追記
# ufw status ← 設定結果の確認
# wget https://download.jitsi.org/jitsi-key.gpg.key ← GPGキーのダウンロード
# apt-key add jitsi-key.gpg.key ← GPGキーの登録
# echo 'deb https://download.jitsi.org stable/' > /etc/apt/sources.list.d/jitsi-stable.list ← リポジトリ追加
↓↓ Ubuntu18.04の場合のみ追加。OpenJDK-8がインストールできないから ↓↓
# echo 'deb http://archive.ubuntu.com/ubuntu bionic universe' > /etc/apt/sources.list.d/openjdk-8.list
# apt update
# apt install nginx   ← WebサーバーにNginxを使う場合(どちらか一方)
# apt install apache2 ← WebサーバーにApacheを使う場合(どちらか一方)
↓↓ Ubuntu18.04の場合のみ追加。OpenJDK-8が入っていないから ↓↓
# apt install openjdk-8-jre-headless
# apt install jitsi-meet

インストール中の問い合わせ
The hostname of the current installation:
→ temp.hogeserver.hogeddns.jp

SSL certificate for the Jitsi Meet instance
→ I want to use my own certificate ※この選択はチュートリアルとは違っている

Full local server path to the SSL key file:
→ /etc/ssl/temp.hogeserver.hogeddns.jp.key ※SSLキーファイルをこのタイミングで要求している

Full local server path to the SSL certificate file:
→ /etc/ssl/temp.hogeserver.hogeddns.jp.crt ※SSL証明書ファイルをこのタイミングで要求している

これでインストールは終了。だけど、再起動しないとうまく動かない。

# reboot

 

これで利用できる。

 

Ubuntu18.04でIPアドレスしか使えない場合

会社で使おうとするとき、内向きDNSにサービス登録するのが本来の形。
だけど正式に使うと宣言するまでのテスト段階では、IPアドレスでサービス提供したいな。

この場合、インストールの途中の問い合わせで…

インストール中の問い合わせ
The hostname of the current installation:
→ 172.16.nnn.nnn

 

とサービスを提供するIPアドレスを入力するだけ。

 

他のサービスとの共存を考える

ホスト名で名前解決できる環境ならば、ApacheでいうところのVirtualHostで、別の名前でサービス提供するのが良いと考えられる。サブディレクトリ?は全て「会議室の名前」として利用されるため、サブディレクトリでサービスを分けることができないから。

IPアドレスでアクセスする環境の場合、同様の理由から別のIPアドレスを追加してサービス提供するのが良いと考えられる。

 

ユーザー認証を追加する

LDAP認証の設定について記事を投稿しました2020/04/26追記

Jitsi Meetはアクセスさえできれば誰でも簡単に会議室を作ることができる。ただ、この状態でインターネットにサービスを公開したいとは思わないから…ユーザー認証機構を入れてみようと考えた。

Jitsi Meetの場合、認証されたユーザーだけが会議室を作ることができるようにするようだ。その会議室には誰でも入ることができるが、会議室にパスワードを掛ければ利用者を限定できるよね、ということらしい。

で、その認証はXMPPサーバーで行うらしい。XMPP(Extensible Messaging and Presence Protocol)はサーバーを自由に立てることができ、メールサーバーのように他のXMPPサーバーと連携できる模様。XMPPサーバーはProsody。

# systemctl status prosody
 prosody.service - LSB: Prosody XMPP Server
   Loaded: loaded (/etc/init.d/prosody; generated)
   Active: active (running) since Sun 2019-03-24 05:31:06 UTC; 29min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 929 ExecStart=/etc/init.d/prosody start (code=exited, status=0/SUCCESS)
    Tasks: 1 (limit: 9472)
   CGroup: /system.slice/prosody.service
           mq1243 lua5.1 /usr/bin/prosody

Mar 24 05:31:03 temp systemd[1]: Starting LSB: Prosody XMPP Server...
Mar 24 05:31:04 temp prosody[929]:  * Starting Prosody XMPP Server prosody
Mar 24 05:31:06 temp prosody[929]:    ...done.
Mar 24 05:31:06 temp systemd[1]: Started LSB: Prosody XMPP Server.

 

なるほど。

Github / jitsi/jicofo に設定方法が書いてあって…
/etc/prosody/conf.avail/temp.hogeserver.hogeddns.jp.cfg.lua
(ホスト名は設置する場所に置き換える)
VirtualHost "temp.hogeserver.hogeddns.jp"
        -- enabled = false -- Remove this line to enable this host
        -- 認証方法変更
        -- authentication = "anonymous"      ← コメント化
        authentication = "internal_plain"    ← 追加
        -- Properties below are modified by jitsi-meet-tokens package config

-- ファイルの最後にこれらを追加
VirtualHost "guest.temp.hogeserver.hogeddns.jp"
    authentication = "anonymous"
    c2s_require_encryption = false

guest. がないとマイク・カメラが選択できない症状が現れる。2020/04/14追記。

Prosodyを再起動してみる。

# systemctl restart prosody
# systemctl status prosody
・・・
Mar 24 06:15:29 temp systemd[1]: Started LSB: Prosody XMPP Server.
Mar 24 06:15:29 temp prosody[21794]: portmanager: Error binding encrypted port for https: No key present in SSL/TLS configuration for https port 5281
Mar 24 06:15:29 temp prosody[21794]: portmanager: Error binding encrypted port for https: No key present in SSL/TLS configuration for https port 5281

 

なんかエラーが出てるなぁ。

次に以下のファイルを編集。
/etc/jitsi/meet/temp.hogeserver.hogeddns.jp-config.js
var config = {
・・・
    hosts: {
        // XMPP domain.
        domain: 'temp.hogeserver.hogeddns.jp',
        anonymousdomain: 'guest.temp.hogeserver.hogeddns.jp', ←追加。最後のカンマも忘れずに。

guest. がないとマイク・カメラが選択できない症状が現れる。2020/04/14追記。

/etc/jitsi/jicofo/sip-communicator.properties
これは元々は0バイトファイルだったところに、これを書いて保存。
org.jitsi.jicofo.auth.URL=XMPP:temp.hogeserver.hogeddns.jp

※現在のリリースでは空ファイルではなくなっている。最後に追記して保存。2020/04/18追記。

ここまで設定したところでサービス再起動。

# systemctl restart prosody jicofo jitsi-videobridge2

※2020/06/05 rebootから修正

これでJitsi Meetに接続してみると…あ、普通に会議室に入れるじゃん?と思ったら、違った、メッセージが表示された。

Waiting for the host ...

The conference 会議室名 has not yet started.
if you are the host then please authenticate.
Otherwise, please wait for the host to arrive.
                              [I am the host] ← このボタンを押すと認証画面に入る

 

で、ユーザーはコマンドで管理するっぽい。

ユーザーの追加
# prosodyctl register hoge temp.hogeserver.hogeddns.jp hogepassword
# prosodyctl adduser hoge@temp.hogeserver.hogeddns.jp ← パスワードはコマンド実行後に聞かれる
ユーザーの一覧
# ls -l /var/lib/prosody/*/accounts/*
-rw-r----- 1 prosody prosody 40 Mar 24 04:59 /var/lib/prosody/auth%2e172%2e16%2e219%2e73/accounts/focus.dat
-rw-r----- 1 prosody prosody 40 Mar 24 05:30 /var/lib/prosody/auth%2etemp%2ehogeserver%2ehogeddns%2ejp/accounts/focus.dat
-rw-r----- 1 prosody prosody 44 Mar 24 06:47 /var/lib/prosody/temp%2ehogeserver%2ehogeddns%2ejp/accounts/hoge.dat

 

なんだろな、この focus さんは。
→ 実際、focusさんで認証はできてしまうが、会議室はできなかった。2019/10/09追記
→ focusさんはjicofoがprosodyと連携するためのユーザーで、インストール時に作成され、複雑なパスワードが自動で生成される。2020/06/24 追記

さておき、追加したユーザー hoge@temp.hogeserver.hogeddns.jp と hogepassword を入力することでJitsi Meetの認証ができて会議室が作れるようになった。

ユーザーはJitsi Meetと同じホスト名にしておく必要がありそう。2019/10/09追記
とある環境で hoge@hogeserver.hogeddns.jp というユーザー(サブドメインtempがない)を作ってみたところ、最初の1回は接続できるけれど、その後は上手く接続できない問題が発生した。ユーザー hoge@temp.hogeserver.hogeddns.jp を作り直したところ上手く稼働した。

 

アンインストール

アンインストールするには以下を実行すればいいみたい。
Github / Jitsi Meet quick install

# apt purge jigasi jitsi-meet jitsi-meet-web-config jitsi-meet-prosody jitsi-meet-web jicofo jitsi-videobridge2
# apt purge apache2 ← 使っているHTTPサーバーをパージ。
# apt purge nginx ← 使っているのがNGINXならこちら。 # reboot

※jitsi-videobridgeはjitsi-videobridge2に変わっています。多分2020/3/末頃に。2020/04/18追記

きれいになるので再インストールを試すときにはこれを実行。

 

設定変更

初めてアクセスした際の言語を日本語にする

ユーザーの全てが日本人なので、デフォルトは日本語表示がいい。

/etc/jitsi/meet/temp.hogeserver.hogeddns.jp-config.jp
※赤文字部分は自サイトに読み替える。
    // Default language for the user interface.
// defaultLanguage: 'en',
defaultLanguage: 'ja',

 

 

Welcomeページのメッセージ変更(保証対象外)

2019/10/12追記

Welcomeページのメッセージは、日本語では以下のようになっている。

安全で、機能豊富で、完全に無料のビデオ会議

チーム全体とビデオチャットしましょう。あなたが知っている皆さんを招待してください。Jitsi Meetは完全に暗号化された100%オープンソースのビデオ会議ソリューションで、一日中、毎日無料でご利用いただけます。アカウントは必要ありません。

メッセージは標準的なもので使う分には全く問題ないのだけれど、認証を入れたので「アカウントは必要ありません」というのがちょっと違っている…。

メッセージを変更するためにはソースコードをダウンロードしてきて、メッセージを編集し、それをコンパイルして使うのが正しい使い方とされているのだが、お手軽なメッセージ変更方法はないか探してみた。

結論からすると、以下のファイルを編集するとメッセージが変わる。

/usr/share/jitsi-meet/lang/main-ja.json
700行目付近

"welcomepage": {

"appDescription": "チーム全体とビデオチャットしましょう。あなたが知っている皆さんを招待してください。{{app}}は完全に暗号化された100%オープンソースのビデオ会議ソリューションで、一日中、毎日無料でご利用いただけます。アカウントは必要ありません。",

"title": "安全で、機能豊富で、完全に無料のビデオ会議"
},

※変更後に[CTRL]+[F5]でスーパーリロードすると反映される。

ただし、恐らくパッケージが更新されたときにメッセージは元に戻されるから、一時的なメッセージ変更の方法と考えておくのがよさそう。

 

通信帯域幅を減らす 2020/03/27追記

ネットワーク管理者なら、通信帯域幅が気になることだろう。特に今、急激なテレワークの要求でビデオ会議システムが必要になったのはいいけど、ネットワークがパンクする!という状況が起こりうる。

また、この会議システム、クライアント側でかなりCPUリソースを食う。

これらは高品質な画像を処理するために発生している。

そこで、帯域幅について調べてみた。
jitsi / Decreasing Video Resolution does not decrease Kbits traffic on Jitsi server

ということで、品質を落としたギリギリのラインを攻めてみると…
/etc/jitsi/meet/temp.hogeserver.hogeddns.jp-config.js

resolution: 320,

constraints: {
video: {
aspectRatio: 16 / 9,
frameRate: {
max: 5
},
height: {
ideal: 320,
max: 320,
min: 240
}
}
},

※これだとカメラの画像がパラパラ漫画的に。


resolution: 240,

constraints: {
video: {
aspectRatio: 16 / 9,
frameRate: {
max: 15
},
height: {
ideal: 240,
max: 240,
min: 240
}
}
},

※これだとカメラの画像はかなり荒い感じに。

設定の反映はページにアクセスし直すだけで可能。2020/05/17変更(各種サービスの再起動はいらない)

画質は下がるので痛し痒しな部分もあるものの、用途によって色々と設定を変えて最適な設定を目指す。

frameRate指定をするとFirefoxでビデオが使用できないことが分かったので追記。※2020/06/05時点

 

大量に出力されるログを抑制する 2020/04/15追記

サーバーを移行する機会があって、なんか猛烈にでかいログが出ていて、HDDのイメージをコピーするのにとても時間がかかってしまった。原因の1つがJitsi Meetが強烈にでかいログを吐き出していることだったので、それを抑制する方法を調べた。

Jitsi Meetのログが大量に出ているので抑制してみた

だいぶ落ち着いている。

クライアントPCの負担を減らす 2020/04/18追記

会議室に10接続くらいあると、PCが重くなってくるというユーザーからの声を聞きながら調べてみたところ…
Jitsi Community / High CPU utilization on client end

/etc/jitsi/meet/temp.hogeserver.hogeddns.jp-config.js

// disableAudioLevels: false,
disableAudioLevels: true,

※最後のカンマを忘れずに。

どうも、人数が増えてくると、音声レベル表示の更新がPCの負担になってくるらしい。この設定を入れると、設定後の接続から音声レベルが表示されなくなる(再起動等は不要)。

別の記事では、こっそりこの修正を入れてもユーザーは気付かなかった…とか書かれていた。まぁ、気付いたとしても必要な機能ではないので、大きな問題にはならないかな。

 

会議室の利用状況を確認する方法利用状況を確認する 2020/05/17追記

会議室の利用状況を確認する方法を投稿。
Prosodyのバージョンが新しくなるなどの変更があるので、適用時は注意。

 

利用するメモリを調整する 2020/06/02

このシステムはCPUを使うけれどもメモリはあまり使わないなと思っていた。それは、そのようなデフォルト設定になっていたからだった。
Jitsi Community / [jitsi-dev] Tunning for hard load (or how to have more that 50 people in the same room)

/usr/share/jitsi-videobridge/lib/videobridge.rc
# The amount of memory that the java process can consume.
# Use the format that is in use for java's -Xmx switch
# The default is 3072m
# Only effective on linux, 64 bit
# VIDEOBRIDGE_MAX_MEMORY=3072m

# Uncomment the next line to enable the remote debugging of the video bridge
# VIDEOBRIDGE_DEBUG_OPTIONS="-Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8000"

 

使用するメモリはmeet側の構成にもよるのかもしれないが40~50人くらいまでなら実際1GB程度なんじゃないかと思われる。増やしても良くならなかった的なことも書かれていたので、メモリ使用量を増やすことによる品質向上に過剰な期待はできない。

やったこと

画面共有ができない

どうにも画面共有が起動できない。いろいろと調べてみると、Jitsi MeetをアンインストールしてApacheやNginxをインストールしてからJitsi Meetをインストールしてみ?的なやりとりが見つかった。

# apt --purge remove jitsi-meet jitsi-meet-web jitsi-meet-prosody jitsi-meet-web-config jicofo jitsi-videobridge2
# apt install apache2 ← 日頃使い慣れているから。後でNginxも試したけど、それでもうまくいく。
# apt install jitsi-meet

※jitsi-videobridgeはjitsi-videobridge2に変わっています。多分2020/3/末頃に。2020/04/18追記

あら、これだけでしっかりと使えるように。
/etc/apache2/sites-enable を見てみたら設定ファイルが作られていた。必要ならこれをちょっといじってあげればいいのだろうと思う。

間にApacheやNginxを挟まなくてもポートさえ空けておけば何とでもなるのかなと思っていたが、そうならなかった。理由を突き詰めるところまではやっていない。

 

タブレットのカメラが安定しない

タブレットはWindows10の32ビット版。こいつはカメラが使えるものの、明るくなったり暗くなったりと全然安定しない。なんでだろ?

こちらも、ApacheやNginxを事前にインストールした上でJitsi Meetをインストールしたら解決した。
理由を突き詰めるところまではやっていない。

 

クロームでカメラが使えない

Firefoxでは使えてみたり、Edgeでも使えてみたりするのだけれど、Chromeでカメラにアクセスできない。設定画面では「Permission not granted」と表示される。

Jitsiを調べてみたけれどもこの問題が発生しているのは少数派っぽく、結論が出ていないように見えた。Windowsを再起動しても全然だめ…

試しにOpenmeetingsで試してみたら、マイクもカメラも使える。
これはWindows10の問題の可能性があるなと思い、以下を実行したところ解決した。

  • 設定 を開く(スタートボタンをクリックすると表示される歯車をクリック)。
  • 「プライバシー」をクリック。
  • 左側のペインの「カメラ」をクリック。
  • 項目「アプリがカメラにアクセスできるようにする」が「オン」になっているのを「オフ」にする。
  • Chromeを開きJitsi Meetの歯車をクリックして設定画面を開く。カメラは当然「Permission not granted」になる。Cancelで設定画面を閉じる。Chromeの再起動等は必要なし。
  • 項目「アプリがカメラにアクセスできるようにする」を「オン」にする。
  • ChromeからJitsi Meetの歯車をクリックする。

一口に言うと、いったんWindows10の設定でカメラへのアクセスを制限しエラーを発生させ、その後に設定を緩めるとこの問題が解消するみたい。
再起動しても問題再発することはなかった。

結論、Flashからのカメラへのアクセスはうまくできていたけど、WebRTCからのカメラへのアクセスはWindows的に何かがあってうまくできていなかったのかなと。

 

Edgeでの利用 2020/04/19追記

この記事を書いた後、Edgeでアクセスすると「ChromeかFirefoxで使って!」的なページに飛ばされるようになっていた。

じゃあ使えないのか…というと、ChromiumベースのEdgeであれば利用可能であることが分かった。手動でダウンロード→アップグレードしたところ、問題なく利用できる。

Microsoft / 新しい Microsoft Edge をダウンロード

だけどこれ…Edgeという名前だけれども、Googleアカウントで同期してプラグインもそのまま使える。もう完全にChromium。Edgeを業務利用している場合には、アップグレード前に利用しているシステムが対応済みであることを確認しておいた方がよさそう。

 

さいごに

性能が高くて使いやすいビデオ会議システムが簡単に構築できるのはいいなぁ。
SIPとかも連携できるようになるみたいだけど、自分にはハードルが高いと思うので今回は諦め。

2020/03/28追記 新型コロナウイルスの影響のためかアクセス数が増えていたので、帯域幅に関する記述を追加してみた。皆様のお役に立てるといいなと願って。

“オープンソースなWeb会議システム Jitsi Meet Server インストール” への52件の返信

  1. 役立つ記事をありがとうございます。
    クローム や FireFox でアクセスしても Windows10 のカメラの許可が設定できなくて困っています。
    貴殿の記事「クロームでカメラが使えない」のとおり操作しても許可になりません。
    ご指導いただければありがたいです。

    1. もしdebianやubuntuにサーバー版を入れたのでしたらpackageが更新されているかチェックしてみてください。
      sudo apt-get update
      sudo apt-get upgrade

    2. コメントありがとうございます。
      マイクやカメラを要求されないということは、サーバーが正しくマイクとカメラを要求できていない→サーバーが正しく動いていない、という可能性があります。
      たまたま今日、そんな事象を引き起こしまして…

      (1) 「通信帯域を減らす」の項目で書いている箇所が中途半端で、最後の }, が抜けている。
      結果として、サーバーが正しく起動していない場合があります。
      ※直しておきます。
      (2) 認証機構で、サーバーのFQDNを正しく設定できていない。
      guestと書いたり書かなかったり、設定がややこしいのですが、つじつまが合わない状態になるとサーバーが正しく動作しない場合があります。

      見直しのポイントはこれくらいで、後は…

      (3) ApacheやNGIXの前にJitsiをインストールした。
      不思議ですが何度やっても上手く動かなかったです。Jitsiをアンインストールして、インストールし直したらばきれいに動きました。

      頂いたコメントから想像する確認ポイントはこれくらいです。お試し頂き、結果を教えて頂けますと幸いです。

    3. 昨日、システムを新たに構築した際に同じ現象が発生しました。
      Prosodyの認証設定に誤りがあったためです。サーバー名っぽいところに guest と書いているところがあるのですが、これがないとVideoBridgeとの連携が上手くいかないためのようです。
      本文中の記事で太字にしておきますので、設定をご確認頂けたらと思います。

  2. 参考になる記事有難うございました。
    ユーザーが会議室を勝手に作ってしまう仕様を、貴殿の記事を参考にホストのみが作成できるように変更できました。

  3. インストール中のダイアログで、

    The hostname of the current installation:
    → temp.hogeserver.hogeddns.jp

    とありますが、一度インストールしてしまうと、全消ししてもこの部分がもう出てこなくなります。
    最初www.hogehoge.comに設定して、やはり他のホスト名にしたいと思って変更しようとしましたが、ここが変更できないせいか、SSL設定なども全部このホスト名になってしまうようです。
    全部手作業で直したものの、うまく動いてくれません。
    ここを変更(削除?)する方法はないのでしょうか。

  4. アンインストールの件、解決しました。
    本サイトに記載のアンインストール方法ではだめでした。
    正確には下記の通りです。

    apt purge jigasi jitsi-meet jitsi-meet-web-config jitsi-meet-prosody jitsi-meet-turnserver jitsi-meet-web jicofo jitsi-videobridge2

    jitsi-videobridgeがjitsi-videobridge2に変わっているようです。

    1. アンインストールでFQDNの問題が解決したということですかね。まずは良かったです。
      videobridgeの件はその通りです、今月立てたサーバーの再構築をした際に気付いてはいました。
      tabキーを押せば補完されるような変更なのでまぁいいかと放っておきましたが、せっかくご指摘をいただきましたので更新しておきます。

  5. 初めまして
    テレビ会議について情報を集めている中で、rohhie様の当サイトにたどり着き、
    自前で構築してみようと始めたのですが、サーバ構築後、Windowsからアクセスすると問題なく接続してビデオ会話できるのですが、ipad,iphoneからはミーティングには参加できずに『あなたは切断されました。ネットワーク接続を確認することができます。〇〇秒で再接続します。』との表示がでます。
    jitsi.orgなどで原因を探っているのですが、さっぱりです。
    もしかして、インターネットに出ないとだめなのでしょうか?
    関連するような情報をお持ちでしたら、ご教授ください。

    1. 連投で申し訳ありません。
      前出の中で『インターネットに出ないとだめ』としましたが、
      meet.jit.siにしか行かれない?と考えています。

    2. コメントありがとうございます。
      もしかしてサーバーで「自前の証明書」を使っているのではないでしょうか?

      モバイル版のアプリケーションは、いわゆるオレオレ証明書に対応していないという投稿がコミュニティにありました。
      私が試したときにも同じ表示がされました。

      Androidの場合ですが、Chromeでアクセスしてオプションから「PC版サイト」をチェックするとブラウザからアクセスができます。
      iPhoneだと操作が厳しいかもしれませんが、iPadの大きさがあれば回避策になるかもしれません。

      ご参考まで。

      1. 貴重な情報ありがとうございます。
        ご指摘の通りopensslにて自前の証明書を作成しております。証明書まで考えが至りませんでした。自前の証明書の用意だけで四苦八苦してここまで到達しましたが、なかなか厳しい予感がほのかにして参りました。引き続き対応していきたいと思っていますのでアドバイス頂ければ幸いです。
        また最終目標はビデオ会話のレコーディングまで行きたいと考えていますので、チョイチョイアドバイス頂けると幸いです。
        ありがとうございました。

  6. 初めまして、にっぱーと申します。
    jitsi-meetを設定する上でこのサイトが非常に役立っております。
    ありがとうございます。

    Ubuntu20.04にjitsi-meetをインストールし、hamachiを使ってVPNで接続されたパソコンでビデオチャットできるか試しています。
    しかし、以下のようなエラーが出てしまいます。

    Waring! 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 tu set your external ip address in extarnal-ip and restart coturn service.

    hamachiのipアドレスが外部IPアドレスとして認識されてないことが原因であると思うのですが、解決策がわかりません。
    お知恵を貸していただけると幸いです。

    1. コメントありがとうございます。hamachiを使ったことがなくよく分からないところがあるので、全て想像・仮定で書きます。

      (仮定)
      会社でJitsi Meetサーバーを立てて、社内ではビデオ会議ができることを確認した。
      在宅ワークをしている方とhamachiを使ってVPNでつないだので、その人にも会議に参加して欲しいが、External IP addressを解決できないと怒られた。
      (仮定があっているとしたら)
      Jitsi MeetサーバーもhamachiのVPNに参加する必要があるのかなと思いました。
      hamachiというのは「ソフトをインストールして、サーバーにログインして、登録済みのVPNに参加する」仕掛けになっているようなので、VPNに参加している人達だけが通信できるようになるのではないでしょうか。

      あくまでも勘で書いちゃってますので、違っていたらすみません。
      うまく会議ができると良いですね。

  7. 連投失礼します。
    hamachiのIPアドレスをDNSと関連付けして再度jitsi-meetをインストールし、hostnameにDNSを設定すればエラーは消えました。
    よって上記の質問は答えていただかなくても大丈夫です。

    hamachiを使用してもDNSとの関連付けは必要そうですね。
    VPN接続してDNS使わずにできないか模索しています。

    1. 入れ違いにコメントをいただいてました。
      DNSと関連付ける、hostnameにDNSを設定する、ということそのものが未経験で…駄目ですね、答えが出せませんでした。

      イントラネットやVPN接続している方だけに見せたいIPアドレスというのはあります。
      私は自宅でDNSサーバーを稼働させて、インターネットからはグローバルIPアドレスが戻り、イントラネットからはローカルIPアドレスが戻るようにしています。

      上手く設定ができたらぜひ教えてください。

  8. ご丁寧な返信ありがとうございます。

    私の目的としてはhamachiのVPNでVPNネットワークに参加した人だけが繋げることのできるjitsi-meetのサーバを作ることです。

    hamachiはjitsi-meetのサーバ(Ubuntu20.04)にも入っており、専用のVPNのIPアドレスが割り振られているのですが、そのIPをJitsi-meetインストール時のhotsnameに入れてサーバを起動しても、ほかのパソコンからアクセスができない状態です。

    ネットワークの設定はなかなか難しいですね。
    進展すればまたこちらに書き込ませていただきます。

    1. Jitsi Meetをインストールしたサーバーにhamachiが入っていて、インストール時のホスト名にIPアドレスを指定したなら、Jitsi Meetはきっと正しくインストールされていると思います。アクセスできない原因はルーティングなのかもしれないですね。
      基本的なところになってしまいますが、
      $ ip addr
      $ ip route
      で念のため設定を見つつ、
      /var/log/apache/access.log や error.log、あるいは、
      /var/log/nginx/access.log や error.log で実際に利用者PCからのアクセスが届いているのか、その結果どうなったのかを見てみるところからでしょうか。
      パケットが到着しているけれど、返事を投げていないのか、投げているけれども届かないのか、投げているつもりが違う経路に投げちゃっているのか、というところを見極めていく感じでしょうか。
      さらっと探してみたら、こんな記事もありました。
      https://community.logmein.com/t5/LogMeIn-Hamachi-Discussions/Route-all-the-traffic-through-Hamachi/td-p/120734

  9. 貴重な情報ありがとうございます。
    ご指摘の通りopensslにて自前の証明書を作成しております。証明書まで考えが至りませんでした。自前の証明書の用意だけで四苦八苦してここまで到達しましたが、なかなか厳しい予感がほのかにして参りました。引き続き対応していきたいと思っていますのでアドバイス頂ければ幸いです。
    また最終目標はビデオ会話のレコーディングまで行きたいと考えていますので、チョイチョイアドバイス頂けると幸いです。
    ありがとうございました。

    1. 返信してみて良かったです。オレオレCA証明書を端末にインストールしても効果がないので探してみたら、対応していないけどLet’s Encryptがあるじゃん、という「確かに」的な回答だった記憶です。オープンソースですから自分で変更を入れてコンパイルすればいいのかもしれませんが、ハードルがかなり上がってしまいますよね。

      Let’s Encryptは無料で良いのですが、取れない環境(イントラネットでIPアドレス運用しているとか、dynamic dnsを利用していて思い通りに取れないとか)もあったりすると思いますので、どちらを選択するのかは難しいところです。

      レコーディングはJigasiでしょうか?試してみようと思いながらも、なかなか時間が取れずにいました。録画はローカルマシンでWindowsの標準機能を使って…という経験だけですが、とりあえずは上手くいきました。お手軽ではあります。

      それにしても、自前の証明書が用意できただけでも凄いことだと思うのですよね、経験からするとあれはなかなか大変ですから。

      無事ゴールにたどり着けると良いですね。

      1. 返信ありがとうございます。
        今回の件では証明書でハマるとは思っていませんでした。引き続きトライしていきます。
        録画についてはjibriを入れてみようと考えていて、理由はyoutubeで検索した際に最初にお手本動画に当たったためです。jitsiの構成を十分把握していないのですがjigasi でも行けるのなら試してみたいですね。引き続き何かありましたら、ぜひご教授お願います。

        1. 失礼しました、JibriがYouTubeとの連携モジュールですね。
          JigasiはSIPサービスなので全然違ってました。

          コメントをいただいたことで、この記事を元に環境構築すると、自前の証明書ってことになるのかと、改めて気付かされました。
          今のところ記事の修正は考えていませんが、今後投稿する記事では意識していきたいと思います。

          Let’s Encryptで証明書を取得できる環境なら差し替えは可能です。
          Apacheかnginxで参照する証明書を変えるだけで動くはずです。

          今後も何かありましたら気軽にコメントしてください。

  10. いろいろご教授頂き申し訳ありません。
    そもそも私が目指すゴール地点、前提をお伝えしていなかったため貴重なお時間を頂く結果となり申し訳ありませんでした。ゴール地点、前提は全てのサーバ、クライアントがインターネットには出れない環境下においてビデオ通話と録画を実現したい。但し構築時はインターネット接続は可とする。非常に手前勝手なゴールになっております。
    自分でやっていて、なんだかな?と思うところもありますが、これに懲りずにお付き合い頂ければ幸いです。

    1. 時間については大丈夫です。できる範囲でしかやりませんので。

      ゴール地点をそこに置いているのだとすると、Jibriの利用は難しいように思いました。私の理解では、Jibriの録画先はYouTubeなので。

      ローカルネットワークでの運用で録画が必須ならば、私の知る範囲ではOpenmeetingsなのかもしれないと思いました。
      セットアップはJitsi Meetより少しハードルが高く、ユーザー管理も必要になってきますが(自動登録機能はありますが)、良いシステムだと思います。ホワイトボード機能もあるので、喜ばれるかもしれません。
      少なくともVersion4時代には録画機能があり、かなり使い込んでいましたが、便利でした。多分5.0.0.M4にも録画機能はあると思います。

      そういう需要もあるかと思いまして、記事を投稿したりもしています。
      https://rohhie.net/ubuntu18-04-clean-install-of-openmeetings5-0-0-m4/

      既に証明書が準備できているのであれば、やれることの範囲は広がっています。

  11. 仕事の都合で返信できず申し訳ありませんでした。
    確かにJibriはYouTubeを録画先にしているようなのですが、せっかくなので少し弄ってから決めようと思います。Openmeetingsなるものがあるのですね。自分のゴール地点に近いです!jibrをやりつつOpenmeetingsもやってみようと思います。貴重な情報ありがとうございます。

    Jitsiの方で一つ作業工程を飛ばしていたことがありました。Jitiを始めたころは様子見でLet’s Encryptを選択していたのです。Let’s Encryptは最後に証明書のインストールが必要だったのですね。インストールしなくてもしっかり動いていたので気が付きませんでした。もう一度Let’s Encryptでやってみます。

    結果はまた報告させていただきます。ではでは。

    1. 証明書は誰でも作ることができますが、誰がお墨付きを与えてくれるのか、というのがポイントです。

      Let’s Encryptは一般的なシステムで「安全」とされた認証機関で、それが署名してくれているので普通にアクセスできるのですが、署名されていない場合や自己署名(オレオレ認証局で署名したオレオレ証明書)だとユーザーに警告が表示されます。

      ActiveDirectoryでドメイン管理された環境なら、利用者のPCに「安全な認証局」として管理者が用意したオレオレ認証局を登録できますので、その認証局に署名された証明書を使ったサイトは、ユーザーにとってみると安全に見えます。

      証明書の部分は「危険を承知でアクセスする(実際我々が用意するサーバーなので安全ですけど)」という形で回避することができますので、ユーザーの理解が得られれば運営できるような気がします。私の職場はそうはいかなかったので、安全に見えるように細工をしました。

      ・LAN内に立てたサーバーはドメイン管理者の用意した認証局に署名してもらった証明書を利用。
      ・インターネットに立てたサーバーはLet’s Encryptで取得した証明書を利用。(ワイルドカードの証明書)

      どちらもインストーラーで自動取得できないタイプなので、インストール時には証明書を自分で用意する選択して、手動で設定しています。

  12. こちらのHPを参考にさせていただき、質問をした後に試行錯誤した結果、クライアントがJitsiサーバを読み込もうとするところまで来ました。

    しかし、現況は以下のようなエラーがnginxのエラーログに出力されている状態です。

    2020/05/25 16:08:50 [crit] 10333#10333: *44 SSL_read() failed (SSL: error:14191044:SSL routines:tls1_enc:internal error) while processing HTTP/2 connection, client: 127.0.0.1, server: 0.0.0.0:4444

    SSL認証がクライアント側で読み込めていないと認識しているのですが、どこを直せばいいかがわかりません。
    お忙しい中恐縮ですが、お知恵を借りられれば幸いです

    構成は以下のとおりです

    OS:Ubuntu20.04
    webサーバ:nginx/1.17.10

    SSLの設定については以下のサイトを参考にし、Common Nameを書き込むところをVPNのIPアドレスにしました。

    https://www.server-world.info/query?os=Ubuntu_20.04&p=ssl&f=1

  13. 上記の続きですが、クライアント側からクロームやFirefoxでVPNのIPアドレスに接続すると警告が出て、そちらを無視して進むと読み込みこもうとするのですが、画面が切り替わらないといった状態です。

    1. これは恐らくですが、nginxが証明書を正しく読み込めないために、クライアント(ChromeやFirefox)との通信を暗号化できない、というエラーが出ているように思われました。

      書いて頂いた内容からすると、まだ、署名要求(リクエスト)までしかできていないように思われます。

      最後の署名をすればnginxは暗号化をはじめると思います。

      実はちょうど今、証明書に関する記事をまとめ直しているところなのですが、恐らく証明書っていうのは、こういうことなんだろうと思うんです。

      秘密鍵がある(これが人だったり目的だったりを表す)。

      秘密鍵からリクエストを作る(僕は○○がしたいんだ)。★今はここですね。

      リクエストに署名すると証明書になる。

      署名をする人が権威のある人だと、世の中的に安心アクセスするための証明書になるし、ActiveDirectoryの管理者なら管理するAD範囲の人が安心してアクセスできる証明書になる。
      自分で署名すると、自己署名証明書、ということになります。どのシステムからも全く信用されないけれども、ユーザーが「アクセスする」と決めればアクセスできるサイトで使われる証明書です。

      私が過去に書いた記事では、自分で署名するんだけれども、署名するのはオレオレ認証局ですよ、と宣言しています。ユーザーにオレオレ認証局の証明書を信用してもらえれば(ルート認証局として登録してもらえれば)、オレオレ認証局が署名した証明書ならば安心、とシステムが理解するようになります。
      https://rohhie.net/certification-authority-to-make-at-company/

      前置きが長くなりましたが…今回にっぱーさんに示して頂いたサイト(私もよく教えてもらっているサイトです)では、オレオレ認証局を作っていませんので、ユーザーに「それでも僕はアクセスする」という操作をしてもらう必要がありますが、暗号化ができるようになりますので、ビデオ会議はできるようになります。

      緑色の箇所が管理者が入力する箇所で、解説すると

      (1) /etc/ssl/privateに移動(ここで作業をします)
      (2) openssl genrsa で秘密鍵を作ります。
      (3) openssl rsa で秘密鍵からパスフレーズを削除 ★ここで秘密鍵完成
      (4) openssl req で僕は何かがしたいというリクエストを作ります。ここでやりたいことは宣言していないように見えます。
      (5) openssl x509 でリクエストに署名して証明書にします。★ここができていないと思います。

      という具合だと思います。

      ここまでできたら、nginxでは証明書として server.crt(csrではありません) を、秘密鍵として server.key を読み込むようにすれば、暗号化通信ができるはずです。

      認証局を作った方がよりユーザーに安心感が出てくると思うのですが、まずは通信できるようにすることが先ですよね。

      長くなってしまいました。結果が出ることをお祈りしております。もう一息です。

      1. 詳しい説明ありがとうございます。

        >ここまでできたら、nginxでは証明書として server.crt(csrではありません) を、
        秘密鍵として server.key を読み込むようにすれば、暗号化通信ができるはずです。

        nginxに証明書を読み込むようにするというのは/etc/nginx/nginx.confにcrtとkeyの
        パスを書き込むという認識でよろしいでしょうか?

        nginx.confのhttpの枠内に以下のような設定を追加しました。

        http {
        …(略)

        server {
        listen 443 ssl;
        server_name ;
        ssl_certificate /etc/ssl/private/server.crt;
        ssl_certificate_key /etc/ssl/private/server.key;
        }
        }

        しかし、現在上記の設定を行ってnginxを再起動し、ステータスを確認すると以下のエラーが発生します。

        nginx: [emerg] bind() to 0.0.0.0:443 failed (98: Address already in use)

        443ポートが既に使われているというエラーだと認識していますが、lsofコマンドを使っても443を
        使用しているプロセスはありませんでした。そして、nginx.confの設定を元に戻すと正常に動作しました。

        そもそもnginx.confを編集することが間違っているのか、それとも別の要因があるのかが分かりません。
        お手数ですがお知恵を貸していただければ幸いです。

        1. それは、追加する場所が違っていると思います。前回回答の私の想定が間違っていました。

          nginx.confはNginXの基本動作が書かれていますが、恐らく、最後の方に

          include /etc/nginx/conf.d/*.conf;
          include /etc/nginx/sites-enabled/*;
          }

          という行があると思います。Jitsi Meetの証明書関連の設定は、
          /etc/nginx/sites-enabled/hogehoge.conf
          から読み込まれます。(hogehogeはにっぱーさんのサイトに読み替えてください)

          ここに、server の設定があって、Jitsi Meetの設定が書いてありますので、
          ssl_certificate /etc/ssl/private/server.crt;
          ssl_certificate_key /etc/ssl/private/server.key;
          に修正します。

          既に使われているというエラーが出るのは、nginx.confに新しいサイトを追加し、そこで443を先に使ってしまった後に、include文でJitsi Meetの設定が読み込まれ、さあ443を使おうと思ったら既に使っていた…という状況だからだと思います。

          どうしても上手くいかない場合は、nginxとJitsi Meet関連のファイルをアンインストール(purge)して、nginx→Jitsi Meetの順でインストールし直します。
          途中で証明書について聞かれるので、
          /etc/ssl/private/server.key
          /etc/ssl/private/server.crt
          と回答すれば正しく設定し直してくれるので、動作すると思います。

          ※NginXについてあまり知らないので、今、Ubuntu20.04環境にインストールしてみましたが、Jitsi Meetのダウンロードに結構時間が掛かります。
          世界的にユーザーが増えているのでしょうね。ですので、最初は設定修正を試し、駄目なら再インストールって感じかなと思いました。

          ※ただ、設定修正を頑張りすぎる必要はありません。インストールしなおせば必要な設定をしてくれますので。

          あと一歩ですね。

          1. お忙しい中、迅速な返信ありがとうございます。
            もう少しだろうという手応えはあるのですがなかなか前に進めません。

            とりあえずすべてアンインストールして以下の手順で設定し直してみました。

            ①apt updete および upgrade

            ②SSL承認の手順(1)~(5) (前回貼ったURLの手順)

            ③こちらのサイトにあるJitsi-meetのインストール手順 ufw enableからrebootまで
            ・インストール中の問い合わせではVPNのIPアドレスを指定し、crtとkeyは
            /etc/ssl/private配下のserver.crtとserver.keyを指定

            reboot後、友人の家にあるパソコンからIPアドレスを入力してもらって接続しても読み込みはするのですが
            画面が切り替わりませんでした。
            エラーログを確認すると以下のようなエラーが出ています。

            2020/05/27 06:45:05 [crit] 756#756: *24 SSL_read() failed (SSL: error:14191044:SSL routines:tls1_enc:internal error) while processing HTTP/2 connection, client: 127.0.0.1, server: 0.0.0.0:4444

            >Jitsi Meetの証明書関連の設定は、/etc/nginx/sites-enabled/hogehoge.conf
            から読み込まれます。

            ということをアドバイスいただきましたので、confを確認したのですが、
            ssl_certificateおよびkeyは既にprivate配下のcrtとkeyが指定されていました。
            内容は以下のとおりです。

            server {
            listen 80;
            listen [::]:80;
            server_name <VPNのIPアドレス>;
            (略)
            }
            server {
            listen 4444 ssl http2;
            listen [::]:4444 ssl http2;
            server_nameserver_name <VPNのIPアドレス>;

            (略)

            ssl_certificate /etc/ssl/private/server.crt;
            ssl_certificate_key /etc/ssl/private/server.key;

            これで行けるかと思ったのですが、現状はやはりエラーログの通りSSLが読み込めていない状況です。
            お忙しい中、大変恐縮ですが、お知恵を貸していただければ幸いです。

            あと、関係ないかもしれませんが listen 443を指定してある内容が
            /etc/nginx/modules-enabled/60-jitsi-meet.confにありました
            内容は以下の通りです。

            stream {
            upstream web {
            server 127.0.0.1:4444;
            }
            upstream turn {
            server 127.0.0.1:4445;
            }

            (略)

            server {
            listen 443;
            listen [::]:443;

            こちらのserverにもcrtとkeyのパスを書き込んだほうがいいでしょうか?
            以上、長文で失礼いたしました。

  14. 色々と試して頂いて恐縮です。
    示して頂いた情報からすると、証明書に問題があるという印象です。
    ※ご友人の家からのアクセスはまた別の要素が入り込み得るので、まずは置いておきます。
     色々な技術が絡んでいるので、1つ1つ解決したいと思います。

    サーバーをIPアドレス指定でインストールし直したのですが、どうにも問題が再現できない…

    ServerWorld様の1~5の手順を実施し、その上で、Jitsi Meetを再インストールして/etc/ssl/private/~.crt と key を設定したのであれば、Jitsi Meetの設定を修正する必要は恐らくないと思います。それを設定するためのインストール中の問いかけなんですね。

    ※アンインストールについてやってみて1つ不足していることが分かりました。apt purege nginx を実行しておく必要がありました。Jitsi-meetのインストールで問いかけがあったということは、恐らくこれは実行して頂いているものと想定しています。

    VPNのIPアドレスと書かれている部分が何を示しているのかちょっと分からないところがあったのですが、少なくともUbuntu20.04をインストールしたサーバーのIPアドレスを指定する形でインストールし直したところ、問題なく起動しています。

    可能なら、Contactのページから key, csr, crt の中身(テキストになっていると思います)を送って頂ければ、証明書が作られた過程をある程度確認させて頂くことはできます。
    その他できることといえば、時間を合わせてWeb会議しながら問題を1つ1つ解消していくことくらいでしょうか。
    ※key, csr, crt はここに書くとインターネットに公開されてしまいますので、送る場合は必ず Contact から送ってください。
    念のため、
    https://rohhie.net/contact/
    です。

    server.crtは正しく作成したのであれば、クライアント側にインストールしても効果はありません。
    クライアント側にインストールして効果が出るのは 1)CAの証明書(ルート認証局とかいわれてますね) 2)クライアント証明書(アクセスしてくる人を制限したいときに使います) のいずれかです。
    これらは秘密鍵から作ること自体は変わらないのですが、作るためのパラメーターが違ってきます。

    1. 早速の回答、ありがとうございます。

      >VPNのIPアドレスと書かれている部分が何を示しているのかちょっと分からないところがあったのですが、少なくともUbuntu20.04をインストールしたサーバーのIPアドレスを指定する形でインストールし直したところ、問題なく起動しています。

      VPNのIPアドレスとは、hamachiをUbuntuにインストールし、ネットワークに接続することで払い出されるIPアドレスを指しています。
      Jitsi-meetをVPNで接続することが目的なのでこちらのIPアドレスを設定していますが、それが間違いだったのかもしれません。検証してみます。

      Contactのページから key, csr, crt の中身を送信しましたのでご確認いただけると幸いです。

  15. Jisti-meetおよびnginxをインストールし直し、IPアドレスはローカルIPの192.168・・・を設定
    /etc/turnserver.confのexternal-ip=にhamachiのVPNアドレスを設定してreboot後接続を試しました。

    ローカルIP内であれば external-ipをアドレス欄に入力すれば接続できるのですが、やはり外部からexternal-ipをアドレス欄に入力しても
    SSL_read() failedと、前回と同様のエラーが出る状況です。

  16. コメントありがとうございます。

    にっぱーさんに送っていただいた秘密鍵とサーバー証明書を実際にNGINXに設定して起動してみました。
    ・秘密鍵と証明書はできあがっていて、暗号化に使える状態になっていました。
    ・上手く接続できる環境で証明書だけを差し替えてテストし、アクセスできることが確認できました。
    ・UbuntuにIPアドレスを追加(証明書に含まれていたサーバーのIPアドレス、hamachiのIPアドレスですね)し、Jitsi Meetをインストールし直し、クライアントPCにIPアドレス(証明書のIPアドレスにアクセスできるもの)を登録、証明書に含まれていたサーバーのIPアドレスでアクセスできることが確認できました。

    以上のことから、JItsi Meetのインストールには成功しており、証明書にも問題はなく、NGINXも問題なく動作していることが分かります。hamachiがVPN接続で、VPN接続したPC同士が無制限に接続できるものならば、問題なく動作するはずですが、そうなっていない…と。

    今、この状態にいたって、最初にコメントをいただいたときからここまでは上手くいっていたものと思いました。
    (ここまで理解したところで過去をたどると、情報がつながりました)

    ろっひーはようやくここでスタートラインに立ったようです。

    インストールし直した際の/etc/turnserver.confは以下です。これは変えないように書かれていますね。
    (Apacheで構築した環境にはないファイルなのでなんだろ?と思っていましたが、これもここで分かりました)
    —————————
    # jitsi-meet coturn config. Do not modify this line
    use-auth-secret
    keep-address-family
    static-auth-secret=*ここはインストールするたびに変わります*
    realm=2**.***.***.*** *ここは送っていただいた証明書に含まれたhamachiのIP*
    cert=/etc/ssl/private/server.crt
    pkey=/etc/ssl/private/server.key

    no-tcp
    listening-port=4446
    tls-listening-port=4445
    external-ip=127.0.0.1

    syslog
    ——————

    再度整理すると…
    [Jitsi Meet] <-> [NGINX] <-> クライアントPC は接続OK。
    [Jitsi Meet] <-> [NGINX] <-> [hamachi] <-localnet-> [hamachi] <-> クライアントPC は接続OK。
    [Jitsi Meet] <-> [NGINX] <-> [hamachi] <-internet-> [hamachi] <-> クライアントPC が接続NG。
    ということなのかと思います。

    接続NGの場合は、NGINXがSSLでエラーを出力しているということな訳ですが、エラー番号でGoogle検索をしても何が起きているのかということを突き止めることができていません。

    NGINXはエラーが発生するその手前、エラー直後にもいくつかログを出していると思われます(日頃使っていないので断言はできませんが、要求と何をしようとしていたか、エラー、その後どうしたか…を普通なら出力するだろうと思います)。error.logではなくaccess.logに出ているかもしれません。

    その前後の情報も併せて調査するか、あるいは…
    ~[hamachi] <-localnet-> [hamahci]~であれば上手くいき、
    ~[hamachi] <-internet-> [hamachi]~ではエラーが出るのだとすると、出力されるログの違いを手がかりに問題を解消していくようになると思います。

    このあたりの情報がもらえると(プライバシー情報を含むならContactからでお願いします)、もう少し調査ができるかもしれません。

    NGINXの情報交換を色々と眺めていると、SSL通信をProxyするあたりで条件を緩和して上手くいったというような記述もあったように思います。どこかにもう少し追加の設定が必要になりそうです。

    1. こんな朝早くから回答。ありがとうございます。

      >再度整理すると…
      >[Jitsi Meet] [NGINX] クライアントPC は接続OK。
      >[Jitsi Meet] [NGINX] [hamachi] [hamachi] クライアントPC は接続OK。
      >[Jitsi Meet] [NGINX] [hamachi] [hamachi] クライアントPC が接続NG。
      >ということなのかと思います。

      まさに仰るとおりで、ローカル同士なら接続できるのですが、インターネット間での接続ができない状態です。

      >このあたりの情報がもらえると(プライバシー情報を含むならContactからでお願いします)、もう少し調査ができるかもしれません。
      こちらはnginxのaccess.logとerror.logをContactでお送りすればよいでしょうか?
      送ってはいけないプライバシー情報は使用していないと思うので大丈夫だと思います。

      1. 1点質問なのですが、rohhie様は

        [Jitsi Meet] [NGINX] [hamachi] [hamachi] クライアントPC

        こちらの接続もできているという認識でよろしいでしょうか?
        それともこちらはまだ試されていないでしょうか?

        1. 書き間違えました

          [Jitsi Meet] [NGINX] [hamachi] [hamachi] クライアントPC

          こちらのインターネット間の接続ができていたかどうかをお聞きしたいです。

          1. ログに関してはContactから送ってください。
            hamachiを使ったインターネット間接続は試していません。

            hamachiはインストールしていません。インストールすればどういうものなのかもっと理解が進むと思うのですが、自分的には深みにはまりそう(色々と調べたくなる)で怖くてできないでいます。そこで、1つのNICにVPNのIPアドレスを追加で持たせてサーバーを構築して擬似状態を作り出し、クライアントはVPNっぽいIPアドレスだけを持たせてテストしてみました。

            もらったログから何も分からず…という状態になったら、インストールしてみようかと思っていたところです。同じことをすれば、同じ結果になるはずですから。

    1. ログを確認しましたが、接続要求があってすぐにエラーが出るのではなく、数秒経ってからエラーが発生したり、アクセス要求の前にエラーが発生したりしていました。後者は置いておいて前者を考えると、インターネットを介した接続でもポータルは表示され、そこから会議室に入るときに問題が発生?とか想像しています。

      とりあえず、Ubuntuにhamachiをインストールして匿名でログインしてみたところ、ham0というインターフェースが追加され、IPアドレスが払い出されました。
      3: ham0: mtu 1404 qdisc fq_codel state UNKNOWN group default qlen 1000
      link/ether 7a:79:00:00:00:00 brd ff:ff:ff:ff:ff:ff
      inet 2n.nnn.nnn.nnn/8 brd 25.255.255.255 scope global ham0
      valid_lft forever preferred_lft forever
      ※ログオフしても払い出されたIPアドレスは残ってました。

      これを使って問題再現するか試してみようと思います。

        1. 試しました。

          [Ubuntu20.04 Jitsi Meet x NGINX] <-hamachi-> [家Router] <-internet-> [スマホテザリング] <-hamachi-> [Ubuntu20.04 Chrome]

          仮想PCで実行するより他ないため、ローカルPC同士ではあるものの、
          ・スマホテザリングの方はLANを無効化し、スマホテザリングのみでネット接続
          ・念のためFirewallでお互いのパケットをDeny指定
          という形で切り分けてやってみましたが、接続できています。ビデオ通話までは試せていないのですが、Videobridgeとつながったであろう動作をしています。

          Jitsi MeetとNGINXはアンインストールし、最初にNGINXをインストールし、その後にJitsi Meetをインストール。
          インストール時の問い合わせには、ホスト名として hamachi のIPアドレスを入力し、鍵と証明書はニッパーさんのものを指定しました。

          ネットワークID(?っていうのでしょうか)とパスワードををメールでお送りしますので、気が向いたら接続を試してみてください。
          しばらく立ち上げっぱなしにしておきます。

          ただし…以下は失敗しています。
          [Ubuntu20.04 Jitsi Meet x NGINX] <-LAN-> [Windows Chrome]
          ページは表示されますが、会議室に入ったあとVideobridgeとの接続が確立できませんでした。
          ただこれは、今、にっぱーさんが直面している問題とは別の問題ととらえて、一旦切り離します。

  17. おぉ!いけましたか!
    それは希望が持ててきました。

    しかし、とするなら何が原因なのか・・・

    とにかくあたってみます!
    検証ありがとうございます。

    1. 昨日はどうもありがとうございました。
      テスト環境とは言え、お互いのサーバーに入るというのはエキサイティングな体験でした。
      そして、実はITにかなり詳しい方だということが分かり、良い経験をさせていただきました。

      Web会議システムは安定性が一つの判断ポイントになるので、どうにか安定通信を確保したいところです。
      にっぱーさんの環境では解決しなければならない課題がありそうに見えました(まだ見極められていませんが)。
      症状からすると、MTUに関連する何らかの問題のようにも見え、Ubuntuにはそれに関わる問題があるようです。
      https://qastack.jp/server/488893/how-do-i-prevent-tcp-connection-freezes-over-an-openvpn-network

      ここの「回答」のところに
      $ sudo ip link set dev tun0 mtu 1350
      というのがあります。今回でいうと、サーバー側のham0をこのくらいまで落としてみると状況が改善するかもしれません。
      (hamachiにおける正しい設定方法はこれから調べる感じですが…)

      ご検討ください。

  18. その後、Contactからいただいたことも含めて、にっぱーさんからいただいたお問い合わせを整理します。

    まず、結論。
    hamachiで作るVPN環境でJitsi Meetを使ったWeb会議環境の構築は可能。
    Jitsi Meetのインストール時にhamachiのIPアドレスを指定すればシステムは問題なく動作し、自作の秘密鍵・サーバー証明書で問題なくアクセスができる。

    正確なところは分からないものの、
    ・/etc/turnserver.conf の設定値はファイルに書かれているとおり変更不要で、external-ip=127.0.0.1のままで良い。当初は一部だけ何かをカスタマイズしてインストールしていて、経路上の何らかの問題を引き起こしていた。
    ・nginxで証明書が読み込めないエラーは発生しない。ご提示いただいた証明書と、エラー発生時の証明書は違っている可能性が高い。
    ・接続ができない問題はMTU値を上手く処理できないUbuntuのバグにはまっている、経路の途中に何かある。
    というところだったのかと想像します。

    全部自分でやってみた構築結果に基づく想像ですが…。
    最後のMTU値については解決をプラットフォーム変更(Hyper-V→VMware)で実現したものと思われます。
    SSHでログインした後にファイルを開くとフリーズしたり、Jitsi Meetインストール中の問い合わせ画面で必ずフリーズしたりする問題は、Hyper-VだけでなくPCに直接インストールしたというUbuntuでも発生していましたから、経路の途中にIPv6があってみたり、何らかMTU値の低い装置があったりすることで、Ubuntuの潜在バグを顕在化させたのかなという印象です。

    スピード感と問題原因の究明は相反するものに感じます。とりあえずシステムが構築できてしまって、運用できちゃっているものとしてのおごりかもしれませんが書くと、問題原因をはっきりさせて対策しないと、利用者の不便を作り出してしまったり、問題の原因を利用者に求めてしまったりして、長い目で見てみんなをハッピーにできないようなことになりかねません。自戒を込めて書きますが、そのシステムを使う・使わないは利用者が決めるもので、気持ちよく利用するためには少なくともシステムを安定的に稼働させておく必要があります。そのために1つ1つの問題を丁寧に解決している感じです。
    その上で…ビデオ会議システムのエクスペリエンスは、利用者の回線品質によって大きく左右されます。一人が駄目だと、他の全員に影響が出るのもその特徴で、実は例えばTeamsでも一人の回線品質によって会議の質は大きく下がったりします。地味ですが、丹念に調べて整理しています。

    実際には、利用者が本当に駄目な使い方をしていることもあります。でも、問題を解決する方法を教えてあげるだけでとても感謝されたりもします。聞いてくれるということは使おうとしてくれているってことですから、頑張りどころだったりもするんですよね。これも自戒ですが。

    ところで…このシステムはメモリは最大でも3GB程度しか消費しません(デフォルト設定では)。とにかくCPUを消費しますが、hamachi無料範囲の5人であればCPU1つでも余裕があると思います。

    そろそろ本格稼働するでしょうから、経験を踏まえて思ったことを書いてみました。
    また、お気軽にコメントいただけましたら幸いです。

お気軽にどうぞ ~ 投稿に関するご意見・感想・他

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です