ししおどし

このブログ記事を最初にまとめた当時（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 レコードは今回の趣旨とは全く関係がないオマケで、無関係の他者が勝手にこのドメイン名を使った証明書を作成することを防ぐためのものである。 NGINX acme.sh を使

（👉 公式ドキュメント ） 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 の WebSo

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'],

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

（👉 公式ドキュメント ） ビルドシステム 👉 基本 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

Google でニンゲンTVのこと（スタッフのプロフィール等）を調べようとすると、まず出てくるのが Weblio辞書の項目 だが、これは Wikipedia の原田龍二の項目 のうちの ニンゲンTVの副項目 の丸パクリである。おそらく、転載元の Wikipedia では原田龍二に関するページの副項目であるがために、「ニンゲンTV」というキーワードで Google 検索をした場合、ニンゲンTVのみで独立した項目として載っているWeblio辞書が優先して検索結果として表示されてしまっているのだろう。 ともかく、ニンゲンTVに関するまとまった客観的情報としては、Wikipedia の原田龍二の項目のうちの ニンゲンTVの副項目 が、本家本元だということを抑えておきたい。 阿部さんに関する記述が削除されている 今回（2023-11-23）、ふと降魔師の阿部吉宏のプロフィールを読み返したくなり、この Wikipedia 情報にアクセスしたが、例の 新加入した 3 人の女性準レギュラー の記述が加わっている一方で、阿部さんの項目が消えていた。これは一体どういうことだ……？ 編集履歴を調べてみると、 2023-11-11 23:42 と同 23:47 に、匿名ユーザー（IP: 2001:268:c241:6de0:2070:8a5e:ceae:684 ）によって阿部さんの記述がごっそりと削除されているのがわかる。 この時はすぐ（17 分後の 2023-11-12 00:04）に別のユーザーが復元したが、1 日後（2023−11−13 00:13）、 一刀斎を名乗るユーザー に再度削除される。 「一刀斎」というのは、阿部さんの抜刀道家としての武名である。この Wikipedia の原田龍二の項目の副項目としてのニンゲンTVの中のメンバーとしての阿部吉宏のプロフィールを削除したのが、阿部さん自身なのか、それとも、阿部さんを騙る別人によるものなのか、どちらなのかは不明である。しかし、これ以来、現在（2023-11-23）に至るまで、削除された項目を復元しようとするユーザーが現れておらず、「阿部吉宏」に関する記述は Wikipedia 上から失われたままである。 これが、阿部さん自身による場合と、赤の他人の騙りによる場合では、解釈が全く正反対になってくるだ

僕のニンゲンTV視聴に関する経緯と立ち位置 座敷童（みやこ）に関するエピソードからニンゲンTVの YouTube チャンネルに足を踏み入れた オカルト的な興味から心霊系の動画を観るようになったので、オカルトというよりは（口先でどのように綺麗事を言おうが）実際のところ単なる若者の不謹慎な 100% 興味本位の肝試し系のノリでしかない心霊スポット探索系の YouTuber は元々忌避していたので、ニンゲン TV の心霊スポット探索動画にしても見向きもしないで放置していたが、降魔師の阿部吉宏の物語に興味を惹かれるあまり、YouTube のお勧めに表示されるニンゲンTVの心霊スポット探索系動画もちょこちょこ観るようになった。 そうやって間も無く〝ニンゲンTV沼〟にハマり、こうなったからには、ニンゲンTVの過去の動画を全て観るしかないと思うようになった。心霊系に方向転換した時期以降のニンゲンTVの再生リストを過去から順を追って視聴中。阿部の加入前の時期の霊能者・山口彩さんの再生リストに衝撃を受け、現在、山形（2 度目）のシリーズに入ったばかり。 原田龍二の書いた小説『精霊たちのブルース』も先日、読了した。 女性の準レギュラーメンバーを加入させた件 については批判的 阿部は観察する対象、原田は視点を共有する対象として応援している 天野ディレクターにはもっと、地上波テレビ的ではない YouTube 的なやり方を勉強して頑張って欲しい。原田・阿部を中心とする人間ドラマを演出するのは上手いと思うが、それ以外の演出がまだまだ YouTube の心霊系チャンネル向きのものではないと思う。いかんせん失敗を恐れず躊躇しないで新しい試みを続けて欲しい。 山形（2 度目）の最初のロケ地である廃ラブホテル 今回取り上げるニンゲンTVの動画はこれである： 巨大な顔 この廃ラブホテルは当初の予定になかったロケ地らしく、現地でスタッフが情報を仕入れて急遽行くことに決めたようだ。そのため、一番目に訪れたようで、ロケ地の〝ヤバさ具合〟は未知数なので考慮に入れられていなかった模様。 阿部が外から見えている窓や車の中などあちこちに霊体がいると指摘しているが、当然僕も原田龍二サイドの基本的には〝視えない〟側の人間。何もよくわからない。ただ、

今日（2023-11-19）、ニンゲンTVの心霊スポット探索動画の一つを観ていて、少々気分が悪くなってきた……orz 詳細をブログにまとめるためには、説明のためにスクリーンキャプチャーした画像を提示する必要があるのだが、画像を編集する作業をするとまたぶり返してくるので、今晩はちょっと無理な感じ。日を変えて日中に作業するのがいいと思う。 一応、動画の概要欄には（おそらく降魔師の阿部吉宏による）「お祓い済み」であると書かれてはいる。 だが、いくら阿部さんだからといって、万能の御祓いが可能なわけはない。どんな人（例えば心理的に敏感な人）が観ても、何ら霊障が起らない御祓いの仕方などあるわけがない。例えば、怪談ばかりに触れていると、その人のその心の波動に合わせて、浮遊霊が寄ってくるというような考え方があるが、御祓いした動画を観た人が、その視聴行為によって、間接的にそういった霊的な方向に心のチャンネルを合わせてしまうようなことをも含めて、「御祓いをしたからにはどんな場合でも霊的に安全である」などという保証は、論理的に成り立たないだろう。 本来、心霊動画に対する御祓いの効果は、あくまでも直接、その心霊動画に映り込んでいる心霊本体とアクセスしてしまうことを防ぐものであって、その動画を観ることによる視聴者側の間接的な心の変化による影響までも保証しうるものではないはずだ（もしそんなことができるとしたら神レベルの力と言う他ない）。 その動画の中で、モロに心霊が映像として映り込んでいるシーンを 2 箇所見つけた。視聴中のある時点（1 箇所目の心霊を見つけた場所のあたり）で頭が痛くなり、また、後になって先程、2 箇所目に見つけた心霊のスクリーンキャプチャー画像を編集しようとしてその心霊をまじまじと見ていたら、気分が悪くなってきた。 さらには阿部さんも、動画の中で「ここは穢れが酷い」と言っていた。穢れだから、心霊とは違うので、御祓いの効果で心霊からの霊障は防げても、穢れが映像を通じて漏れ出すのは防げないのかもしれない。もちろん、阿部さんは対穢れ用の真言を唱えてはいたから、御祓いにあたっては、そういった真言を用いて行っている可能性はある。 しかし、視聴後になって検証のためコメント欄に全て目を通してみると、気分が悪くなったと訴えるコメントが多数あったので、僕だけではないことは確実だ。

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.1

（公式ガイド：👉 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 未