websocket サーバーを OpenWrt で運用する

（👉 公式ドキュメント）

Quick start

（ローカル PC でのテスト。OpenWrt とは無関係な websockets 自体の話）

ハローワールド

  • CUI ウィンドウを 2 つ開いて、server.py を実行すると、無限ループで強制終了するまで動き続ける。もう一つのウィンドウから client.py を実行すれば、サーバーから挨拶が返ってくる。client.py は何度でも実行し直すことができる。
  • server.py の websockets.serve が、（第 2、3 引数で定義される websocket の）コネクションが発生する毎に、（第 １ 引数で定義される）hello コルーチンを実行する。
  • client.py の async with websockets.connect(uri) の記述によって、ブロック内のコードの実行後に、websocket 接続が自動的に閉じられるようになっている。

wss 化

  • リンクから localhost.pem をダウンロードして、サーバー＆クライアント共通の暗号鍵として使う。
  • ハローワールドに対して、server.py は、websockets.serve にオプションの引数として ssl を追加しており、その値として使う ssl_context のために 3 行の ssl に関するコードが追加されている（それに伴う import も追加されている）。
  • ハローワールドに対して、client.py も、server.py と同様に、websockets.connect にオプションの引数として ssl を追加しており、その値として使う ssl_context に関しては（同じ暗号鍵を使っているわけだから）全く同じである。

次は一旦サンプルをリフィレシュして、クライアント側を Web ブラウザーの JavaScript コードに代えてアクセスする例を紹介している。

Web ブラウザーからのアクセス

  • JavaScript 側は単にサーバーから受け取ったメッセージを ul の li として追加して表示していくだけのもの。Python 側の websockets モジュールとは直接関係がなく、JavaScript の WebSocket クラスの話なので、割愛する。
  • サーバー側（show_time.py）は、sleep を使って、一定間隔で時刻をメッセージとしてプッシュするだけの無限ループ
  • 一応このサーバー＆クライアントによって、複数のクライアント（Web ブラウザーのウィンドウやタブ）からサーバーにアクセスできることを確認するが、あくまでも、次の改良版のための叩き台に過ぎない。

メッセージのブロードキャスト（一斉配信）

  • websockets.broadcast を使って、保持している複数の websocket のセットに対して一斉配信している。
  • register というメソッドを定義して、websocket のセットを管理しているのがわかる

最後にサンプルを一新して、クライアントの一つから受け取った操作を反映して、結果を全クライアントに一斉配信するサンプルとなっている。

アプリの状態を管理する

  • JSON 形式のメッセージを送受信することで、状態を更新している。
  • 現在表示されているカウンター数と、参加ユーザー数との 2 種類の値がある。
  • クライアントの JavaScript 側では、+ - のいずれかを押すと、websocket.send を発動している。websocket.onmessage では、メッセージを受け取った際に、JSON をパースして、画面に表示している数字を書き換えているのがわかる。
  • サーバーの Python 側、counter で定義されたイベントループの最初に、websocket をセットに加えて（セットなので、重複するものは無視される）、そのセット数を参加ユーザー数として JSON 化して、ブロードキャスト。
  • + - のいずれかを押した JSON メッセージがクライアントから来た場合には、カウンター数を変更する。
  • websocket が（そのクライアントと）切断された場合は、セットから websocket を削除し、更新された参加ユーザー数をブロードキャスト。

以上が websockets 自体のちょっとしたジャブ的なクイックスタート・チュートリアル。以下からが、OpenWrt 上での websockets サーバー運用の本番となる。

Supervisor を使って OpenWrt 上のデーモンとしてサーバープログラムを動かす

まず、OpenWrt サーバーで、Python、pip が使える状態が整えられていることは前提として、websockets も supervisor も pip でインスールする：


pip install websockets
pip install supervisor

そして次のような Python コードを用意する（/www/ws/app.py）：


#!/usr/bin/env python

import asyncio
import websockets

import os
import signal

async def echo(websocket):
    async for message in websocket:
        await websocket.send(f'echo: {message}')

async def main():
    # Set the stop condition when receiving SIGTERM.
    loop = asyncio.get_running_loop()
    stop = loop.create_future()
    loop.add_signal_handler(signal.SIGTERM, stop.set_result, None)

    async with websockets.unix_serve(echo, path = f"{os.environ['SUPERVISOR_PROCESS_NAME']}.sock"):
        await stop

if __name__ == "__main__":
    asyncio.run(main())
  • 基本的にはクイックスタートで作ったような単純なエコーサーバーだが、SIGTERM でループが終了するようになっている点と reuse_port オプションを有効にしている点が新しい。
  • SIGTERM 対応は、プロセスマネージャーである Supervisor での利用を想定しているため。

次に supervisord（Supervisor daemon?）の実行オプション用の設定ファイルを用意する（/www/ws/supervisord.conf）。ただし、websockets 公式の設定例が OpenWrt 的にはイマイチよろしくない部分があったので、OpenWrt 用に最適化した：


[supervisord]
user = root

[program:websockets]
command = python /www/ws/app.py
directory = /var/run
umask = 111
numprocs = 4
process_name = %(program_name)s_%(process_num)02d
autorestart = true

公式の例ではプロセスが通常の場所のファイルとして作成されてしまうので、フラッシュストレージの OpenWrt ルーターでは好ましくない。/var/run を使って確実に、RAM が使われるようにしておきたい。ネットで情報を探したが、誰も /var/run を使うようにしている例を示しているものが存在しなかったので、自力で見出した。上のように、directory 設定との組合せで process_name が /var/run に作成されるようにしたのがポイント。

動作テストは、PC 側の CUI ウィンドウを 2 つ開いて、それぞれ SSH で OpenWrt サーバーにログインして行うなどする。

1 つ目のウィンドウで SSH して、次のコマンドで supervisord を起動する（cd /www/ws 前提）：


supervisord -c supervisord.conf -n
2023-12-04 22:13:34,534 INFO Set uid to user 0 succeeded
2023-12-04 22:13:34,671 INFO supervisord started with pid 3749
2023-12-04 22:13:35,689 INFO spawned: 'websockets_00' with pid 3750
2023-12-04 22:13:35,732 INFO spawned: 'websockets_01' with pid 3751
2023-12-04 22:13:35,797 INFO spawned: 'websockets_02' with pid 3752
2023-12-04 22:13:35,868 INFO spawned: 'websockets_03' with pid 3753
2023-12-04 22:13:36,951 INFO success: websockets_00 entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2023-12-04 22:13:36,954 INFO success: websockets_01 entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2023-12-04 22:13:36,969 INFO success: websockets_02 entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2023-12-04 22:13:36,989 INFO success: websockets_03 entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

2 つ目のウィンドウで SSH して、次のコマンドで対話モードで（同じ OpenWrt ルーターから）サーバーにアクセスする：


python -m websockets ws://localhost:8080
> hello
< echo: hello
> yes!
< echo: yes!

対話モードを強制終了してから、ls で /var/run を見てみると、狙い通りに、*.sock がここに配置されていることが確認できる：


ls -all /var/run
(...)
srw-rw-rw-    1 root     root             0 Dec  4 22:27 websockets_00.sock
srw-rw-rw-    1 root     root             0 Dec  4 22:27 websockets_01.sock
srw-rw-rw-    1 root     root             0 Dec  4 22:27 websockets_02.sock
srw-rw-rw-    1 root     root             0 Dec  4 22:27 websockets_03.sock

NGINX を使って Web からアクセスできるようにする

前述の Supervisor を使った例では、OpenWrt 上からサーバーにアクセスしてテストした。ここでは、NGINX を使って、Web から OpenWrt ルーターにアクセスして、エコー動作させるようにする。

前述の例では、/var/run/websockets_00~04.sock が UNIX ソケットとして使われたから、それを NGINX 側で設定すればよい。

/etc/nginx/init.d/websockets.conf：


server {
    listen 8080;

    location / {
        proxy_http_version 1.1;
        proxy_pass http://websocket;
        proxy_set_header Connection $http_connection;
        proxy_set_header Upgrade $http_upgrade;
    }
}

upstream websocket {
    least_conn;
    server unix:/var/run/websockets_00.sock;
    server unix:/var/run/websockets_01.sock;
    server unix:/var/run/websockets_02.sock;
    server unix:/var/run/websockets_03.sock;
}

クライアント PC 用の Python プログラム

OpenWrt ルーターの IP アドレスは 192.168.1.1 とする（send.py）：


#!/usr/bin/env python

import asyncio
import websockets

import sys

async def hello():
    async with websockets.connect(uri = 'ws://192.168.1.1:8080') as websocket:
        await websocket.send(sys.argv[1])
        message = await websocket.recv()
        print(f'send("{sys.argv[1]}") -> received("{message}")')

asyncio.run(hello())

引数をメッセージとして送るので、次のようにして使う：


./send.py hello!
send("hello!") -> received("echo: hello!")

ブート時における supervisord の自動起動設定

以上のやり方で正常に動作することが確認できたら、あとは、supervisord がブート時に自動起動されるように設定する。これは純粋に OpenWrt の話になる。

/etc/init.d/supervisord：


#!/bin/sh /etc/rc.common

START=79

USE_PROCD=1

start_service() {
	procd_open_instance
	procd_set_param command /usr/bin/supervisord -c /www/ws/supervisord.conf -n
	procd_set_param file /www/ws/supervisord.conf
	procd_set_param stdout 1
	procd_set_param stderr 1
	procd_set_param respawn
	procd_set_param pidfile /var/run/supervisord.pid
	procd_set_param term_timeout 10
	procd_close_instance
}

START=79 の 79 は、uwsgi の場合と同じにした。nginx の 80 の直前の順番になっている。

/etc/init.d のスクリプトによって、service コマンドで start/stop/restart/reload 等が可能になるが、さらに OpenWrt ブート時に自動で start されるようにするには、/etc/rc.d にシンボリックリンクを作成する必要があるが、これは enable コマンドで可能である：


/etc/init.d/supervisord enable

reboot して正常に機能しているか確認する。

LuCI のプロセス情報を見ても、狙い通りに子プロセスが 4 つ存在していることが確認できる：

さらに、wss 化する

公式チュートリアルでは説明されておらず、丸一日使って調べて、どうにか正解に辿り着いた。

  • サーバーアプリ（app.py）には変更なし。NGINX との間は unix ソケットによる OpenWrt ルーター内部での通信となるので、セキュア化の必要がないため。
  • NGINX 用の設定ファイル（/etc/nginx/init.d/websockets.conf）は SSL 用の設定に変える
  • クライアントアプリ（send.py）は wss 用に変える。

/etc/nginx/init.d/websockets.conf：


server {
    listen 8080 ssl;

    ssl_certificate     /etc/nginx/conf.d/_lan.crt;
    ssl_certificate_key /etc/nginx/conf.d/_lan.key;

    location / {
        proxy_http_version 1.1;
        proxy_pass http://websocket;
        proxy_set_header Connection $http_connection;
        proxy_set_header Upgrade $http_upgrade;
    }
}

upstream websocket {
    least_conn;
    server unix:/var/run/websockets_00.sock;
    server unix:/var/run/websockets_01.sock;
    server unix:/var/run/websockets_02.sock;
    server unix:/var/run/websockets_03.sock;
}

_lan.crt と _lan.key は、OpenWrt の LuCI 用のもの（自己署名証明書）をそのまま流用して使っている。実際に Web に公開して運用する場合には、そのドメイン用に用意した証明書とその暗号鍵を使うことになる。

クライアント側（send.py）：


#!/usr/bin/env python

import asyncio
import websockets
import ssl
import sys

async def hello():
    async with websockets.connect(uri = 'wss://192.168.1.1:8080', ssl = ssl._create_unverified_context()) as websocket:
        await websocket.send(sys.argv[1])
        message = await websocket.recv()
        print(f'send("{sys.argv[1]}") -> received("{message}")')

asyncio.run(hello())

uri の ws:// を wss:// に変更している。ssl はテスト用としては、ssl._create_unverified_context() という一種の隠しメソッドを使っているのがポイントである。サーバー側の証明書が自己署名のものなので、通常ではクライアント側で証明書エラーになってしまい、信用ができないということで、接続を拒否してしまう。今は wss プロトコルで正常に通信できるようになっているかのテストなので、証明書の正当性を検証しないために ssl._create_unverified_context() を使う。本番ではもちろん、ちゃんとした ssl_context を使うこと。

これにより、無事、wss でのセキュアーな websocket 通信が NGINX との間で確立されたことを確認できた。

ちなみに、クライアント側に JavaScript の HTML 文書を使ってアクセスする場合には、ws:// を wss:// に変更するだけである。自己証明書のせいでエラーになる場合には、そのサーバー側アドレスに対して https:// でアクセスしてみて、ブラウザーが閲覧に警告を発するのを了承して先に進むことで、その自己証明書を受諾することになるので、以後 wss:// に対するエラーが解消されるようになる。

コメント

コメントを投稿

このブログの人気の投稿

OpenWrt での Wi-Fi 設定

イメージ
OpenWrt をインストールしたら、まず最初に手を付ける作業が Wi-Fi（Network > Wireless で該当デバイスの設定を Edit）。初期状態では Wi-Fi が無効化されているため、Wi-Fi を有効化しておかないと、有線 LAN で直結していないノート PC（Macbook）から作業できない、というのが個人的には決定的な理由。 設定自体は特に難しくはなく、大まかには 2.4G 帯と 5G 帯それぞれについて、暗号化キーを決め、SSID や周波数チャンネル、出力強度をカスタムしたりする程度。最後に Enable して Save & Apply する流れとなる。 以下では、最初に、作業用の古いノート PC（Linux）から有線 LAN でルーターに接続して設定を行い、5G 帯をアクセスポイント・モードで有効化し、Wi-Fi 経由で MacBook が接続できるようにしてから、（Linux マシンと LAN ケーブルを片付けて）残りの作業を行っている。 5G 帯のアクセスポイント設定 WZR-HP-AG300H の場合では radio1 が 5G 帯（802.11an）となっているので、この Wireless 設定を Edit する。 Device 設定（Advanced Settings） 上半分の Device 設定についてはまず Advanced Settings タブの国設定で「JP - Japan」を選ぶ。 Interface 設定（基本設定） 下半分の Interface 設定については上のスクリーンショットのように Mode を「Access Point」、ESSID を適当に設定する（ここでは「OpenWrt」としている）。 Device 設定（基本設定） 国設定を選んだので、基本設定のタブに戻る（下のスクリーンショット）。 チャンネルは auto にすると、PC（受信端末）側のアクセス可能範囲外のチャンネルが選ばれてしまう場合があるので、確実に接続できるであろうチャンネルを手動で選んでおいた方が無難だろう。出力パワーは最強にしておいた。帯域幅はデフォルトの 20 MHz 幅のまま（40 MHz にすると倍化するが、その分、他の Wi-Fi との干渉もし易くなるため）。 ...
続きを読む

シークエンスパパとも 本物の霊能力

イメージ
Ms Sarah Welch / CC-BY-SA-3.0 シークエンスはやともを知ったきっかけ TV を見ない僕がシークエンスはやとも（YouTuber。吉本興業所属）の存在を知ったのは、今年の春（3 月か 4 月）の頃だったと思うが、YouTube でふと宜保愛子の動画を探していて、彼が宜保愛子を称賛するものを見つけて以来だったと思う。 それ以来いくつかの彼の動画をちょくちょく観るようになって、彼の霊能力が父親（シークエンスパパとも）譲りであり、パパともも息子のはやともに勧められて（癌闘病の傍ら）YouTuber として活躍していたのだが、残念ながら今年 1 月末に逝去していた、ということなどを知るようになった。 シークエンスパパともを知ったきっかけ はやとも流れでパパともの動画を観るきっかけになったのは、画面脇のお勧めに出ていた親子対談の動画を見たのが切っ掛けだった。 そこでのパパともの宮本武蔵に関するコメント（「晩年の宮本武蔵は一生懸命仏像を彫ったりしていたが、（若い頃）子供の道場主を殺したりしていたことによる怨霊は除霊できなかった」）に少しシビれた。息子のはやともが、まだ若いせいもあって、ちょっと話がマクロな（思想論や社会論的な）方向に行くと、厨二病的な傾向があるのには食傷気味な感じがあった。一方で、パパともの宗教・倫理観的な考えの方がその点、人間的な深さを感じるものがあったので、それがパパともに興味を引かれたきっかけだった。 パパともの霊能力に衝撃を受けた理由 そこで、初めて、パパとものチャンネルの動画もいくつか観たりしたのだが、「未解決事件を霊視する」という中々に攻めた企画を初期にやっていて興味深かったのだが、中に、上野の不忍池での事件（僕自身はこの 2006 年の事件については知らなかった）を扱ったものがあった： 「あっ！」と思ったのが、奇しくも前日（2023-06-28）、全く別のチャンネルの別の動画で、霊媒師が同じ事件を霊視するという企画のものを観ていたのだった： 千原せいじの YouTube チャンネルで、彼がコラボをしている飯島唯という通称・ギャル霊媒師の方が霊視をしている。 パパともの動画は 2021-05-12 と 2021-05-15 に公開されたものであるのに対し、ギ...
続きを読む

和歌山（？）の女性宮司の霊能力者を特定した

イメージ
昨夜、ニンゲンTVに登場した和歌山（？）の女性宮司の霊能力者の後編が公開された。滅茶苦茶気になったので、全力で我が特定力（？）を駆使したが、今ようやく特定できた。疲れた…… orz 前編を観た段階で、原田龍二が浮遊霊にいつの間にか憑かれていたことが発覚。『神島編』以来の肩の不調の原因だったようだが、だとしたら降魔師・阿部吉宏の立場は……。 まあ、数日前、僕は阿部さんは意外と「討ち漏らし」はあるんじゃないかという説を「 ニンゲンTVのヤバい心霊映像で気分が悪くなった……（その 2） 」という記事でも述べたりしていたので、霊能力者としては「感知能力が戦闘能力よりも劣る」タイプなのかなとは思っていた。 原田のヨイショと、天野ディレクターの良くも悪くも優秀な演出・編集によって、阿部さんが完全無敵の守護神（いわばオリヴァー・カーン）のように扱われているが、世には霊能者は他にも存在し、その中で阿部さんが完全無欠なのかというとそういうわけでないと思うし、本人も結構、そのあたりは謙虚な発言をしている。だが、ニンゲンTVの番組の演出上、これまで阿部さんを他の霊能者と比較するような場面がなく、ただ、非能力者である他のメンバーから唯一絶対的な能力者存在として扱われてしまっていただけだ。 阿部さん加入前に、ニンゲンTVがコラボをしていた凄腕霊能者の山口彩さんが好例だが、阿部さんが自身で謙虚に述べているように「 上には上がいる 」というのが本当のところだと思う。ただ、そういったプロ中のプロとして活躍中の霊能者の人たちだと、廃村・廃墟といった心霊スポット巡りの撮影に参加してくれるようなフィジカル的にもタフな人材は（阿部さんを除いて他に）見つけることは難しいように思われる。 原田の亡き祖母との再会の仕方に関する回答や、霊的な世界に関する見解など、この宮司は、（一霊四魂や言霊など）神道寄りながら、かなり良い指摘の仕方をする方だったと思う。神道なのに、最後は仏教的な輪廻転生観に基いて語っていたのも印象的だった。
続きを読む