ししおどし

Mac を初期化して別の Mac から乗り換えた。同じ Mac で macOS を一旦初期化して再構築する場合でも同じ。今後もこういう機会はあるはずなので、初期化時と初期化後の一通りのセットアップ手順をまとめて記しておく。 Macintosh HD の初期化・再インストール Mac を売却、譲渡、下取りに出す前にやっておくべきこと ：iCloud・iMessage からサインアウト 「この Mac を探す」を元々有効にしていると、アクチベーション・ロックがかけられた状態になっているので、macOS のインストール時に、元の AppleID のパスワードの入力が求められるようだ。先に、iCloud にログインして、デバイスを AppleID の登録から削除しておけば、回避できるものと思われる（未確認）。 ディスクユーティリティを使って Mac を消去する （ Apple シリコン搭載の Mac の場合 ）: フォーマットは APFS で、大文字小文字を区別する・しないについては、ユーザーによって使い分ける。一般ユーザーは「区別しない」で、アプリ開発者である自分は「区別する」で。暗号化は（フォーマットをする）この時点では行わない方が良い。macOS のインストール・セットアップ後の設定時に後から FileVault を有効化するのが無難。 NVRAM リセット：起動時 option (⌥) + command (⌘) + P + R を 20 秒 macOS を再インストールする方法 ：Intel Mac では「command (⌘) + R」で「macOS 復旧モード」で起動し、「macOS を再インストール」によって消去されたディスクにクリーンインストールできる。 以下は、各アプリのバックアップ・リストア作業について AquaSKK SKK に慣れてしまうと、他の入力方法が不快でたまらなくなってしまう。セットアップ作業においても文字入力の必要性が発生するので、できるだけ初期化後の早い段階でインストール・セットアップを済ませておきたい。 自前の辞書ファイル ~/.skk-jisyo は ~/ にあるので、~/ 丸ごとバックアップしていれば問題はない。 Mousecape AquaSKK ほどの切迫性はな...

macOS において、yt-dlp で、Safari の cookie を使う方法。 コマンド： yt-dlp [URL] --cookies-from-browser safari 次のようなエラーが出る場合： ERROR: [Errno 1] Operation not permitted: '/Users/XXX/Library/Containers/com.apple.Safari/Data/Library/Cookies/Cookies.binarycookies' 解決方法：システム設定でターミナルのフルディスクアクセスを許可する 参考： https://github.com/yt-dlp/yt-dlp/issues/7392

e-Tax（with マイナンバーカード + IC カードリーダー）を macOS Big Sur で使おうとして、最後の最後の段階の、データを国税庁に送信する段階になって「このアプリは作成コーナーの画面内でご利用いただくものです。直接クリックして起動することはできません」というエラーに陥った。 macOS で、それも Big Sur に早々と更新するような勢で、さらにマイナンバーカードを IC カードリーダーを使って確定申告しようというような酔狂者は少ないのか、検索してもあまり事例を見付けることができない。辛うじて Twitter には このような国税庁の Mac 対応不足を指摘するものを発見したのみ。 上記ツイートにより、このエラーが自分だけではないことがわかったのはいいのだが、実は、この「Mac 対応不足 → Windows なら ok」という認識は誤っていて、むしろ余計に皆が Windows に逃げようとする流れを是認・助長してしまっている。実際のところ、全然、Mac でも ok（後述）。決して e-Tax ヘルプデスクに「ゴルァ電」して、混雑に拍車をかけないように。 旧バージョンの e-Tax をアンインストールしろ！ この重要なポイントが、なぜか、e-Tax のホームページで見つけられず（つまりググっても辿り着けない）、インストール時の jizenMac.dmg（仮想ディスクイメージ）の中の「インストールマニュアル.pdf」の説明の一部として「旧バージョンの e-Tax をアンインストールしろ」と書かれている。 これをやらないと、e-Tax の開始時では「正常にセットアップされています」と認識されているのに、最後の最後の国税庁にデータを送信する段階で「直接クリックして起動することはできません」エラーに陥いる。 ほとんど罠のような話。これでは「Mac 対応不足 → Windows なら ok」という認識を皆が抱いても仕方がないのかもしれない……。 ともかく、macOS Ventura とマイナンバーカードと IC カードリーダー（ ACR1251DI-NTTCom ）で今年（2024）も e-Tax はできている。Mac ユーザーの皆様には、めげずに貫き通して欲しい。

そろそろ確定申告の時期を迎えて、e-Tax に関して、 M1 Mac の IC カードリーダーの対応が鬼門だ と国税庁が注意を喚起した件について、あちこちで記事になっている（2021 年当時の話）。 自分は M1 Mac ではないのだが、そもそも Big Sur にアップデートしてしまったので、その影響もあるのかどうか、既にアップデートしてしまってから気になってきた。 Mac で e-Tax を安心してできるようにと、わざわざ NTT コミュニケーションズのフラッグシップモデルである ACR1251DI-NTTCom を入手したくらいなので、それが迂闊な OS アップデートで差し障りが生じてしまうというのはちょっと残念過ぎる。JPKI（公的個人認証サービス）によると Big Sur はサポート対象外 である。不安が煽られる。 早速、ACR1251DI-NTTCom を MacBook に接続し、JPKI の利用者クライアントソフトを立ち上げてみた。 問題なく立ち上がる。動作チェックをしてみる。 動作チェックも無事終了する。念のため、マイナンバーカードの電子証明書を読み取らせてみたが、正常に機能した。 M1 Mac はともかく、どうやら Big Sur については（ACR1251DI-NTTCom に関する限り）問題ないようだ。 更新：macOS Ventura 2024 年 3 月の時点で、2023 年度分確定申告を e-Tax（マイナポータル経由）によって行ったが、ACR1251DI-NTTCom は少なくとも、自分の Intel-Mac（Macbook Pro 2017）では無事使えている。

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

各種 UNIX 系ツールのインストール・管理は MacPorts を使っているが、MacPorts でインストールした Python の tkinter を使おうとしたところ、XQuarz 経由で Tk が動く形となり、日本語入力が使えずに、コピー＆ペーストしながら入力して、かなり不便なのを我慢していた。 どうにかならないものかと改めて情報を探ってみたが、X11 を使わずに Quarz を使うなどという 10 年前の情報が出るだけで、既に XQuarz が使われている自分の場合にはこれ以上手の施しようがないと思い込んでいた。 ──が、これが単なる、しかし致命的な勘違いで、Quartz と XQuartz では別物というか、XQuartz は、Quartz をワザワザ X11 互換モードで動かしているものらしく、要するに X11 のことである。だから Quartz をちゃんと Quartz として動かす必要があった。たったそれだけ、それだけだが致命的な勘違いだったというわだ。 「 macOS の matplotlib (MacPorts) で X11 を要求される問題を回避する 」というブログ記事の通りにして、無事に Quartz で tkinter を動かすことができた。記事自体は matplotlib に関するものだが、tkinter の場合も MacPorts 経由でインストールされた Tk を使うので、tk +x11 → tk +quartz に切り替えればよいというのは同じである。 MacPorts の tk は デフォルトで X11 を使用する ことになっていたので、 -x11 +quartz を付けてインストールし直せばよい(+x11 と +quartz は conflict するので同時に設定できない)。 sudo port install tk -x11 +quartz お蔭様で、無事、日本語入力もできるようになった。

実家の au ひかり用の HGW を Aterm BL902HW から HGW-BL1500HM に更新した。条件（メッシュ Wi-Fi の有料オプション（おうちどこでも WiFi）への申し込みとの抱き合わせ）付きだが、キャンペーンで今なら手数料無料で更新できたからだ（有料オプションは、料金が発生する前に速攻で解約する予定）。 両者の違い： Wi-Fi が ax/ac 対応になった（BL902HW では an まで） NEC（日本）製から Askey（台湾）製になった VDSL モデム一体型から分離型になった 両者の共通点： 有線の WAN/LAN は 1Gbps でギガビットイーサなのは同じ 有料オプションの Wi-Fi は使っていなかったし、今後も使う予定はないので、かなりどうでもいい話（だが、au 側としてはそこが理由で今回のキャンペーンを行ったのだろうけど）。 NEC（日本）製から Askey（台湾）製になったことについては、ファイヤーウォールの初期設定（👉 au ひかり用の HGW のファイアーウォールの初期設定 ）など、特に変った点は見られず、この辺りの一貫性はメーカー側よりは au 側にイニシアティブがあるのだろう。ただ、設定項目としては同じでも、かなり画面の外観が変っていて、レイアウトが無駄に大きく（NEC の時は 1 次元的に縦に長いレイアウトだったが、Askey では 2 次元的で横に段組されていて今さら古い時代のホームページみたいなセンス）、行きたい画面に辿り着くまでステップ数が無駄に多い印象。 Wi-Fi は使わないし、かといって使う方の有線の WAN/LAN は前の BL902HW と同じなのに、なぜ、わざわざ更新しようと思ったのか？　それはまあ、Wi-Fi が高速化された分、スループット（CPU の処理速度も含めた総合的な性能）がより高速になっているであろうことが期待できるからである。 実は段違い？ マンションタイプの VDSL なので、そこがボトルネックにはなってしまうのだが、実は、BL902HW の場合と BL1500HM で大きく違っている部分があり、それは、VDSL モデムと HGW 間の接続が、100Base-TX から 1000Base-T に上がった点である。...

au ひかり用の HGW である HGW-BL1500HM について、初期状態でのファイアーウォールの設定について調べてみた（ちなみに、前世代の Aterm BL902HW についても設定内容は同じである）。 WAN 側インターフェース 種別 方向 プロトコル 送信元 送信元ポート 宛先 宛先ポート 優先度 廃棄 out UDP any any any 137-139 1 廃棄 out TCP any any any 137-139 2 廃棄 out UDP any any any 445 3 廃棄 out TCP any any any 445 4 廃棄 out TCP any any any 2049 5 廃棄 out UDP any any any 2049 6 廃棄 out TCP any any any 1243 7 廃棄 out TCP any any any 12345 8 廃棄 out TCP any any any 27374 9 廃棄 out TCP any any any 31785 10 廃棄 out UDP any any any 31789 11 廃棄 out UDP any any any 31791 12 廃棄 in TCP any any any 1243 13 廃棄 in TCP any any any 12345 14 廃棄 in TCP any any any 27374 15 廃棄 in TCP any any any 31785 16 廃棄 in UDP any any any 31789 17 廃棄 in UDP any any any 31791 18 一見複雑なようだが、全て廃棄するルールで、送信元ポートは全て any であり、重複してエントリーされているものがあるので、宛先ポート毎にまとめて考えれば、かなり単純だと思う。独自に宛先ポート毎の表にしてみた： WAN 側インターフェース 宛先ポート 方向 プロトコル 備考 137-139 out TCP/UDP NetBIOS over TCP/IP (Windows) 445 out TCP/UDP Direct Hosting of SMB (Windows) 2049 out...

OpenWrt サーバーで運用している NGINX で SSI を試しに使ったみた感じのメモ。 Apache と違って、NGINX では SSI のサポートは消極的・限定的。何年も前から状況が変わらないので、開発中というわけではないだろう。静的コンテンツに特化した NGINX の特性や開発ポリシー的なものと思われる。また、動的コンテンツを使いたいのであれば、サーバーサイドなら PHP、フロントエンドなら JavaScript という世の中の確立された相場もあるので、「今さら SSI」という感じでもあるだろう。 NGINX の設定 SSI は一々、NGINX で HTML の内容をパースするため、NGINX のパフォーマンスに影響が大きいので、無差別に SSI をオンにしないように、NGINX の conf の location で対象を絞った方がいいと思う。例えば、index.html にどうしてもアクセスカウンターを SSI で表示させたいと思っているとしたら、次のようにする： location /index.html { ssi on; ssi_types text/plain; # デフォルトの text/html に加えて、text/plain も扱う場合 root /www } 前述のように、NGINX の SSI は、静的なファイルのインクルードか、CGI からの出力をインクルードする程度のものしか対応する気がないようである。CGI からの出力を HTML ファイルの中に埋め込んで表示する場合は、include virtual コマンドを使う： 引数を与えたい場合 ここで、アプリケーション・サーバーとしては uWSGI を使っている（👉 OpenWrt で uWSGI 環境を整える ）。 CGI の場合 uWSGI の CGI モードで動かしている Python プログラムの場合、「?」の後の QUERY_STRING を「+」を 区切り文字 デリミター として使い、各 key=value のペアは urlencode して「=」は %3D となっているものを使う必要があった。 このようにすることで、uWSGI の CGI プラグインは、最初のペア（key1=value1）を sys.ar...

macOS 用の FTP クライアントは他にもいくつかあるようだが、Linux でも共通して使えるので、 FileZilla にした。 Linux から macOS への設定データの移行は、Linux 側からエクスポートした FileZilla.xml を Mac 側の FileZilla でインポートするだけ。 .DS_Store を無視する .DS_Store を無視するためには、表示 > ディレクトリ リストのフィルタリングを開いて、フィルター ルールの編集を開き、Useless Explorer files の設定に .DS_Store を追加するとよい。 設定を追加したら、元の画面に戻って、左側のローカルフィルターの Useless Explorer files をオン（✅）にするだけ。これで一々、サーバーに .DS_Store をコピーして送ってしまうことに悩まされなくなる。

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

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

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

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