「WSL」の記事 - Crieit

【WSL】ユーザアカウントにログインできなくなった場合の確認と対処方法

2023-10-29T22:01:49+09:00

こんにちは、しきゆらです。
今回は、WSL起動時に初期設定したユーザでログインできなくなったので、調べたり対応したことをメモしておきます。

WSLのインストール時にユーザアカウントを作成しますが、いつの間にかユーザアカウントへログインできずにrootとしてログインしてしまう状況になっていました。
何が起こっているのかわからなかったので、諸々も調べてユーザアカウントとしてログインできるよう修正したのでメモしておきます。

WSLはWindows Subsystem for Linuxという通り、動いているのはLinuxになります。
なのでLinuxコマンドや各ファイルをもとに確認していきます。

作業の流れ

ざっと流れを記載しておくと以下の通りです。

現在ログインしているユーザを確認する
ユーザアカウントの有無を確認する
デフォルトのログインユーザを指定する
指定したユーザでログインできるか確認する

では、それぞれを見ていきます。

現在ログインしているユーザを確認する

ほぼログイン時のパスなどでわかると思いますが、念のため書いておきます。
whoamiコマンドで確認すると以下のように表示されます。

> whoami
root

コマンド名の通り、現在のユーザを確認するコマンドになります。 rootとなっていれば大本の管理アカウントなので、普段使っているユーザアカウントとは異なっていることがわかります。

ユーザアカウントの有無を確認する

続いて、これまで使っていたユーザが残っているのかどうかを確認してみます。
これはコマンドではなく/etc/passwdファイルにまとまっているので、中身を確認してみます。
このファイルには、ユーザ以外にもデーモンなど裏側で作られているものも含まれているので、grepコマンドでほしい情報があるかを絞ったほうが見やすいです。

# 全体の確認
> cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
...

### これまでのアカウントがあるかどうかを確認する場合
> cat /etc/passwd | grep <ユーザ名>
# ファイルの中にユーザ名が含まれていればその行が表示され、含まれていなければ何も表示されません

grepしてユーザ名が書かれた行がなければ、/home/<ユーザ名>のディレクトリを確認し必要なファイルのバックアップを取ったうえで初期化したほうが良いかもしれません。

私の場合は、このファイルにユーザ名の行があったので以下の手順で復帰しました。

ログインするユーザを指定する

上記でユーザが残っていることはわかったので、ログインするユーザを明示してあげます。
記載するファイルは/etc/wsl.confで以下のように記載します。

# 以下を追記
[user]
default=<ユーザ名>

# ログイン時にWindowsのパス情報を追加したくない場合は以下も記載
[interop]
appendWindowsPath = false

上記を記載したら、念のためWSLの再起動をしてあげた後にログインしてみましょう。
PowerShellからWSLを止めます。

# PowerShellからWSLをシャットダウンする
> wsl --shutdown

指定したユーザでログインできるか確認する

WSLを一度シャットダウンしたので、該当するディストリビューションへログインましょう。

# wslを立ち上げてログインする
> wsl -d <ディストリビューション>

# whoamiコマンドで意図したユーザとしてログインできているかを確認する
> whoami
<ユーザ名>

無事に指定したユーザでログインできれば、修正完了です。

rootのままだった場合は、ユーザの指定を間違えていないかを確認してみてください。
解消しなければ「ユーザアカウントの有無を確認する」のところにも記載していますが、バックアップを取ったうえで初期化したほうが安全かと思います。

今回は、WSLのログインがrootになってしまったので修正方法を調べつつまとめました。
私の場合は、たまたま今回はアカウントが残っていたので無事に修正できましたが、アカウントそのものが残っていない場合は復旧が難しいかもしれません。
その場合は、できるだけ必要なファイルをバックアップしたうえで初期化するしかないかと思います。
幸い、WSLの初期化は簡単なので使える状態にするには時間がかからないかと思います。

参考情報としてLinuxディストリビューションの登録解除の方法を置いておきます。

WSL の基本的なコマンド | Microsoft Learn https://learn.microsoft.com/ja-jp/windows/wsl/basic-commands#unregister-or-uninstall-a-linux-distribution

今回は、ここまで。

おわり

【WSL2】systemdがサポートされたようなので試してみた

2022-11-19T08:32:00+09:00

ここ数年はWindowsの環境をクリーンインストールするたびにWSL2の環境を作り直し、その度にgenieを使ってsystemdをPID 1 にするための方法をメモしてきました。
【WSL2】systemctlが動かない問題をきちんと解決する
 【WSL2】Ubuntu20.04でPID1をSystemdにする
 【WSL2/Ubuntu】systemdをPID1で動かす 2021年3月版

しかし、気が付いたらWSL自体がsystemdをサポートしたようなので、WSLだけでsystemdをPID 1にしてみたのでメモしておきます。

詳しいことは公式ブログを参照ください。
Systemd support is now available in WSL!

設定手順

公式ブログによると、WSLのバージョンが0.67.6以上で使えるとのこと。
なお、手元のWSLのバージョンを確認するとすでに1.0になっていたのでだいぶ前から使えたんだなぁともっと早く気づきたかった気持ちでいっぱいです。
確認するためのコマンドは以下の通り。

powershell > wsl --version
WSL バージョン: 1.0.0.0
カーネル バージョン: 5.15.74.2
WSLg バージョン: 1.0.47
MSRDC バージョン: 1.2.3575
Direct3D バージョン: 1.606.4
DXCore バージョン: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windowsバージョン: 10.0.22621.819

なお、WSLの更新もwslコマンドでできるようになったようなので、バージョンが古い場合は以下のコマンドで更新すればよい。

powershell > wsl --update

次に、WSL環境にwsl.confというファイルを作成し、以下を書き込む。

wsl(Ubuntu) > sudo emacs /etc/wsl.conf
# 以下を追記
[boot]
systemd=true

書き込んだらWSL環境を再起動。
これにて準備完了です。

powershell > wsl --shutdown

この後、WSL環境に入りsystemctlを動かしてみます。
以下のようにエラーが起きずにつらつら表示されたらOK。

wsl(Ubuntu) > systemctl
UNIT                                                                                                                                                                      LOAD   ACTIVE SUB       DESCRIPTION                                            >
sys-devices-LNXSYSTM:00-LNXSYBUS:00-ACPI0004:00-VMBUS:00-0fd20160\x2d7ac7\x2d4158\x2d9e38\x2d8685d280c3a6-net-eth0.device                                                 loaded active plugged   /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0004:00/VMBUS:>
sys-devices-LNXSYSTM:00-LNXSYBUS:00-ACPI0004:00-VMBUS:00-ba31a026\x2d5b46\x2d4a8d\x2da6dc\x2df00324cf1e90-pci5b46:00-5b46:00:00.0-virtio0-virtio\x2dports-vport0p0.device loaded active plugged   /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0004:00/VMBUS:>
sys-devices-LNXSYSTM:00-LNXSYBUS:00-ACPI0004:00-VMBUS:00-fd1d2cbd\x2dce7c\x2d535c\x2d966b\x2deb5f811c95f0-host0-target0:0:0-0:0:0:0-block-sda.device                      loaded active plugged   Virtual_Disk
sys-devices-LNXSYSTM:00-LNXSYBUS:00-ACPI0004:00-VMBUS:00-fd1d2cbd\x2dce7c\x2d535c\x2d966b\x2deb5f811c95f0-host0-target0:0:0-0:0:0:1-block-sdb.device                      loaded active plugged   Virtual_Disk
sys-devices-LNXSYSTM:00-LNXSYBUS:00-ACPI0004:00-VMBUS:00-fd1d2cbd\x2dce7c\x2d535c\x2d966b\x2deb5f811c95f0-host0-target0:0:0-0:0:0:2-block-sdc.device                      loaded active plugged   Virtual_Disk
sys-devices-platform-serial8250-tty-ttyS0.device                                                                                                                          loaded active plugged   /sys/devices/platform/serial8250/tty/ttyS0
sys-devices-platform-serial8250-tty-ttyS1.device                                                                                                                          loaded active plugged   /sys/devices/platform/serial8250/tty/ttyS1
sys-devices-platform-serial8250-tty-ttyS2.device                                                                                                                          loaded active plugged   /sys/devices/platform/serial8250/tty/ttyS2
sys-devices-platform-serial8250-tty-ttyS3.device                                                                                                                          loaded active plugged   /sys/devices/platform/serial8250/tty/ttyS3
  ...

まとめ

今回は、WSLがsystemdをサポートしたということで設定してみました。
今後はgenieを入れずともWSLだけでsystemdを使えるので、より手軽に環境を使えるようになりました。

今回は、ここまで。

おわり

【WSL】WindowsでUbuntuを検証したいときによく使うコマンド

2022-11-10T10:08:52+09:00

確認済み環境

Windows 11 22H2

Ubuntuをインストール

管理権限で起動したコマンドプロンプトかPowerShellで実施、WSL未導入の場合は再起動（バックグラウンドでWSLを導入するため、ハイパーバイザーや仮想マシンプラットフォーム機能などが有効化されるため）が必要です。再起動後Ubuntuが起動するのでID/PWの設定を行います。

> wsl --install -d Ubuntu

インストール状況を確認する

管理権限で起動したコマンドプロンプトかPowerShellで実施、インストールされたディストリビューション名や状態、WSLバージョンが確認できます

> wsl -l -v

Ubuntuをエクスポート

管理権限で起動したコマンドプロンプトかPowerShellで実施、他のPCに環境を移動したい時に使います

> wsl --export "ディストリビューション名（例：Ubuntu）" "エクスポートファイル名（例：Ubuntu_export.tar）"

Ubuntuをインポート

管理権限で起動したコマンドプロンプトかPowerShellで実施、WSLを導入していないPCの場合は事前に導入が必要です（私の環境ではWSL未導入だと--importオプションが使えませんでした）

> wsl --import Ubuntu "インポート先のフォルダ名（例：c:¥wslimg→フォルダがない場合は自動で作られる）" "エクスポートファイル名（例：Ubuntu_export.tar）"

VPN に繋ぐと WSL2 や Hyper-V VM でネットワークに繋がらなくなる問題を解消する

2021-01-27T09:33:58+09:00

OpenVPN や Cisco AnyConnect, GlobalProtect 等といった VPN に接続した際、 Hyper-V 仮想マシン内からや、 WSL2 のディストリビューション内、 Windows Sandbox 内、 WSL2 ベースの Docker コンテナ内等々、 Hyper-V 系の技術を使った仮想環境から、 PC 外のネットワークにアクセスしようとすると、以下のようなエラーが発生して失敗する。

$ # curl 利用時の例
curl: (6) Could not resolve host: example.com
curl: (5) Could not resolve proxy: proxy.example.com

$ # apt で更新しようとした場合の例
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/focal/InRelease  Temporary failure resolving 'archive.ubuntu.com'
W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/focal/InRelease  Temporary failure resolving 'proxy.example.com'

エラーの内容からわかるとおり、アクセス先やプロキシーのドメイン名を DNS で解決できなくなっている。

このような問題が発生することは以前から知っていたのだが、このご時世で VPN 使うことが増えてきて、いい加減鬱陶しくなってきたので、なんとかしようと思う。

解決方法

とりあえず、まずは解決方法から。

以前は AnyConnect でもこの方法が使えたはずなのだが、どうやら対策されて打つ手なしになってしまった模様。
今のところ、以下の方法で回避の確認が取れているのは、 GlobalProtect のみだ。

WSL2 の場合は何らかの WSL2 を使ったディストリビューションを立ち上げる。
- WSL 2 based engine が有効になった Docker Desktop を起動するだけでも OK。
- WSL2 を使っていないなら、何もする必要はない。
VPN を接続状態にする。
管理者権限で Windows PowerShell を立ち上げ、以下のコードを実行する。 (GlobalProtect の例)
```
$targetIfName = 'PANGP Virtual Ethernet Adapter';
# define function
function Get-NetworkAddress {
    param([Parameter(Mandatory, ValueFromPipelineByPropertyName)][string]$IPAddress, [Parameter(Mandatory, ValueFromPipelineByPropertyName)][int]$PrefixLength);
    process {
        $bitNwAddr = [ipaddress]::Parse($IPAddress).Address -band [uint64][BitConverter]::ToUInt32([System.Linq.Enumerable]::Reverse([BitConverter]::GetBytes([uint32](0xFFFFFFFFL -shl (32 - $PrefixLength) -band 0xFFFFFFFFL))), 0);
        [pscustomobject]@{
            Addr = $IPAddress;
            Prfx = $PrefixLength;
            NwAddr = [ipaddress]::new($bitNwAddr).IPAddressToString + '/' + $PrefixLength;
        };
    }
}
# extend route metric
$targetAddresses = Get-NetAdapter -IncludeHidden | Where-Object InterfaceDescription -Match 'Hyper-V Virtual Ethernet Adapter' | Get-NetIPAddress -AddressFamily IPv4 | Get-NetworkAddress;
$targetIfs = Get-NetAdapter -IncludeHidden | Where-Object InterfaceDescription -Match $targetIfName;
$targetIfs | Set-NetIPInterface -InterfaceMetric 2;
$targetIfs | Get-NetRoute -AddressFamily IPv4 | Select-Object -PipelineVariable rt | Where-Object { $targetAddresses | Where-Object { $_.NwAddr -eq (Get-NetworkAddress $rt.DestinationPrefix.Split('/')[0] $_.Prfx).NwAddr } } | Set-NetRoute -RouteMetric 6000;
```
- GlobalProtect 以外の場合は、上記コード一行目の 'PANGP Virtual Ethernet Adapter' のところを VPN ソリューションのネットワーク接続アダプタ名に書き換える。
  具体的には、 Win+R で ncpa.cpl を実行して「ネットワーク接続」を開き、該当する VPN の接続のプロパティを開いて、 "接続の方法" のところに書かれた名前 (の一部) を指定する。
  - OpenVPN なら TAP-Windows Adapter とか、 AnyConnect なら Cisco AnyConnect とか。環境によっても違うかも。
- 管理者権限の PowerShell は、スタートボタンを右クリックで簡単に立ち上げられる。
- 1回の実行で成功しない場合、 上記コードの最後の行 を、ルートメトリックが書き換わるまで何度もしつこく実行する。
  - ルートメトリックが書き換わっていない状態の例:
    
```text/plain
$targetIfs | Get-NetRoute -AddressFamily IPv4 | Select-Object -PipelineVariable rt | Where-Object { $targetAddresses | Where-Object { $.NwAddr -eq (Get-NetworkAddress $rt.DestinationPrefix.Split('/')[0] $.Prfx).NwAddr } }

ifIndex DestinationPrefix NextHop RouteMetric ifMetric
------- ----------------- ------- ----------- --------
36 172.30.175.255/32 0.0.0.0 0 0
36 172.30.160.1/32 0.0.0.0 0 0
36 172.30.160.0/20 0.0.0.0 0 0
20 172.18.31.255/32 0.0.0.0 0 0
20 172.18.16.1/32 0.0.0.0 0 0
20 172.18.16.0/20 0.0.0.0 0 0
```
  - ルートメトリックの書き換えに成功した例:
    
```text/plain
$targetIfs | Get-NetRoute -AddressFamily IPv4 | Select-Object -PipelineVariable rt | Where-Object { $targetAddresses | Where-Object { $.NwAddr -eq (Get-NetworkAddress $rt.DestinationPrefix.Split('/')[0] $.Prfx).NwAddr } }

ifIndex DestinationPrefix NextHop RouteMetric ifMetric
------- ----------------- ------- ----------- --------
36 172.30.175.255/32 0.0.0.0 6000 0
36 172.30.160.1/32 0.0.0.0 6000 0
36 172.30.160.0/20 0.0.0.0 6000 0
20 172.18.31.255/32 0.0.0.0 6000 0
20 172.18.16.1/32 0.0.0.0 6000 0
20 172.18.16.0/20 0.0.0.0 6000 0
```
上記を、 PC を再起動したり、 VPN を接続しなおす度に、毎回実行する。

解説

上記のコードは、 VPN プロバイダがホスト PC に作成しているルーティングの設定のうち、 Hyper-V や WSL に関係する宛先ものだけ、ルーティングのメトリックをめっちゃ長くしている。

Hyper-V や WSL のネットワークの仕組みに簡単に触れながら、もう少し細かく説明していこう。

Hyper-V と WSL2 の NAT

まずそもそもの前提として、 ホストPC と WSL2 の仮想環境で異なる IPアドレスを持っている。
利便性のため、 WSL2 の localhost のリッスンが、ホスト PC の localhost へ転送されているなど、 IPアドレスが異なることをあまり意識せずすむような仕組みにはなっているけれども。

そしてその WSL2 や、 Hyper-V の VM では、 PC の外と通信する際に NAT を経由して通信を行う仕組みがメインとなる。

このとき、 Hyper-V や WSL2 のバックエンドとなる Hyper-V ハイパーバイザーは、ホスト PC 上に仮想 NIC を作成する。
そしてその仮想 NIC に、 WinNAT と呼ばれる機能を割り当て、更に WSL2 向けには DNS の機能も割り当てて、ホスト PC の外との通信の中継を担わせるようになっている。

これら、仮想 NIC や、 WSL2 に自動で割り当てられる IP アドレスは、ホスト PC と被らない適当なプライベート IP アドレスが割り当てられる。

なお、 やっかいなことに、この割り当てられた IP アドレスは、起動する度に毎回異なる。

VPN 側の動作

一方のソフトウェア VPN では、 VPN の有効化と同時に、ホスト PC のルーティングを片っ端から書き換えている。

具体的には、 VPN の仮想 NIC に対して短いメトリックとなるよう、ルーティングを書き加える。
それによって、全ての通信が VPN トンネルを通るようになっているのだ。

そして悲劇が起こる

その結果、どうなるか。

ホスト PC からゲスト VM (あるいは WSL ディストロ) のプライベート IPアドレスへ通信しようとすると、 VPN のトンネリング側にルーティングされてしまう。

例えば、 WSL2 からホストPC へ DNS の問い合わせ (クエリ) を受けると、そのレスポンスが明後日の方向にルーティングされてしまう。
これが、 ゲスト側で DNS による名前解決ができなくなる原因だ。

この問題を回避するため、前述のスクリプトでは、ルーティングテーブルを書き換えて、ゲスト VM のアドレスに対して、 VPN の仮想NIC のメトリックを長くすることで、 VPN にルーティングされないようにしているわけだ。

本当は、 VPN へのルーティングを消してしまいたいところなのだが、ルーティングを消しても、 VPN クライアントが即座にルーティングを復活させてしまうため、メトリックを長くするだけにとどめている。

なお、 GlobalProtect でも、書き換えたメトリックを戻される対策がされたようだが、インターフェースメトリックを書き換えたり、短期間に何度も書き換え直したりすると、メトリックを戻すことを諦めてくれる。
このため、上記のようなコードになっている。

WSL2 , problem with network connection when VPN used (PulseSecure) · Issue #5068 · microsoft/WSL | GitHub
ちなみに、上記の Issue ではもっと単純に、 WSL2 へのメトリックは 1 にして、全ての VPN 関係のルーティングのメトリックを 4000 くらいに延ばすワークアラウンドが紹介されている。
しかしそれだと、本来 VPN 経由にしなくてはならない通信までもが VPN 通らなくなったりする場合があって、 VPN を使わせるポリシー上マズい。
このため、上述のように、必要なネットワークアドレスだけに絞ってメトリックを書き換えている。

別解

Microsoft Docs 上の WSL のトラブルシューティングでは、 WSL の /etc/resolv.conf の DNS を、ホストPC の WinNAT ではなく VPN のトンネリング先のネットワークの DNS に書き換える方法も掲載されている。

……が、これを行うと、ゲスト側の DNS の名前解決こそできるようになるものの、依然ホストPC からゲストOS へのパケットが届かない問題は解消されない。
このため、ゲストで立てたサーバーに、ブラウザでアクセスしたり、 ssh 等でログインしたりと言ったことはできないままだ。

更に、イントラネット内で別途 DNS を運用していた場合、イントラネット内の名前解決ができなくなる問題もある。

このため、この DNS を書き換える方法は、望ましい解決方法とは言えない。

改訂履歴

2023-02-22:
- コードの一部でエラーが発生していた部分を修正。
2023-02-14:
- 各社のメトリック書き換え対策に対し、 GlobalProtect 向けにコードを変更し、 AnyConnect 向けには打つ手なしとなったことを追記。
2021-04-04:
- Windows Sandbox などでも問題となる旨追記
- いくつかの VPN ソフトについての設定例を追記
- Microsoft Docs 記載の改善方法について追記
2021-01-28:
- 仮想ネットワーク上に DHCP は存在しないのに、 DHCP の存在がすると誤記があったので修正。
- スクリプトで Hyper-V の仮想スイッチをさかす際に、 NIC 名ではなくて、ネットワークアダプタの接続名で探すように変更。

WSLのディストリビューションの格納場所の移動

2020-12-26T16:32:04+09:00

WSLでUbuntuをインストールしたものの、Cドライブの容量が心元なかったため、ディレクトリ移動した際の手順を記述します。
``

◆手順

１．ディストリビューションをtarファイルにエクスポート

wsl --export Ubuntu-20.04 F:\Work\wsl\Ubuntu-20.04.tar

２．ディストリビューションの削除

wsl --unregister Ubuntu-20.04

３．ディストリビューションのインポート

wsl --import Ubuntu-20.04 F:\Work\wsl\Ubuntu20.04 F:\Work\wsl\Ubuntu-20.04.tar

構文：
wsl --import ＜ディストリ名＞＜インストールディレクトリパス＞＜１でエクスポートしたtar＞
※ ディストリ名は任意でいいらしい

思ったよりすごく簡単にできた。
３．でディストリ名を任意で設定できるということは、コピーしてディストリ名を別にすれば環境の複製もできるんだろうなぁ。

Windows WSLのUbuntuにGoogleChromeをインストールする

2020-09-20T19:59:37+09:00

Railsで開発をしていてRspecでChromeDriverでのテストを利用しているためChromeが必要になったのでインストール

sudo apt-get update
# 必要なライブラリのインストール
sudo apt-get install libappindicator1 libappindicator3-1 fonts-liberation

# 最新安定版のDL、インストール
curl -O https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
sudo dpkg -i google-chrome-stable_current_amd64.deb

# ここでパッケージの依存関係で怒られたので依存関係の解消
sudo apt --fix-broken install

# 再度インストールを試した
sudo dpkg -i google-chrome-stable_current_amd64.deb

# インストールされていることの確認
google-chrome --version

参考

Proxy 下で vscode の WSL 上の他の拡張機能のインストールに失敗する

2019-10-09T11:22:41+09:00

プロキシ環境下の vscode で、 WSL 上で拡張機能を動かしたいのに、インストールインストールに失敗する問題を解決するメモ。

前回の↓の記事は、『Remote – WSL 拡張が有効にできない』問題だったが、今回は『Remote – WSL 拡張を有効にした後、その環境上で他の拡張機能がインストールできない』問題なのでちょっと違う点に注意。ややこしいね。
https://crieit.net/posts/Proxy-vscode-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) だ。

"Remote [WSL]" 用の設定ファイルを書き換える

Remote – WSL 拡張をインストールすると、 Settings のウィンドウに "Remote [WSL]" というタブが増えている。

そのタブに移動してみると、 Proxy の設定が空欄になっているのがわかる。

"Modified in: User" って書いてあるので、 User タブの内容で上書きされる動作をしてくれそうだったり、設定されてなかったら http_proxy, https_proxy の環境変数の値が使われると書いてあったりしているが、とりあえずその情報は無視。

この "Remote [WSL]" 上のプロキシの設定も、 User タブと同様に改めて記載して保存し、 vscode をリロードしてみる。

その結果、 WSL 上の拡張機能もインストールに成功するようになった！

まとめ

プロキシ環境下で WLS - Remote を使うときは、 Settings の "Remote [WSL]" タブにもプロキシの設定を書こう。
WSL 上の http_proxy, https_proxy の環境変数を設定しただけでは、 vscode の全ての通信をプロキシ経由にするには不十分のようだ。
- VS Code Server for WSL の更新のために、これらの環境変数は設定しておくべき。
- もしかしたら、 Windows 側の環境変数にも上記の値を設定させておけば、本問題が発生しないのかも知れないが、試していない。
vscode のプロキシ環境下の動作の作り込みは、まだまだ甘い。

Proxy 下で vscode の WSL 拡張へ接続できない

2019-10-09T11:02:59+09:00

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](https://code.visualstudio.com/docs/remote/troubleshooting#_wsl-tips)

どう解決したものか。

そもそも wget でダウンロードができる状態なのか

拡張機能の GitHub プロジェクト上の Issue によると、内部的には wget でファイルをダウンロードしているらしい。
https://github.com/microsoft/vscode-remote-release/issues/78
https://github.com/microsoft/vscode-remote-release/issues/79

.bashrc で http_proxy, HTTP_PROXY, https_proxy, HTTPS_PROXY 全ての環境変数にプロキシの URL を設定しているので、 wget に対してプロキシの情報は渡っているはずなのだが。。。

とりあえず WSL を起動して、書き込み権限がある適当なディレクトリで、エラーになっているファイルのダウンロードを wget https://update.code.visualstudio.com/commit:3db7e09f3b61f915d03bbfa58e258d6eee843f35/server-linux-x64/stable で試してみて、成功するか試してみよう。

私の場合、以下のような初歩的なミスでダウンロードに失敗していた。

HTTP_PROXY と HTTPS_PROXY の大文字の環境変数にしか設定しておらず、 wget がプロキシを認識してくれなかった。
curl とかはどっちでもイケるから、気づくのに時間がかかった。
何故か ~/.wget-hsts のパーミッションが 666 に書き換わっていて、 wget のセキュリティエラーでダウンロードに失敗している事があった。
カレントディレクトリが /mnt/c/ になっていて、ダウンロードしたファイルの書き込めなかった。

それでもダウンロードに失敗する

以下の記事によると、 Windows 側から WSL Remote の VS Code Server を起動するとき、 .bash_profile や .bashrc, .profile などを読んでくれないらしい。
https://github.com/microsoft/vscode-remote-release/issues/432
このため、環境変数でプロキシを設定しても反映されないようだ。

以下のどちらかを行うと、この問題を回避できる。

#79#issuecomment-503989625 のコメントのように、 ~/.wgetrc にプロキシの設定を書く。
- http_proxy と https_proxy だけ設定すればよいはず。 check_certificate = off をむやみに設定するのはセキュリティ上良くない。
いったんすべての VS Code を終了させ、 WSL のコンソール上で code と実行し、 Windows の VS Code を起動する。
- このとき、 WSL 側に Linux 版の VS Code がインストールされていると、そちらが起動してしまうのでダメ。

正直、どちらが良いかは一長一短だ。

.bashrc や .wgetrc などあちこちにプロキシの設定を書くと管理が大変だし、
VS Code Server が更新されるたびに WSL 側から VS Code を実行するのは手間だ。

幸い、 #79#issuecomment-504368316 によると、今後のバージョンでは VS Code Server のダウンロードを Windows 側で行うように更新する予定のようだ。
それまでの間は逐一 WSL 側から VS Code を実行する方法で回避するのでも良いかもしれない。

しかし、少なくとも現時点のバージョンである VS Code 1.38.0 + Remote - WSL 0.39.5 の組み合わせでは、そうなっていない。

WSLでWindows側のフォントを使う

2019-03-01T09:57:47+09:00

WSL側で使えるフォントを確認してみると最低限のものしかない。Windows側に入っているフォントをそのまま全部使いたかったのでその方法。

/etc/fonts/conf.dにフォントの設定ファイルがある。そこに下記の設定ファイルを入れる。




    /mnt/c/Windows/Fonts

これでfc-listしてみるとフォントが追加されているのがわかる。（追加されない場合はキャッシュをクリアする）

プログラム側で画像を描画する場合にもフォントが正しく表示されることが確認できた。