この記事は PowerShell Advent Calendar 2019 の 23日目 の記事だ。
日程が埋まりきっていなかったので、適当な内容で埋めていこう。
あなたは、 PowerShell の短いコードを、 デスクトップのアイコンをクリックするのも億劫なほど、手軽に実行したいと思ったことはないだろうか？
ないって？
私はある。
例えば、ブラウザなどでコピーして WYSIWYG エディターにペタリと貼り付けるときに、クリップボード内の装飾情報を削除したいとか。
(Get-Clipboard -TextFormatType UnicodeText -Raw) -replace '^[ \r\n\t]*|[ \r\n\t]*$','' | Set-ClipboardPowerShell なら上記のような一行コード実行すれば済む話だ。 しかし、 ウィンドウをシェルに切り替えたり、 ショートカットクリックするのも面倒。 タスクトレイのアイコン一つクリックして実行できたらいいのに。
はい、それを叶えます。
.NET Core の登場で大分影が薄くなったものの、 まだまだ Xamarin でガンガン使われている Mono。
この Mono には, gsharp という C# GUI Shell が存在する。
CUI 版の Shell と比べると、 グラフがプロットできるとか、 画像が手軽に表示できるといったメリットしかないが、タブ補完も効くし、まぁ便利っちゃ便利なツールだ。
しかし Windows で gsharp を動かしたくても、 Windwos 用の Mono インストーラには gsharp が入っていないため、そのままでは gsharp を使えない。
このため、 WSL の Ubuntu に gsharp をインストールして、 VcXsrv などの X Server を使って動かすのが手っ取り早い。
以下の記事が詳しい。
ところが、 この gsharp などを含む、 Mono 拡張 GUI ツールを、 WSL を含む Ubuntu ベースのディストリビューションにインストールしようとすると、エラーになってしまう。
今回は、 その暫定的な回避策について。
早く mono/mono#16322 の不具合直した Mono パッケージを出してくれ。
11/10 頃から、 Python でpypiwin32 や pywin32 パッケージや、それらに依存しているパッケージを pipenv にてインストールしようとすると、
AttributeError: module 'site' has no attribute 'getsitepackages'とエラーが出て失敗するようになった。
10/22 追記: pywin32 v227 で問題は修正された。
"there's nothing wrong with PyWin32, it's just a fix applied on PyWin32's side to work around a VirtualEnv bug." と、修正コメントで強調されている。 わかるよ、その気持ち。
追記ここまで
直接的な原因は、 pipenv ではなく virtualenv にある。
この記事は、 Ansible AWX をインストールしたときに、 Server Error に なったりならなかったりする 問題に対処したときのポエムだ。
はじめに断っておくが、最終的に AWX 8.0.0 で解消しているっぽいものの、 原因や正確な条件などは不明なままである。
また後述するが、 （タイトルに反して）おそらく Ansible AWX の問題ではなく、 postgres:9.6 の docker イメージの問題ではないかと思われる。
構成管理ツール (いわゆる Infrastructure as Code（IaC）) の中でも比較的易しいと言われる Ansible。
その Ansible の運用を省力化してくれるツールとして Ansible Tower というものがあり、そのコミュニティ管理版 (OSS版) が AWX だ。
その AWX がインストールされたサーバを作成する Playbook を作ろうとしたら意外と手間取ったので、そのメモ。
なお、インストール先は CentOS 7 である。
AWX のインストールは、 公式ビルド済み docker イメージを Docker Compose を使ってコンテナ化する方法 を使った。
11/21: 追記
docker-compose の PyPI (pip) パッケージが 1.25.0 に更新後、 CentOS 7 (正確には、 Python 2 系を使っている環境) で docker-compose のインストールや実行がうまくいかなくなった。
(commit:719a1b0 で) subprocess32 に依存するようになり、 gcc 等のビルド環境のインストールが別途必要になったためだ。
それに加え、たとえ gcc をインストールしても、依存パッケージの python2 対応が不十分なようで、 docker-compose 実行時にエラーになってしまう。
docker/compose#7030 の Issue には挙がっているが、修正されるかどうか不明なため、一つ前の 1.24.1 を使うことで回避するように、コードを修正した。
python2 ツラい。。。
しかし、 2020年にサポート切れになった後も、 CentOS 7 が生きているしばらくの間はこの辛みと付き合わなければならないようだ。
ツラい。。。
追記ここまで
プロキシ環境下の vscode で、 WSL 上で拡張機能を動かしたいのに、 インストールインストールに失敗する問題を解決するメモ。
前回の↓の記事は、 『Remote – WSL 拡張が有効にできない』問題だったが、今回は『Remote – WSL 拡張 を有効にした後、その環境上で他の拡張機能がインストールできない』問題なのでちょっと違う点に注意。ややこしいね。
Visual Sutdio Code (以下、 vscode) へ 無事に Remote – WSL 拡張機能 の "VS Code Server for WSL" のインストールが完了し、 Windows 上から 快適に WSL の環境にアクセスできるようになった。
しかし、 いくつかの vscode の拡張機能は、 Windows 上の環境とは別に WSL 上の環境で改めてインストールしなくてはならない。
そこで、 UI 上の案内に従って各拡張機能で "Install in WSL" を行ったところ、 プロキシ環境下だと以下のエラーが発生してインストールに失敗する問題に遭遇した。
Failed to install extension
パネル上の OUTPUT タブで "Log (Remote Server)" の情報を見ると、以下のようなエラーが発生しているのがわかる。
[remoteagent] [error] Failed to install extension: {拡張機能ID} connect ECONNREFUSED 13.107.6.175:443
settings.json ではプロキシの設定しているし、更には WSL 上の環境変数 (http_proxy, https_proxy) にだってプロキシを入れている。
更には（前述の）前回の記事に倣って、 WSL のコンソール上から code . の立ち上げまで行ってみた。
それでも解消しない。何故だ。
なお、試した vscode のバージョンは、 August 2019 (version 1.38.1) だ。
Windows 上の Visual Studio Code (以下、 vscode) で、WSL 上のファイルやシェルを使えるようになる、 Remote - WSL 拡張機能。
これを、プロキシ環境下でインストールしたり更新したりすると、 vscode から WSL 環境ににアクセスするときに、
VS Code Server for WSL closed unexpectedly. Check WSL terminal for mor details.
とエラーになってしまう。
WSL ターミナルのログを見てみると、だいたい以下のようになっていて、どうやら update.code.visualstudio.com から VS Code Server の更新版のファイルをダウンロードするのに失敗しているように見える。
Starting VS Code Server inside WSL (default distro) Extension version: 0.39.5, Windows build: 17763. Multi distro support: disabled. WSL path support: enabled Probing if server is already installed: C:\WINDOWS\System32\wsl.exe -e sh -c "[ -d ~/.vscode-server/bin/3db7e09f3b61f915d03bbfa58e258d6eee843f35 ] && echo found || echo missing" No server install found on WSL, downloading server on client side: C:\Users\user\AppData\Local\Temp\vscode-remote-wsl\3db7e09f3b61f915d03bbfa58e258d6eee843f35\vscode-server-linux-x64.tar.gz Unable to detect if server is already installed: Error: connect ECONNREFUSED 104.42.78.153:443 Launching C:\WINDOWS\System32\wsl.exe sh -c '"$VSCODE_WSL_EXT_LOCATION/scripts/wslServer.sh" 3db7e09f3b61f915d03bbfa58e258d6eee843f35 stable .vscode-server 0 --disable-telemetry' in c:\Users\user\.vscode\extensions\ms-vscode-remote.remote-wsl-0.39.5 WSL version: 4.4.0-17763-Microsoft Updating server... Updating VS Code Server to version 3db7e09f3b61f915d03bbfa58e258d6eee843f35 Removing previous installation... Downloading: Failed --2019-09-11 20:50:12-- https://update.code.visualstudio.com/commit:3db7e09f3b61f915d03bbfa58e258d6eee843f35/server-linux-x64/stable Resolving update.code.visualstudio.com (update.code.visualstudio.com)... 104.42.78.153 Connecting to update.code.visualstudio.com (update.code.visualstudio.com)|104.42.78.153|:443... failed: Connection refused. ERROR: Failed to download https://update.code.visualstudio.com/commit:3db7e09f3b61f915d03bbfa58e258d6eee843f35/server-linux-x64/stable to ~/.vscode-server/bin/3db7e09f3b61f915d03bbfa58e258d6eee843f35-xxxxxxxxxx.tar.gz VS Code Server for WSL closed unexpectedly. For help with startup problems, go to https://code.visualstudio.com/docs/remote/troubleshooting#_wsl-tips
どう解決したものか。
ネットワークドライブ上の GB オーダーのファイルに対して、複数のハッシュアルゴリズムでファイルハッシュを計算する必要に駆られていた。
「そんなシチュエーションが本当にあるのか？」と思うかも知れないが、あったのだから仕方ない。
最初は、 PowerShell を使って 愚直に Get-FileHash を 2回 計算していた。
しかし当たり前だが、 2回ファイルをダウンロードすることになるこの方法は遅くて仕方ない。
ということで、 C# でコンパイルしたコード上で、 一度メモリに読み込ませてから複数のハッシュアルゴリズムで計算できるようなコードを作成した。
バッファーサイズを 80KiB 程度とすると、 .NET の仕様で 85KB を境にメモリの扱いが変わる (LOH と呼ばれる特別なヒープに移動する) ことから、 このサイズを超えると一般的に動作速度が下がると言われている。
しかし、今回のコードの場合バッファーが小さいと、 Task 周りの処理がボトルネックになってしまうので、 8MiB くらいのサイズとしている。
80KiB としているのは、 .NET mscorlib の System.IO.Stream.CopyTo メソッドなどでもおなじみなのだが、これが必ずしも正解とは限らないわけだな。
800Mbps 位でシーケンシャルリードできるリモート上の 4GB のファイルを、 4回 ずつ計測した平均を計測した。
Get-FileHash の 2種類目 以外はクライアントキャッシュが効かないように注意し、 計測の各回でハッシュを計算するファイルはそれぞれ別のファイルで、中身はランダムバイナリとした。
Get-FileHash については、 計測の各回では同じファイルに対して -Algorithm パラメータを変えて複数回連続で呼び出した。
| 計算したハッシュの種類 | Get-FileHash |
上記の改良スクリプト |
|---|---|---|
| 1種類 (SHA1) | 48.8s | 43.3s |
| 2種類 (MD5, SHA1) | 60.4s | 44.2s |
| 3種類 (MD5, SHA1, SHA256) | 83.3s | 48.2s |
ん？ 計算したハッシュが 1種類 の場合でも、改良スクリプトの方が早いぞ？
HashAlgorithm.ComputeHash の実行速度、低すぎ…？PowerShell v5 相当
PowerShell v6 相当
上記のように、 Get-FileHash は、内部的に HashAlgorithm.ComputeHash でハッシュ計算を実行している。
で、その HashAlgorithm.ComputeHash がどうなっているかというと、 4KiB 毎に ファイルの読み込みと、 ハッシュストリームへの書き込みを 同期的に 行っている。
ファイルの読み込みも、 (使うアルゴリズムにもよるけど) ハッシュの計算も、 どちらもコストがかかるので、同期的にやってたらそりゃ遅いわ。
当ブログでは、 WordPress の Twenty Eleven テーマを使っている。
このテーマでば、なぜかシングルページの表示や個別記事のページでサイドバーが表示されない。
当ブログのアクセスのほとんどは、 検索からの個別記事のページへの流入なので、個別記事へのサイドバーの表示は行っておきたいところだ。
それを実現するのが、 Twenty Eleven Theme Extensions プラグインだ。
とても古いプラグインだが、 Twenty Eleven テーマの最新版でも問題なく動いている。
ところが、 このプラグインを有効にしたところ、 Google の Search Console で怒られるようになってしまった。
調べてみたところ、 /plugins/twenty-eleven-theme-extensions/moztheme2011.css の配信が This request has been blocked; the content must be served over HTTPS. でエラーになってしまっているようだ。
このブログは SSL化 され https:// で配信されているのに、プラグインの CSS が http:// で配信されているためだ。
これを修正してみよう。
運用時にネットワークにつながっていない Android タブレットで、 自作のアプリケーションを 簡単に 動かすには、どうしたらよいだろうか？
.apk ビルドしてインストールさせる？いやいや、手軽からはほど遠いだろう。
現在のトレンドは PWA で Service Worker を組み合わせてキャッシュさせる方法だろうか。
PWA 配信するには https のホスティングを用意しなくてはならないし、ブラウザのキャッシュ整理したらデータが吹き飛んでしまう。
ここで私は、 Android 上で Python を動かしてセルフホストさせる方法 を提唱したい。
