投稿

ラベル(OpenWrt)が付いた投稿を表示しています

OpenWrt で Let's Encrypt (with acme.sh)

イメージ
このブログ記事を最初にまとめた当時(2020-11-11)には気付かなかったが、現在(2023-12-06)ではいつの間にか、OpenWrt のパッケージモジュールとして acme が用意されており、さらには LuCI から使うための luci-app-acme までも存在している。以前の僕はこれらの OpenWrt パッケージについて知らなかったので、acme.sh の 公式サイト の説明に従って一般的な Linux マシンとしてインストールし、コマンドを実行して使用してと、愚直に自力の作業をしていたものである。今では OpenWrt の acme.sh についての 公式の説明 も存在するので、それに従って作業すれば、ほとんど苦もなく完了できる。 だが、acme.sh の実行による Let's Encrypt からの証明書の発行が半自動化されたとはいえ、DNS や NGINX などと連携させる必要があり、総合的な話としては一定の知識を要するので、ここにまとめておきたいと思う。 Web ルートの準備 acme.sh では証明書の発行時の身元確認の方式として、Web ルートに .well-known/acme-challenge という一時的な隠しフォルダを作成し、そこにユニークな文字列からなるファイル名を持ったファイルを設置して、インターネット側から http://(ドメイン名)/.well-known/acme-challenge/(ファイル名)にアクセスできるかどうかで、確認するという形になっている。 このため、いきなり、acme を使うのではなくて、先に DNS 側でドメインが OpenWrt ルーターの IP を指し示すように設定しておき、さらに OpenWrt ルーター側では、NGINX の設定で、そのドメイン名での http アクセスが /www 以下に対応付けられるようにしておかなければならない。 DNS の設定 A レコードでデフォルトドメインがルーターの IP アドレスを指し示すように設定している他、CNAME で www がデフォルトドメインの別名であるようにしている。CAA レコードは今回の趣旨とは全く関係がないオマケで、無関係の他者が勝手にこのドメイン名を使った証明書を作成することを防ぐためのものである( 参考 )

OpenWrt で uWSGI 環境を整える

イメージ
OpenWrt(23.05)に Web サーバーとして NGINX(SSL 版)を利用し、 uWSGI ミューウィズジー をアプリケーションサーバーとして連携する方法について記す。 前提状況:USB フラッシュドライブ WWW 用のデータを置く場所として USB フラッシュの外部ドライブを用意(👉 OpenWrt での USB フラッシュドライブ )し、さらに Extroot 化(👉 OpenWrt のストレージを Extroot 化する )していることを前提としている。 LuCI もろとも Web サーバー(HTTPd)を SSL 対応 NGINX 化する 以前の OpenWrt 18.x とは飛躍的に進歩して、19.07 以降では SSL 対応版の NGINX が opkg として用意されている(以前は SSL 対応にするためには自前で Linux ソースコードからモジュールをビルドする必要があった)のみならず、NGINX 版 LuCI がセットアップされている opkg すら用意されており、OpenWrt コミュニティの旺盛な活動を感じる(👉 LuCI on other web servers > LuCI on nginx )。 opkg update opkg install luci-ssl-nginx opkg remove luci-ssl luci reboot デフォルトでインストールされている LuCI/uHTTPd の方は不要になるのでアンインストールした。 OpenWrt ルーターで websocket サーバーを運用したいと思ったので、その下準備として、アプリケーションサーバーを整えておく必要がある。Python 系のアプリケーションサーバーとしては uWSGI が定番であり、最近のバージョンでは websocket にもデフォルトで対応しているようなので、まずここでは uWSGI 環境の構築について一通り行いたいと思う。 luci-ssl-nginx luci-ssl-nginx を導入するとデフォルトの uHTTPd 環境の LuCI に代えて、NGINX(かつ SSL)環境の LuCI が動くようになる。この環境において、Lua プログラムである LuCI に NGINX

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

イメージ
(👉 公式ドキュメント ) Quick start (ローカル PC でのテスト。OpenWrt とは無関係な websockets 自体の話) ハローワールド CUI ウィンドウを 2 つ開いて、server.py を実行すると、無限ループで強制終了するまで動き続ける。もう一つのウィンドウから client.py を実行すれば、サーバーから挨拶が返ってくる。client.py は何度でも実行し直すことができる。 server.py の websockets.serve が、(第 2、3 引数で定義される websocket の)コネクションが発生する毎に、(第 1 引数で定義される)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 の WebS

OpenWrt の uWSGI での websocket は諦めた

イメージ
websocket サーバを運用するために OpenWrt(v23.05.2)の uWSGI をあれこれと強引にカスタムしてみたが、結局、諦めざるをえなかった……。 自分の力量不足だっただけかもしれないし、今後のバージョンアップによる情勢の変化もあるかもしれないので、参考までに何を試して駄目だったのかを記録のために記しておくことにする。 OpenWrt の uWSGI パッケージは SSL 非対応なので websocket が不可 最近の uWSGI 自体は、デフォルトで websocket 対応している(“ The uWSGI websockets implementation is compiled in by default. ”)ようなのだが、OpenWrt で用意された uWSGI のバイナリーイメージは、websocket 非対応でコンパイルされている。この StackOverFlow の回答 にもあるように、OpenWrt 上では uwsgi コマンドの help 表示のオプション一覧に、https 関係のオプションが表示されないので、https 対応状態でコンパイルされていないことが確認できる。 uwsgi --help | grep https websocket プロトコルの規格では、非セキュア通信(ws://)の場合でも、ハンドシェイク確立時にはセキュア通信(https://)を必須としているので、https 対応状態でコンパイルされていることが必要となる。実際に、上述の uWSGI の公式ドキュメントのテスト用のシンプルな エコーサーバーの WSGI プログラム を実行してみると、uWSGI のログに次のようなエラーが記録されていた: you need to build uWSGI with SSL support to use the websocket handshake api function !!! Traceback (most recent call last): File "echo.wsgi", line 5, in application uwsgi.websocket_handshake(env['HTTP_SEC_WEBSOCKET_KEY'],

OpenWrt ビルドシステムに関するメモ

イメージ
(👉 公式ドキュメント ) ビルドシステム 👉 基本 SSD/HDD の容量は 10~15GB 以上必要。 仕組みとして大きく分けると 3 段構成になっている: ホスト(実際に作業する PC)側用のツールチェイン ターゲット(OpenWrt をインストールするルーター)側用のツールチェイン パッケージ化したりファームウェアのイメージ化する ツールチェインがホスト側・ターゲット側の 2 段構成になっている理由は、クロスコンパイルを可能にするため。まず、ホスト側ツールチェインを使って、ターゲット側 OpenWrt 用のツールチェインをビルドする。そうやって生み出されたターゲット側 OpenWrt 用のツールチェインを使って、実際に OpenWrt で使われるバイナリーイメージをビルドする(つまり、ホスト側のツールチェインは、単に、OpenWrt 用のツールチェインをビルドするためだけに使う。そして実際の OpenWrt の各パッケージは、ターゲット側 OpenWrt 用のツールチェインによってビルドしていく。このようにして一種の〝ビルド環境のエミュレーション〟のような仕組みとなっている)。 そうして、第 3 段階で、ビルド済みの各パッケージを .ipk の形にしたり、ファームウェアイメージにしたりして、ルーターにインストールするという流れ。 👉 セットアップ方法 GNU/Linux が標準の環境。基本は Git が使えるようにして、その他は、ツールチェインのビルドに必要な C コンパイラの環境を整えればよい。Debian / Ubuntu 系では apt を使って、build-essential clang flex bison g++ gawk gcc-multilib g++-multilib gettext git libncurses-dev libssl-dev python3-distutils rsync unzip zlib1g-dev file wget あたりを用意すればよい。 👉 セットアップ方法(macOS) macOS は本来、非推奨。敢えて使いたいマニア向けの解説。 👉 セットアップ方法(WSL) Windows

OpenWrt on WZR-HP-AG300H: Python

イメージ
32MB フラッシュの WZR-HP-AG300H では、Python のフルパッケージ(python3)も問題なくインストールできた。 ただ、結局のところ、フルパッケージは「python3-light + 他の全ての追加パッケージ」に過ぎないので、必要になったら都度該当する追加パッケージを入れればいいだけだと思い、python3-light で入れ直した。 python3 後日、結局、 Extroot 化 でフラッシュ容量を気にする必要がなくなったので、何も気にせずにフルパッケージ(python3)を入れた: opkg update opkg install python3 OpenWrt 23.05.2 での Python のバージョン: python -V Python 3.11.6 python3-pip フルパッケージとはいえ、pip は含まれていないので、さらに python3-pip もインストールする: opkg install python3-pip OpenWrt 22.05.2 での pip のバージョン: pip -V pip 23.2.1 from /usr/lib/python3.11/site-packages/pip (python 3.11) pip 自体の更新: pip install --upgrade pip Requirement already satisfied: pip in /usr/lib/python3.11/site-packages (23.2.1) Collecting pip Obtaining dependency information for pip from https://files.pythonhosted.org/packages/47/6a/453160888fab7c6a432a6e25f8afe6256d0d9f2cbd25971021da6491d899/pip-23.3.1-py3-none-any.whl.metadata Downloading pip-23.3.1-py3-none-any.whl.metadata (3.5 kB) Downloading pip-23.3.1-py3-none-any.whl (2.

OpenWrt のストレージを Extroot 化する

イメージ
(公式ガイド:👉 Extroot configuration ) 今、例として使用している Buffalo WZR-HP-AG300H は、フラッシュストレージのサイズが 32MB であり、Python や gcc などの開発ツールを使おうとするとすぐに容量不足でアプリがインストールできなくなってくる。また、後に判明したことだが、RAM 容量は 128MB で OpenWrt の文書では特に少ないと扱われてはいないものの、pip で Python のモジュールをインストールする処理の中で gcc でのコンパイル作業を伴うような大掛かりな処理が発生すると、128MB では不足して OpenWrt 自体が落ちて(リブートして)しまったことがあるので、Swap メモリーも必要になる。 まず、フラッシュストレージのサイズは、外部 USB ストレージを使い(参考: OpenWrt で外部 USB ストレージを使う )、Extroot 化することで限界を突破できる。そして Swap メモリーについては、Extroot 化したのち、Swap ファイルによって行えばよい。 原理 OpenWrt のファイルシステムは、overlay ファイルシステムという方式が採られている( 参考 )。パーティションが内部的には rootfs (/rom, compressed, not writable) rootfs_data (/overlay, uncompressed, writable) から構成されており、論理的には overlay (/, 未修正のファイルは compressed, writable) システム内に存在する各ファイルを扱うようになっている。 Extroot の場合、上のような元々の overlay パーティションとは別に、もう一つの overlay パーティションを外部ストレージに用意して使う形にする。Extroot 化前の元々の overlay パーティションにあった内容を全部コピーして使うことで、緊急時には Extroot 化前の状態に戻してフォールバックできる余地を残すためである。 必要なツール等の準備等 公式ガイドによると、ツールのインストールに一定の容量が必要なので、フラッシュ容量が 8MB 未

OpenWrt で外部 USB ストレージを使う

イメージ
(公式ガイド:👉 Using storage devices ) 外部 USB ストレージ用のドライバーのインストール opkg update opkg install kmod-usb-storage opkg install usbutils ドライバーは kmod-usb-storage のみ usbutils はコマンド lsusb -t を使って USB メモリーが接続されているかどうかを調べるためのもの(オプショナル) lsusb -t /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/2p, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/2p, 480M |__ Port 1: Dev 2, If 0, Class=, Driver=usb-storage, 480M 「Port 1: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 480M」の行が表示されていることにより、外部 USB ストレージ(USB メモリースティック)が挿されているのが確認できる。 外部ドライブとして認識されていることの確認 lsusb コマンドによる確認は、USB デバイスが認識されているかどうかのものである。最終的に、OpenWrt の Linux OS 側が、外部ドライブとして認識しているかどうかは、/dev/sd* としてアタッチされているかで確認できる: ls -l /dev/sd* brw------- 1 root root 8, 0 Nov 16 16:42 /dev/sda brw------- 1 root root 8, 1 Nov 16 16:42 /dev/sda1 今回の例では、/dev/sda が存在することにより、認識されていることが確認できていることになる。 外部ドライブのパーティションが適切に認識されているかの確認 上で外部ドライブが認識されていることが確認できたが、さらに、/dev/sda の論理