おは代々木ダイアリー

いろいろ試したメモを書きます

WSL --updateしてからSSH経由でWSLが起動しなくなって困った

久々に触ったパソコンでWSLでもしてみるかなーーーと思ったら wsl --list --online で表示されるディストリビューションが古く、あれ?!アップデートが必要??となって迂闊にも wsl --update したらSSH経由でログインしてwslコマンドを叩くことができなくなりました。

コンポーネント版とプリインストール版

WSLには、Windowsのオプション機能として導入できるWSLと、Microsoft Storeからダウンロードできるストア版のWSLが存在するらしいです。

参考: ASCII.jp:WSL(Windows Subsystem for Linux)がMicrosoftストア版に一本化される

今回触っているパソコンは、Windows 10 Homeで、低スペックにもかかわらず戯れで導入した「オプション機能として導入できるWSL」が入っていました。

それを上にも書きましたが、「久々に触るからアップデートするぞ~~~」wsl --update を叩いてしまったからあら大変。問題が起こってしまいました。

起こった問題: SSH経由でWSLコマンドが叩けなくなった

以前も書きましたが、ぼくはWSL2にSSHで乗り込んでWindows 10 Homeなパソコンを開発サーバーにするということをしています。

ohayoyogi.hatenablog.com

上記のような芸当をするためには、SSHで乗り込んで nc コマンドを叩くということが必要になるので、乗り込んだ先でWSLコマンドが叩けないといけません。

が、以下の画面。

wsl.exeで「ファイルにアクセスできません。」

「ファイルにアクセスできません」・・・ってなんじゃそりゃ~~~~

ちゃんとモニタ繋いでローカルにWSLコマンド叩くことはできるのにな~~~~~

解決策: ストア版をアンインストールする

どうやら、これって C:\ProgramData\Packages のアクセス権が特殊になっていて、SSHでログインしたユーザーからは触れなくなっていることが問題っぽい??

  • アクセス権限を修正すれば使えるようになる
  • Windows Update (KBいくつだったか忘れた)をアンインストールすれば解決

調べてみると、上記のような解決策がでてきましたが、アクセス権を修正したこと絶対後になって忘れるし、当該番号のWindows Updateは適用されていなかったしで最後の手段で update したものを元に戻してみることにしました。つまり、ストア版のアンインストールです。

Windows 10の設定の「アプリと機能」から、「LinuxWindows サブシステム」をアンインストールします。

ストア版をアンインストールしてみる

で、アンインストールが完了したら(ここで念のために再起動しました。)気を取り直して… ディストリビューション再インストール!!

wsl --install -d Ubuntu

Ubuntu再インストール

とまぁ、再インストールしてみましたが再インストールが必要かはわかりません。自分の場合、なぜかフォルダが圧縮されていたりしてちゃんと起動しなかったので気持ち悪くて再インストールしてみましたが、 wsl --update で単に起動しなくなったケースでは再インストールは不要かもしれません。

終わりに

というわけで、誤ってストア版に上げてしまったwsl.exeを戻して事なきを得ましたという記事でした。どなたかの参考になれば幸いです。

しかし、これからストア版に統一されるっていうのにこんな不具合抱えていて大丈夫なのか?と心配になりますね。このマシンも結構古くから使っているので最近のWindows10をクリーンインストールしたりすると良くなったりするんだろうか。

おまけ

なんでそもそも前回までで開発サーバー用意できたのにまたWSLいじってるの?と思われた方もいらっしゃると思いますが、ゲーミングPC付けっぱなしにしているのに罪悪感を覚え、低消費電力な録画サーバーに開発サーバーを兼務させられないか?と試してみているところでした。

もしよければ、Twitterもフォローお願いしいます~

WSL2 Bashを使うことですべての問題が解決したかと思われたWindowsリモート開発だったが結局WSL2にSSHした件

Windows10 HomeなゲーミングPCに乗り込んでリモート開発すべく、WindowsにOpenSSHサーバーを導入してVisual Studio Codeのリモート開発拡張機能を使ってきました。開発を進めていく上で遭遇した

  • SSH経由のgit pullがハングする
  • DevContainersが使えない

といった不具合を乗り越えるため、WSL2 Bashをデフォルトシェルに指定することで解決するという内容を前回記事で書きました。

ohayoyogi.hatenablog.com

まだ残っていた問題

デフォルトシェルをWSL2にすることで、当初の「SSH経由でのgit pull」や「DevContainersの利用」はできるようになったものの、新たな問題が発覚しました。

それは

  • ssh-agentのForwardingが効かない

ということです。「WSL Bash SSH Agent Forward」みたいなググり方をすると、使用するSSHクライアントによって癖があるようで、「Windowsssh-agent.exeに登録した鍵をWSL2 SSHで使用する」みたいな内容がよく出てきました。が、今回はそれとは違うような気がしています。

(そもそも、SSHのAgentForwardingってどうやって実現されているのかよくわかってないです。SSHサーバーが環境変数に参照すべきAgentの宛先を設定して、それをSSHクライアントが使用している…?詳しい人いたら教えてください…)

で、さんざん調査してわかったのはどうやらWindows向けのOpenSSHサーバーはAgentForwardingには未対応ということです。おお、マジか・・・

Agent Forwarding Windows client to Windows host not working? · Issue #1865 · PowerShell/Win32-OpenSSH · GitHub

というわけで、AgentForwardningが効かないのはちょっと(だいぶ)つらいので、頑張って解決してみようという内容になります。

解決方法

いままで開発してきて、Windows向けのOpenSSHクライアントからLinuxのOpenSSHサーバーに向けてつないだ時はAgentForwardingが機能することは確認できていたので、WSL2のLinuxに直接SSH接続すればいい ということになります。

が、ここで立ちはだかるのは2つの壁です。

  • WSL2でsshdを動かす
  • WSL2のsshdへ何とか繋がるようにする

一番目のsshdの動かし方は wsl sudo service sshd start とかやっちゃえばまぁ解決です。問題は二番目の「WSL2のsshdへの繋ぎ方」です。

これについては何が問題かというと、WSL2で使用されるIPアドレスは起動のたびに変わってしまうということが言われていて、現在固定する方法がない(Hyper-V使える人は固定できるみたい?まぁWindows Proエディションの話なので今回は対象外)ということです。

世の中の先人たちは、これに対して WSL2のIPアドレスを取得してnetshでポートフォワーディングの設定を書く という対処方法をよくとっているみたいです(著者調べ)。以下、参考にしたサイトです。

リモートマシンのWSLにOpenSSHサーバとDockerを入れてVSCodeからリモートアクセスできるようにする - てのひら

ただ、これ開発時以外もずっとポートフォワーディングしてるのが非常に気持ち悪いですし、そもそもタスクスケジューラとか普段使わないので設定したことを忘れて放置してたりしそうで怖いです。何よりファイアウォール開けるのが嫌ですね・・・

というわけで、別の方法をとりたいと思います。

Windowsホストを踏み台にしてWSL2にログインする

Windowsに開発時以外もポートフォワーディングさせるのちょっと怖いですし、昔ながらの「SSHのProxyCommandを使って接続する」という方法をとってみたいと思います。「踏み台」ってやつですね。

【ポートフォワーディングさせる場合】
クライアントマシン ==SSH==> WSL2(開発機)

【踏み台にする場合】
クライアントマシン ==SSH==> Windows(開発機) ==SSH==> WSL2(開発機)

そうだnetcatしよう

さて、踏み台にするにあたって「WSL2のIPアドレスはどう扱う?」という問題は依然としてあります。

が、ここで天啓。これ、フツーに「WSL2にnetcatさせればいいのでは????」となりました。

つまり、ProxyCommand で踏み台に wsl nc localhost 22 させればよいのです。

やりかた

というわけで早速 .ssh\config を書きました。WinHomeは開発機のホストで、DevWSLは開発機内のWSL2のホストです。

Host WinHome
  HostName 1.2.3.4
  # 以下略

Host DevWSL
  HostName localhost
  Port 22
  ProxyCommand ssh WinHome wsl nc %h %p
  # 以下略

接続時は ssh DevWSL とするだけでOK!。VSCode からもDevWSLを開くようにポチポチしているだけでWSL2に入って開発することができます。

結局、AgentForwardingならず

はい、ここまで引っ張っておいてアレなんですが、結局AgentForwardingできていません。なんかどうもWSL2に導入するOpenSSHのバージョンによってはForwardingできない問題が発生するそうです。なんじゃそりゃー!

WSL2のOpenSSH Agent Relayが動かなくなったので調査した

結局DevContainersでいく

結果としては失敗に終わりましたが、実はAgentForwardingできる方法がありました。

VSCodeのDevContainersのAgentForwarding機能を使用する という方法です。

これ、どうやらSSHとは異なった経路(?)でAgentForwardingしているようで(確かにDockerに入るのSSHじゃないもんな)、たぶんバケツリレー的に経由するホストの各地点でAgentForwardingできていなくてもSSHクライアントと連携できるんだと思います。(適当言ってます。間違ってたら指摘してください…)

devuser@0cf0909ae8ca:/workspaces/hogehoge $ ssh -T git@github.com
Hi ohayoyogi! You've successfully authenticated, but GitHub does not provide shell access.

え?じゃあこれWSL2 Bash経由で繋いでてもDevContainersだったらPortForwardingできたってこと~~~????っていう疑問もわくんですが、怖いので調べていません・・・(情報求む)

終わりに

というわけで、WSL2に対してnetshによるポートフォワーディングを使用せずにSSHで繋ぐ方法を考えてみました。

WSL2にAgentForwardingできたら最高だったんですが、それは時間が解決してくれるということで、今は頑張って何とかWSL2内でpullしてから鍵を使った作業はDevContainers内でどうにかするという方法をとりたいと思います。

それでは、みなさまもよきリモート開発ライフを。

nodeなどのコンテナイメージでdevcontainerを使うとuidが変わらなくて困る問題への対処

Visual Studio CodeのRemote Containers機能(Dev Containers)には、VSCodeの実行ユーザーのUIDでコンテナ内のユーザーのUIDを更新してくれる便利な機能があります。

例えば、UIDが1002のユーザーでVSCodeを立ち上げていて、コンテナ内で作成したユーザー devuser を使用したとき、コンテナ内の devuser のUIDは1002に上書きされるといった挙動になります。これは、手元のディレクトリをコンテナ内にマウントしていて、それをVSCodeでいじる場合に、UIDが異なってしまうという問題を回避することができるのでとても便利。

使い方

使い方は簡単で、devcontainer.json に以下のように remoteUserupdateRemoteUserUID を指定するだけ。remoteUser にコンテナイメージ内に存在するユーザー名を指定することでコンテナを開いたときに使用されるユーザーを指定でき、かつ updateRemoteUserUID を有効にすると 指定したユーザーのUIDが現在のログインユーザーのUIDになってくれます

{
  "remoteUser": "devuser",
  "updateRemoteUserUID": true,
}

説明のためupdateRemoteUserUID も念のため指定していますが、このオプションはデフォルトで有効になっているので明示的な設定は省略可能です。

DevContainersに使用するコンテナイメージには、以下のようなDockerfileを考えてみます。

FROM ubuntu:20.04

ARG USERNAME=devuser
ARG USER_UID=1234
ARG USER_GID=$USER_UID

# Create the user
RUN groupadd --gid $USER_GID $USERNAME \
    && useradd --uid $USER_UID --gid $USER_GID -m -s /bin/bash $USERNAME 

Dockerfile では UID 1234 で devuser というユーザーが作成されていますが、Dev Containersで開いてみると、見事IDなどが変わっていることがわかります。

devuser@cbb03f77d869:/workspaces/devcontainer_example$ id
uid=1000(devuser) gid=1000(devuser) groups=1000(devuser)

devuser@cbb03f77d869:/workspaces/devcontainer_example$ ls /home/devuser -la
total 28
drwxr-xr-x 1 devuser devuser 4096 Jan 12 04:17 .
drwxr-xr-x 1 root    root    4096 Jan 12 04:17 ..
-rw-r--r-- 1 devuser devuser  220 Feb 25  2020 .bash_logout
-rw-r--r-- 1 devuser devuser 3771 Feb 25  2020 .bashrc
-rw-r--r-- 1 devuser devuser  807 Feb 25  2020 .profile
drwxr-xr-x 6 devuser devuser 4096 Jan 12 04:17 .vscode-server

ちゃんと HOME のパーミッションも変わっていてとてもGOODですね。

問題点

「指定したユーザーのUIDが現在のログインユーザーのUIDになってくれます」と書きましたが、これが効かないケースもありました。

というのも、変更先のUID(つまりログインユーザーのUID)がコンテナイメージ内ですでに使われていた場合、このオプションは有効に働かず、コンテナイメージ内のUIDがそのまま使われてしまいます。

例えば、「node」のコンテナイメージはデフォルトで node というユーザーがUIDが1000で作成されているので、VSCodeを起動しているユーザーのUIDが1000だった時にバッティングしてしまい、devuser は作成した時点の UID 1234 の状態のままでDev Containersが立ち上がってしまいました。

解決方法

ここで、この問題を解決できる方法を考えてみました。

1. そのユーザーをそのまま開発にも使う

すでに使いたいUIDが使用されてしまっているのであれば、remoteUser にそのUIDが割り当てられているユーザーを指定してしまうのも手です。

ただ、これだとユーザー名が自由に選べませんし、意図した通りにセットアップされているかはDockerfileを読み解いていくしかありません。そもそも、Dev Contaienrsで乗り込むコンテナにユーザーがあったとしても、そのユーザーをそのまま活用するケースに出会ったことがありませんし、こういうユーザーは封印前提で次に示す解決策2を取るのがいいのかなと思います。

2. そのユーザーのUIDを変えてしまう

1でも書きましたが、これはこのユーザーがDockerfile作者の想定した通りに使えなくなる可能性があるので、「封印前提」で考えるべきでしょう。

RUN groupmod -g 12345 node && \
    usermod -u 12345 -g 12345 node

上記のように、node ユーザーがすでに使いたいUIDを使っていて邪魔なのであれば、そのユーザーのUIDを使わない値にしてしまえという発想です。(消しちゃってもいいのかもしれない)

このようにすることで、uid 1000がすでに使われていたとしてもログインユーザーのUIDに合わせてDevContainers内のUIDを上書きすることができるようになりました。

終わりに

以上、ゴリゴリっと書いてしまいましたが、DevContainersのremoteUser の問題と対処でした。

(読み返すとUID, VSCode, DevContainersと表現が揺れまくっているのが気になる…)

WindowsへのVSCode SSH Remoteに疲れたのでWSL bashを使ってLinuxっぽく使うことにした

リモート開発、便利ですよね。今回はWindows 10 HomeなPCに乗り込んで開発するという内容で記事を書いてみたいと思います。

想定読者

この記事はこんな方に向けて書いています。

  • Windows マシンに乗り込んでリモート開発をしたい!
  • Windows 10 ProのライセンスがないのでHomeでもできる方法を探している

ぼくはDellのG5 5000というゲーミングPCを開発環境として使っていて、先月も増設用のメモリなどを買ったところなんですが、これをリモート開発に使用したい!だけどOSがWindows 10のHomeエディションといういかんともしがたい状況なのです。

ohayoyogi.hatenablog.com

追記20230112:やっぱり駄目でした

どうもやはりssh-agent周りが厳しく、期待通りとはいきませんでした。ほかにやり方考えます。

背景

そもそもなぜリモート開発をしたいかというと、

  • どこからでも1つの環境に乗り込んで手慣れた環境で開発をしたい
  • かといって軽いノートパソコンではスペックが足りない
  • あんまりヘビー(物理)なマシンを持ち歩きたくない

などなど、皆様様々な理由があると思います。自分もインタプリタ系の言語でツールを書いているうちは試行錯誤に時間がかかるので問題にはならないんですが、TypeScriptなどトランスパイルを挟む言語だったり強力な補完を効かせたい言語で開発を行っているとなかなかにストレスが溜まってきます。

補完なんて使わずにメモ帳でも書けて、試行錯誤も1回で済むスーパーマンであればそういったストレスも少なくて済むのでしょうが、ぼくはゴリゴリにトライアルアンドエラーを繰り返して物を作っていく人間なのでそうはいきません・・・

リモート開発環境候補

ここに至るまでに考えた(試した)ものを記載します。

1. リモートデスクトップVNC, RDP, TeamViewer)

VNCやRDPを通して開発するという方法です。GUIを使う方法でネットワークの帯域は必要になりますが、ローカルネットワークであれば快適に開発できます。

「パワーで解決」という感じなので、ネットワークなどの環境に左右されがちなのが難点でしょうか。これがどんなところでも快適にできる未来が来るといいですね。

また、RDPを使うにはWindowsのProライセンスが必要になるので、使える人は限られるのではないかと思います。(自分が開発に使用しているゲーミングPCもHomeライセンスです)

2. Visual Studio Code のリモート開発機能(Linux

???「SSHでよくね?」

はい、昔ながらの方法、「SSH経由でVIM」。これが最強です

・・・ではなくて、最近はVisual Studio Codeのリモート拡張機能を使うとVSCodeの言語サーバー(補完などを提供するサーバー)をリモートで動かしつつ手元に表示して開発することができます。

おお、それなら無料で使えるOracleCloudのARMインスタンスを使ってみてはどうか?ということで、VSCodeのリモート機能で乗り込んで開発してみました。(ARMインスタンスは普段以下のような使い方をしています。)

ohayoyogi.hatenablog.com

が、やはりゲーミングPCのパワーは強く、見劣りするなぁというのが正直な感想です。まぁ使えなくはないんだけど…

3. Visual Studio Code のリモート開発機能(Windows

実はVisual Studio Codeのリモート機能にはSSHWindowsにも乗り込むことができます。

「エーWindowsSSH?」と思われる方もいるかもしれませんが、Windows 10には、とあるバージョンから「OpenSSHサーバー」をオプション機能としてインストールする機能が備わっていますので、簡単にSSHを導入できるのです。

実際に使ってみると、デスクトップPC内で作業しているような快適さでリモート開発できることがわかると思います。

Visual Studio Codeを使用したWindowsでのリモート開発の問題

というわけで、ここまで試してきた中でリモートのゲーミングPC(Windows 10 Home)にSSH経由でVSCodeで乗り込むという方法で快適なリモート開発環境が構築できました。これでしばらくは問題なく開発することができていたんですが・・・

しかし、これにも問題が…

  • SSH周りで問題がありそう?(SSHでgit pullできないとか)
  • devcontainerが使えない

一番目はターミナルでSSHしている場合は普通にgit pullできるのでVSCode拡張機能側の問題で、二番目はdevcontainerの拡張機能Windowsに対応していない(/etc/passwdとか参照しようとしてコケてる)というのが問題です。

Windowsでリモートはやはりマイナーなのか・・・

これについてはLinux互換の何かを動かせばよいので方法は複数考えられて、

  • VirtualBox など VMを立てる
  • WSL2 の LinuxSSHサーバーを立てる
  • デフォルトシェルをWSL2にしてみる

などがあります。が、1つ目はリソースをフルに活用できない問題、2つ目はWindowsとWSLでは内部で異なるIPアドレスになっているのでフォワーディングが別途必要になるなどから、今回取ってみるのは3つ目のWindowsのデフォルトシェルをWSL2のbashにしてみるという作戦です。

解決手順

解決は以下の3ステップです。

デフォルトシェルをWSL2のbashにする

まずはリモートで乗り込む先のWindowsマシンのデフォルトシェルをWSLのbashに変えてしまいます。サーバーにログインした後、レジストリエディタで HKEY_LOCAL_MACHINE\SOFTWARE\OpenSSHDefaultShell という名前で C:\Windows\system32\bash.exe という値の文字列を登録します。

HKEY_LOCAL_MACHINE\SOFTWARE\OpenSSH

PowerShellで行う場合は以下の通り。

New-ItemProperty -Path "HKLM:\SOFTWARE\OpenSSH" -Name DefaultShell -Value "C:\Windows\system32\bash.exe" -PropertyType String -Force

参考: OpenSSH Server configuration for Windows | Microsoft Learn

VSCode Remote SSH の設定を「Linux」に

これでデフォルトシェルがWSLのbashになったので、VSCode側のリモート接続設定を Linux にしましょう。

設定の "remote.SSH.remotePlatform" の値を ホスト名: "linux" という形式で記載します。

{
  "remote.SSH.remotePlatform": {
    "hogemachine": "linux"
  }
}

このようにすることで、対象マシンがLinuxマシンと判断され、VSCodeもsh前提の動作をしてくれるようになるようです。

Windows設定のままだと以下のようなエラーが出てしまいます。PowerShellとかcmdとか探そうとしてしまうみたいですね。

[10:40:38.083] "install" terminal command done
[10:40:38.083] Install terminal quit with output: ]0;C:\Windows\System32\cmd.exebash: powershell: command not found
[10:40:38.083] Received install output: ]0;C:\Windows\System32\cmd.exebash: powershell: command not found
[10:40:38.084] Failed to parse remote port from server output

WSL2内でのdockerの設定を変える

何が原因なのかはわかっていませんが、devcontainerを使用しようとすると以下のようなエラーが出ました。

[2023-01-10T14:30:09.008Z]  => [internal] load build definition from Dockerfile.extended              0.0s
 => => transferring dockerfile: 3.30kB                                     0.0s
 => [internal] load .dockerignore                                          0.0s
 => => transferring context: 2B                                            0.0s
 => ERROR resolve image config for docker.io/docker/dockerfile:1.4         1.0s
------
 > resolve image config for docker.io/docker/dockerfile:1.4:
------
ERROR: failed to solve: rpc error: code = Unknown desc = failed to solve with frontend dockerfile.v0: failed to solve with frontend gateway.v0: rpc error: code = Unknown desc = error getting credentials - err: exit status 1, out: `error getting credentials - err: exit status 1, out: `A specified logon session does not exist. It may already have been terminated.``

どうもcredentialsを取得しようとしてるときにエラーが発生しているようなので、設定ファイルを見てみます。

{
  "credsStore": "desktop.exe"
}

desktop.exe とか怪しすぎるので、適当に無効な設定にしてしまいます。

{
}

これで再度devcontainerで開いてみて無事ビルドが通ればOKです。

終わりに

以上、開発環境構築記事でした。Windowsにリモートで乗り込んで開発したいとかいう珍しい方がいらっしゃったら参考になれば幸いです。

AmazonブラックフライデーでDell G5を増強しました

普段開発に使用してるゲーミングPC「Dell G5 5000」にパーツの増設を行ったのでそのメモ。

はじめに

今までもちょくちょくいじってきましたが、年末ということもあるので、PCパーツ買って整理するのもありかなと思い、購入に踏み切りました。

ohayoyogi.hatenablog.com

ohayoyogi.hatenablog.com

買ったもの

既存のゲーミングPCに増設するだけなので、正直そんなインパクトないですw

SSD: KIOXIA EXCERIA PLUS G2 1TB

まずはシステムディスクの増設用のSSDです。これは以前ノートパソコンのSSDを換装して出た余りを使っている状態だった(というかG5もここまで真剣に使うとは思っていなかった)ので、ちゃんと開発に不便しないように大きめのNVMeなSSDを買いました。

ディスクの大きさについては正直、開発のソースコードGitHubに上げますし、写真データもPrime Photoに上げるなどクラウド前提の立ち回りをするつもりなので、そんなに大きな容量は必要ないんじゃないかと思いますが、まぁ大は小を兼ねますので。

一応データ置き場として1TBの2.5インチSSDも積んであります。(以前購入したTranscendSSD

(これは余談ですが、ソースコードや依存モジュールなど、ビルド時に頻繁に読み書きするのを高速なNVMeに置いた方がいいんじゃないかーと思ったりもしますね。これ以上考えると進まなくなるのでとりあえずSATAにデータ、NVMeにシステムとしてしまいました)

写真をぺたー。これも余談ですが、販売はバッファローなんですね。

KIOXIA EXCERIA PLUS G2のパッケージ

さらに余談ですが、エクセリアといえば。(エクバシリーズ好きです)

メモリ: CORSAIR VENGEANCE LPX DDR4-3200MHz 2022限定モデル

続いてメモリです。今まではごちゃまぜのメモリ4×8GB構成でしたが、安かったのでこれを機に2×16GBで32GBとすることにしました。(増えてない)

換装した結果としては、G5で問題なく利用できているのですが、フルスペックは活かせていません。そもそも、このメモリを3200MHzで動作させるにはXMPに対応したマザーボードが必要ですが、Dell G5 5000はこれに対応していないため定格の2133MHzでの動作となる模様です。

Dellのマニュアルを読むと2666MHzでうごくっぽいぞとワクワクしていたんですが、

G5 5000 セットアップと仕様 | Dell 日本

Dell G5 5000のメモリ構成(「G5 5000 セットアップと仕様」より)

そんなことありませんでした。どうやら2666MHzで動作するのはDell純正のものを装着した場合のみ、らしい。

そこまで違いがわかるか、と言われると絶対そんなことないんですが、フルスペック出てないのは気持ちが悪いので、このメモリは自作PCするときにまた活躍してもらおうかなと思います。(とりあえずG5に付けてはおくけど)

CORSAIR VENGEANCE LPX

装着

というわけで、装着~~~~

Dell G5 5000にメモリとSSDを増設

(ほこりが汚い)

システムのセットアップ

と、今回はシステムディスクの換装を行ったので、Dell G5 5000をまっさらな状態にリカバリしてから開発環境を整えました。

OSの再インストール

Dell OS Recovery Tool」というものを使用することで、Dellのマシンに応じたUSBリカバリディスクを作成することができるので、これを使いました。(Optiplex 9020のリカバリでもお世話になりました)

www.dell.com

ポチポチとダイアログに従ってモデルやらOSの種類やらを選ぶとUSBに書き込まれるので、そこまで難しくないと思います。あとはいつも通りWindowsクリーンインストールされるのでWindows Updateで当たるドライバを片っ端から適用していけばOKです。

Windows Subsystem Linuxのインストール

もはや開発環境としてDockerは外せないですね。というわけで、まずは最初にWSL(WSL2)の導入。

最近のWindows10はすごいので、WSLコマンドが初めから入っています。管理者コマンドプロンプトから以下のコマンドをたたいてWSLを最新化したのち、

wsl --update

Microsoft StoreからUbuntuをインストールするだけ。

Microsoft StoreでUbuntuをインストールする

楽ちんですね。WSLのデフォルトバージョンを2にするのには以下のコマンド。

wsl --set-default-version 2

Docker Desktopのインストール

正直Docker DesktopのGUIは要らないんですが、インストールでごちゃごちゃするのも面倒なため、Docker Desktopを入れてしまいました。まぁ個人利用ならライセンス的にも問題ないのでいいかなと。

https://www.docker.com/products/docker-desktop/

その他もろもろ

必要に応じて必要なものを入れていきます。

などなど。まぁdockerを使えるようにしたらpythonだのnodeだのはコンテナで用意すればいいので、実質必要なのはGitとVisual Studio Codeぐらいかなという感じ。

終わりに

リカバリから始めましたが、作業環境を整えるのはそんなに時間がかかりませんでした。ドライバ回りもWindows Updateでほとんどあたりますし、Docker環境とVSCodeが整えば開発ツール系が一式揃ってしまうので、すごい時代になったなぁと感じずにはいられませんね。

と、ここまでをブラックフライデー直後の土日あたりに記事で公開する予定だったんですが、なんだかんだ年を越してしまいましたw今見たらAmazonで買ったパーツ類がブラックフライデー当時より安くなってて悲しくなっています。

Visa LINE Payクレジットカード(P+)を作りました

実は昨年2022年の12月に「Visa LINE Payクレジットカード(P+)」というものを作りました。今回はこのクレジットカードの紹介をしたいと思います。

Visa LINE Payクレジットカード(P+)とは?

「Visa LINE Pay クレジットカード・ポイントプラス」と読みます。数年前に常時2%還元という狂った還元率をたたき出していた「Visa LINE Payクレジットカード」と名称は似ていますが、別のクレジットカードになります(ややこしい!)

www.smbc-card.com

「Visa LINE Payクレジットカード」はこちら → Visa LINE Payクレジットカード|クレジットカードの三井住友VISAカード

別のクレジットカードに当たりますので、以前「Visa LINE Payクレジットカード」を作った人もこのクレカを申し込んで恩恵を受けることができます。

Visa LINE Payクレジットカードと重複して持つことが可能(2023年1月時点)。画像はhttps://www.smbc-card.com/nyukai/affiliate/lpay/index2.jsp より引用

メリット

このクレジットカードのメリットは何といってもLINE Payでのチャージ&ペイ支払いで5%還元を受けることができることです。(それ以外はちょっと思いつかない・・)

ポイント還元は最大5%(LINE Payチャージ&ペイ利用時)。画像はhttps://www.smbc-card.com/nyukai/affiliate/lpay/index2.jsp より引用

LINEポイントはLINE証券での株購入に充てられるなど消化も容易で便利なので積極的に貯めているポイントの1つです。

カードが届いた!

申し込んでから1~2週間ほどで物理カードが届きました。審査が通った時点でVPassアプリからカードの番号自体は参照できるので、その日からLINE Payで「チャージ&ペイ」に利用することができます。

左:Visa LINE Payクレジットカード(P+)。右:Visa LINE Payクレジットカード

カード番号もカードの裏面に記載されているタイプ(ナンバーレスではない)で、ほぼVisa LINE Payクレジットカードと同じデザインです。表面に「Point+」と書いてあるぐらいでしょうか。カードの色は選べますが、LINE Payでしか使わないことを考えて、LINE Payっぽい緑を選んでみました。(まぁ持ち歩かないので外に出す機会も少ないんですが)

使ってみた感想

審査が通ってVPass上でカード番号が確認できたので、LINE Payに紐づけて使ってみました。ここら辺の操作は公式が手順を示してくれるのでとても楽でした。

LINE Payチャージ&ペイで使ってみた例

↑こんな感じで、横浜のガンダムファクトリーで使ったり、スーパーで使ったりしています。PayPayが使用可能な場所なら結構LINE Payも導入されていることが多いので(たまにLINE Payはやってないことがあるけど)、使用可能な範囲は広いと思います。

とはいえ、最大のメリットである「チャージ&ペイで5%還元」は500ポイントまでという上限が設定されているため、一か月での使用は1万円以内に抑えておく必要があり、使えるからと言ってバンバン使っていると簡単に上限を突破してしまうので注意が必要です。

このカードの使い道

自分はポイントを貯めるのが好きなので、いろんな決済方法を使い分けていますが今回の「Visa LINE Payクレジットカード(P+)」はQUICPayが使えない店舗での使用 をメインにしていこうかなと考えています。優先順位は以下の感じ。

  1. MI CARD ゴールド QUICPay
  2. Visa LINE Pay クレジットカード(P+)
  3. d払い・PayPay
  4. JQエポスカード交通系IC
  5. Revolut

やはりMICARDのQUICPayが最強ですね。上限も5万円利用までと普段使いで不便しない程度に使えますし、貯まるエムアイポイントの使い勝手も途方に暮れるものではありません。MICARDのQUICPayについて書いた内容については以下の過去記事を参照してください。

ohayoyogi.hatenablog.com

とはいえ、QUICPayが使えないケースに遭遇することもあるにはあるので、そういうケースにハマるかなと思う次第です。

終わりに

正直「年間6000ポイント(12×500ポイント)のためにクレカ作る…?」感があるにはあるんですが、QUICPayが使えず取りこぼすポイントを減らしたい気持ちから作ってしまいましたw

Visa LINE Payクレカ(P+)作るとポイントもらえるサイトもあるのでよかったら使ってみてください↓

その買うを、もっとハッピーに。|ハピタス

azure-functions-core-toolsをLinux arm64でも使いたいのでビルドする

devcontainerを使ってAzure Functionsを使用したWebアプリの開発をしたいと思いましたが、Microsoftが提供しているコンテナイメージは x86_64 のみの提供となっており、ARM64なLinuxマシンで開発したい!というケースで使えないという問題が発生しました。

https://hub.docker.com/_/microsoft-azure-functions

ARM用のバイナリをビルドしよう

幸い、azure-functions-core-toolsはオープンソースであり、ソースコードが公開されています。

github.com

build.sh を参考にビルドしてみます。

dotnet build Azure.Functions.Cli.sln
dotnet publish src/Azure.Functions.Cli/Azure.Functions.Cli.csproj --runtime linux-arm64 --output /tmp/cli

/tmp/cli/func というファイルが生成されて、実行できることが確認できればOKです。

Dockerfileでビルドしてみる

と、ここまでで一旦ビルドして使えるものができてしまったわけなのでこれで完成、でもよいのですがこれでは芸がないのでDockerfile内でビルドして本命のDockerコンテナ内で使えるようにしていきたいと思います。

手順としては、

  • dotnet sdkが使用可能なコンテナ内でビルドする
  • ビルドしたバイナリを本命コンテナイメージ内にコピーする

といった感じです。本命コンテナイメージ内ではdotnet sdkを使用できる必要はないので、マルチステージビルドを行います。

Dockerfile

いきなりですが、Dockerfileです。

FROM mcr.microsoft.com/dotnet/sdk:7.0 AS builder
RUN git clone https://github.com/Azure/azure-functions-core-tools
RUN cd azure-functions-core-tools \
    && dotnet build Azure.Functions.Cli.sln \
    && dotnet publish src/Azure.Functions.Cli/Azure.Functions.Cli.csproj --runtime linux-arm64 --output /usr/local/src/azure-functions-core-tools/cli

# You can use any other container image 
FROM node:16-bullseye
COPY --from=builder /usr/local/src/azure-functions-core-tools /usr/local/src/azure-functions-core-tools
RUN ln -s /usr/local/src/azure-functions-core-tools/cli/func /usr/local/bin/func

今回のスクリプトDockerfile for building azure-functions-core-tools for linux-arm64 ( for nodejs ) · GitHub で公開しています。

やっている内容としては、mcr.microsoft.com/dotnet/sdk:7.0 のコンテナイメージをbuilderとして名付け、Azure Functions Core Toolsをビルドさせ、本命のnode:16-bullseye 内にコピーさせ/usr/local/binにシンボリックリンクを貼るという感じです。

node:16-bullseye としているところは別のコンテナイメージでも大丈夫なはずです。今回はJavascriptを使用したAzure Functionsだったのでnodeのイメージを使用しましたがpythonの方はpythonで良いですし、他のコンテナ使う人は他でも大丈夫です。

終わりに

以上、Azure Functions Core ToolsをARM64なLinuxでビルドして使ってみるという内容でした。今回のDockerfileを使うことでDev Containersを使ったAzure Functionsの開発がARM64(aarch64)なLinuxでもやりやすくなりますね。

今回のビルドは「とりあえず動くようにしてみた」レベルの内容で、特にテストが通ったとかそういうわけでもないので何か問題が起こるかもしれません(当方はfunc startでHTTP Handlerが動作することを確認した程度です)。

理想としてはazure functions core toolsのコンテナイメージがマルチアーキテクチャlinux-amd64対応になってくれると良いのですが、コンテナイメージのコードを読むとマルチアーキテクチャの差分はaptで吸収しているのでapt側で先に取り込まれる必要がありそうです。

とはいえ、Issueは立っているしApple M1の対応はなされているのでLinux ARM64版がリリースされるのも時間の問題かなと思いますが…

Release for aarch64 · Issue #3112 · Azure/azure-functions-core-tools · GitHub

良いお年を

晦日にこれを書いていますが、なんとか2022年中に動かして書くことができました。来年もものづくりをする一年にしたいと思います。 みなさんも良いお年をお迎え下さい!