無気力生活 (ノ ´ω`)ノ ~゜

脱力系エンジニア。てきとーに生きてます。

急にV言語のことを思い出した

今日TwitterのTLで観測したこれを見ていたんですね。

github.com

RustやElixir、最近よく見るようになった言語の情報が増えると、このようないいとこ取りを目指した言語が生まれるなーと考えておりまして、ふと、「そういえばGoが爆発的に流行っていたときにいたな、V言語」と湧き出たんですね。

以前取り上げたことがありました

gdgd-shinoyu.hatenablog.com

一年前とちょっと。このときはまだv0.1.0という出たばかりの頃で、まだそこまで使える雰囲気がなかったんですが、今では立派にv0.1.29。かなり現実的に使えるようになってきたような印象です。

以前、これの使い勝手を調べようと思っていたんですが、ちょうど転職やらなんやらで忙しかった時期で、全くもって触れていなかったので、せっかく思い出した手前ではあるので、すこしずつ触っていこうかなと思っています。

触るにあたって、以前はまだうまく動かせなかったv/uiで遊んで見ようかなと。

導入

v/uのgithub見ると、パッケージ管理の仕組みを持っていることがわかります。

v up
v install ui

なるほど、そういう言語なのね。

cannot compile `/home/shinoyu/vlang/v/cmd/tools/vpm.v`:
==================
/tmp/v/vpm.tmp.c:562:10: fatal error: openssl/rand.h: No such file or directory
  562 | #include <openssl/rand.h>
      |          ^~~~~~~~~~~~~~~~
compilation terminated.
...
==================
(Use `v -cg` to print the entire error message)

うーん(´・ω・`) まずは素直に依存関係を解決させるため、公式を覗きます。

Dependencies
Binaries built with V UI will have no dependencies.
To develop V UI apps, you need to install V. This takes a couple of seconds.
On some Linux distros you also need libxi-dev and libxcursor-dev.

とあるのでサクッとaptで導入します。んで、再実行すると.....

 openssl/rand.h: No such file or directory

まあ、そうですよね。入ってないですよね。 OpenSslが文句を行っているので、おとなしくlibssl-devもインストールしておきます。

そして再実行すると、

# v install ui
Creating /home/shinoyu/.vmodules/ ...
Installing module "ui" from https://github.com/vlang/ui to /home/shinoyu/.vmodules/ui ...

これでuiライブラリの導入がサクッとできました。後は時間見つけて触っていくようにしないと....

Chronyを用いたNTPの時刻同期について

時刻が同期されてません(´・ω・`)

前回こんなの書きました。 gdgd-shinoyu.hatenablog.com

設定が不足しており時刻同期ができていないことが発覚しました。 追加の設定について記載していきます。

slewモードへの切り替え

前回の記事でデフォslewとか言ってましたが、設定次第でした。

# makestep 1.3 < コメントアウト
leapsecmode slew

これでOK。

強制的に時間をあわせる

chrony -a makestep

実行すると 501 Not authorised

sudoしてないだけでした(´・ω・`) sudoしてOK。

ハードウェアクロックの同期

chrony -a trimrtc

これもsudo必要

同期

# date
Wed 23 Sep 2020 08:29:19 AM JST

よし

WSL2(Ubuntu)でのNTP設定 と WSLでのSystemd利用の話

時間がずれていてapt updateできないんだが( ゚д゚)

# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.1 LTS
Release:        20.04
Codename:       focal

開発機用途で買ったLenovo T14、ようやく開発用に環境を整えようと思い、数週間ぶりにWSLを立ち上げたんですよ。

時間がずれていて、apt updateができない問題が発生するんですねぇ(´・ω・`)

調べてみた感じ、デフォでNTP設定がされていないようで少しずつずれていくそうです。地味にこまる。メインマシンの方は結構前にNTP設定した記憶ありますがもはや忘却の彼方。ひとまず最初から時間設定合わせていくことにします。

現状のハードウェアクロックを確認

ハード側の時間設定がどうなっているかを確認します。

sudo hwclock --show

ここでずれていたら別途対応が必要になったかもしれません。 今回は特にズレがなかったので、このままでOK。

ずれている時間を合わせる

date --set "指定時間" 設定によってはsudoが必要になります。

時間は分単位まで合っていれば特に問題はなかったのでざっくりと合わせます。

ntpはデフォで入っていない

みたいです。 ntpd --versionってしても、そんなコマンドねぇって怒られました(´・ω・`)

そのままntpdいれてもいいんですけど、今回はchronyを試すことにします(Redhat系だと最近はこっちらしい)

sudo apt install chrony
# chronyc -v
chronyc (chrony) version 3.5 (+READLINE +SECHASH +IPV6 -DEBUG)

これでOK。

ntpの設定を変更する

chronyの設定は/etc/chrony/chrony.confにあった。 設定は、これ見るのが一番参考になる。

access.redhat.com

chornyはデフォでslewモードで動くため、NTPサーバーの設定だけ変更しておくと良さそう。

日本のntpサーバーに向けさせる

初期値では、ntp.ubuntu.com、もしくはubuntu.pool.ntp.orgが設定されていますがレイテンシ影響などもあり精度がいまいちなので、日本時間に合わせるので国内サーバーを使いましょう。

CloudFlareは割といいらしい。セキュリティを重視しているらしい。 blog.cloudflare.com

これと、MFEEDあたりを使うと良さげかも。 www.mfeed.ad.jp

下記だけは、1時間あたりのアクセス数が一定を超える場合申請が必要らしい。使うときは少し気をつけたほうがいいかもしれない。 日本標準時(JST)グループ

もちろん、初回起動時の速度改善を期待するためにiburstオプションもいれておく

最終的にこうなった

pool time.cloudflare.com   iburst
pool ntp.jst.mfeed.ad.jp   iburst maxsources 3
pool ntp.ubuntu.com        iburst maxsources 4

あとはsudo service start chronyとすればOK。

サービスが立ち上がっていればchronyc trackingとすれば同期の状態を見ることが出できます。

サービスの常駐設定

WSL2の場合、systemctlが使えない(´・ω・`)

snowsystem.net

理由も解決方法も上の記事掲載されているのですが、systemctl使えないと自動起動ができないわけで、頑張ってservice startするスクリプトを用意しないといけない(´・ω・`)そんな面倒なことはしたくないわけですね。

上の記事の内容に従ってsystemctlを使えるようにしましょう。

install genie

GitHub - arkane-systems/genie: A quick way into a systemd "bottle" for WSL

sudo apt install daemonize

wget -O - https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor -o microsoft.asc.gpg
sudo mv microsoft.asc.gpg /etc/apt/trusted.gpg.d/
wget https://packages.microsoft.com/config/ubuntu/20.04/prod.list
sudo mv prod.list /etc/apt/sources.list.d/microsoft-prod.list
sudo chown root:root /etc/apt/trusted.gpg.d/microsoft.asc.gpg
sudo chown root:root /etc/apt/sources.list.d/microsoft-prod.list
sudo apt-get update && \
  sudo apt-get install -y dotnet-sdk-3.1

curl -s https://packagecloud.io/install/repositories/arkane-systems/wsl-translinux/script.deb.sh > script.sh
sudo bash script.sh
sudo apt install systemd-genie

インストールするとgenieコマンドが使えるようになるので、

genie -s

とすると、systemdをpid=1にした状態でシェルを立ち上がります。tmuxを使う場合、tmux立ち上げ前に実行しておけばセッション側でも状態が引き継がれていることを確認できました。

# ps aux | grep systemd
root           1  1.5  0.1 107904 13076 ?        Ss   17:51   0:00 systemd

あとは起動時に立ち上がるように設定してあげればOK。

注意点

systemctlが動くようにはなったが、もともとwsl側でpid=1で動かしていたinitプロセスが動かなくなります。 それによって windows側の環境変数が引き継がれなくなりパスが参照できなくなる現象を確認しています。よくWSL経由でWindowsコマンドを使う人(例えばvscodeを開く code など)はそのへん意識して対応すると良さそう。

ちなみに、自分はいろいろ困るケースがでてきてしまったので、X環境整えるまではgenie使わずserviceコマンドで頑張る方針を選びました(ヽ´ω`)

MYSQL8.0で作成したDBにCakePHPからアクセスできないときに確認しておくこと

ちょっと他の方のCakePHPコードを動かす機会が合ったんですが、微妙に詰まったので記録しておく。 DockerでサクッとMySQL8とCakePHP4系の環境を立ち上げたんですよ。でmigrateするじゃないですか。こうなるんですよ

2020-06-28 03:26:02 Error: [InvalidArgumentException] There was a problem connecting to the database: SQLSTATE[HY000] [2054] The server requested authentication method unknown to the client in /var/www/html/mycakeapp/vendor/robmorgan/phinx/src/Phinx/Db/Adapter/PdoAdapter.php on line 82

はい(´・ω・`)

認証できないってやつですね。もちろんUSER/PASSは同じであることを確認済み。
しかし、ついでに入れていたPHPMyAdmin側では認証が通る。とても不思議。MySQL側のコンテナに入ってログインしてみても通る。
ここまでで「これはPHP環境に問題があるのだろう」と特定して深堀り。

まず、php側のDocker環境に入り、iputils-pingを入れて疎通をみる。OK、疎通している。 次に、mariadb_clientを入れてつなぎに行こうとすると

ERROR 1045 (28000): Plugin caching_sha2_password could not be loaded: /usr/lib/x86_64-linux-gnu/mariadb19/plugin/caching_sha2_password.so: cannot open shared object file: No such file or directory

なるほど。caching_sha2_passwordが設定されているユーザーになっているのが原因っぽそう。


ちょっと調べてみたところ、MYSQL8.0からデフォルトの認証プラグインが、caching_sha2_passwordに変わっているんですが、PDO_MySQLを使う場合この認証方式を使えない模様。 https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-compatible-connectors

で、接続しようとしていたユーザーはcaching_sha2_passwordを使う設定になっていたため、USER/PASS合っても弾かれる問題が起こっていたようです。 PHPMyAdmin側でユーザー設定変えてやれば、ちゃんと疎通できるようになりました。

Terraform: s3をbackendに使う際にcredentialsをどう使うか

docker上でTerraform + aws cliの環境を作ってやってます 認証情報はshared-credentialで管理している。環境変数でもいいんですが、個人的にはcredential派。

んで、 s3をバックエンドにしてterraform initしようとしたらこうなる。

Error: No valid credential sources found for AWS Provider.
        Please see https://terraform.io/docs/providers/aws/index.html for more information on
        providing credentials for the AWS Provider

エラーの内容的に認証情報が解決できないらしい。特に指定なしだと対した情報が拾えないので、TF_LOG=TRACE terraform initとしてログをみたりしていた。

結論はprofileの指定がないこと。 https://www.terraform.io/docs/providers/aws/index.html を見る限りAWS_PROFILEで渡しても良いらしいんですが、都度都度書きたくないんですよね(´・ω・`)

結論、backend側設定書いてやれば動いた。

terraform {
  backend "s3" {
    bucket = "bucket_name"
    key       = "tf-saved-path"
    region  = "us-east-1"
    profile  = "profile_name" # これ
  }
}

Terraform has been successfully initialized!

良し(`・ω・´)

唐突にWSL2が[4294967295]をはくようになった

結論

さあ今すぐ、Windows Updateだ。

起きたこと

WSL 2
[プロセスはコード 4294967295 で終了しました]

朝起きてさて開発しようかとPCを起動し、「あれ? WSLターミナル落ちてるじゃん、起動しなおすか」から出てきた以上。 夜あれだけ元気に動いていたのに(´・ω・`)

ちなみに何度立ち上げてもだめ。普通にPowerShell側から呼び出しても、WSLという文字列だけ残して無反応。
再起動も試したが再現する。これじゃ仕事に差し支えるので調査を開始

調査

ここで使うのは、エラーコード。特徴あるコードだからすぐ見つかるだろうとググると即出る。

github.com

しかし内容を見ると、今年の2月3月あたりの話であって、今起きている問題とは関係ない気がする。
以下のコマンドが解決策として提示されていた。

I fixed same problem by "netsh winsock reset"

コマンド的にはWindowsが持っているSocket通信用ライブラリの、TCP/IP接続のリセットであることが分かったので、適当に叩いてもOKだろうととりあえず実行する。実行後、通知に促されるまま再起動。


しかしダメー
ヾ(:3ノシヾ)ノシ


再度調査に戻る。

WSL用のLinuxカーネルの提供方法が変わるらしい

そして見つけた以下の記事。

japan.zdnet.com

 Microsoftは米国時間6月10日、「Windows 10 Insider Preview Build 19645」を「Windows Insider」プログラムの「Fast」リング向けに公開した。このビルドでは、「Windows Subsystem for Linux(WSL)2」用のLinuxカーネルがOSイメージから削除されている。

なるほど。タイミング的にこれが当たってしまったらしい。
イベントビューワーでWindows Updateのログを見てみる。

情報   2020/06/13 4:09:31  WindowsUpdateClient 41  Windows Update エージェント
- EventData 
  updateTitle Windows 10 Insider Preview 19645.1 (mn_release) 
  updateGuid {3e1470ab-9107-460a-87ad-f801336beb4a} 
  updateRevisionNumber 1 

確かに当たってるな。

記事を見る限りだと、

カーネルを最新の状態に保つことを確実にするために、そのアップデートを他のドライバーのアップデートと同様に「Windows Update」経由にするという考え方に基づいている。

とある。つまりWindows Updateで落ちてくる可能性が高いことを示す。Windows Update開いて更新をチェックすると1つヒットしたものがあるらしい。適用して再起動。

f:id:gdgd-shinoyu:20200613152044p:plain
生き返ったWSL

よしきた( ゚д゚)

結局何を入れなければいけなかったのか

動作するようになったとき、何が反映されたかをチェックしておく。

情報   2020/06/13 14:43:58 WindowsUpdateClient 41  Windows Update エージェント

- EventData 
  updateTitle Windows Subsystem for Linux Update - 4.19.104 
  updateGuid {d995d77f-fc67-467b-bcbd-950ea217623d} 
  updateRevisionNumber 200 

確かにLinuxの何らかの変更が落ちてきていた。 お前だったのか。

Docker上のruby:alpineにて、bundlerがrails-assets.orgに繋がらなくなっていた

タイトルどおりではあるが、急にbundlerが外部と疎通できなくなっていた(´・ω・`)

ほんの数日前までは特に問題なく動いていたんですが、さて個人の仕事をやらねばなと腰をあげたところ食らってしまい、起きているのがシンドい時間まで突入してしまいました。

環境はWSL2 Ubuntu上の、ruby:2.6.2-alpine docker-compose run --rm {service} bundle installで動かすと発生しました。

Retrying fetcher due to error (2/4): Bundler::HTTPError Could not fetch specs from https://rails-assets.org/

うーむ。まあエラーの内容通り外部と疎通できないのが要因だろうけれども。curlなりpingなり、存在しているところに飛ばしてもbad accessが発生してる。
調査のためにdigいれようと、apkでbind-toolsを引っ張ろうとしてもコケるので、コンテナ内部でなにか名前解決に問題が発生しているような気がしている。あ、IPアドレスで疎通できるかの確認してなかった(´・ω・`)

どちらにせよ、bundleの問題ではないと判断。まあこういうときは一度コンテナをビルドし直すと解消することがこれまで多かったので、今回もザクッとつくりなおしてみることにした。

docker-compose build --no-cache {service}

実行するとすくなくともapkは正常に走っていることがわかる。コンテナ内部の問題ではなさそう

doker-compose run --rm {service} bundle install

どうやら正常に名前解決できるようになった模様。

Bundle complete! 63 Gemfile dependencies, 150 gems now installed.
Bundled gems are installed into `/usr/local/bundle`

原因が不明だとちょっと気持ち悪い(´・ω・`)


いろいろと調べてみると、resolve.confにnameserver 8.8.8.8すると解決するという話がちらほらとあるわけで。名前解決になにか問題があることは理解したんですが、なぜ急に動かなくなったかは不明でした。

ちょっと深堀りしてみたら、ひとつ気になるものを見つけたんですが。
https://qiita.com/frost-tb-voo/items/fcc0c0fe7561b9101bf4

何も設定していない状態の dockerd では,ホストの /etc/resolv.conf をマスク(上書き)したファイルがコンテナ内部の /etc/resolv.conf として mount される.

WSL2では、resolve.confにはWSLホストであるWindowsIPアドレスが入ってるんですよね。確か。WSLでX Window試してみたことある人はわかると思うんですが、WSL起動ごとにこのresolve.confのIPアドレスが変わるわけですよ。
https://qiita.com/SoraKumo/items/388a1315a6bdc16b4d2e


つまり、dockerのコンテナ生成したタイミングでは、その時のWSL側のresolve.confがコピーされて使われる。しかし、WSLを起動し直すなどしてWSLのIPが変わってしまうと、その場合でもDockerのコンテナ側のresolve.confには古いIPが記録されており、ここに名前解決をしにこうとする。当然そのIPで応答するやつはいないので、解決できずに死ぬ。という動きが考えられるかもしれない。

普段再現しないのは、そもそもWindowsPCを終了することがほとんどなく、スリープ運用しているからで説明はつく。


まあ、状況から考えた仮説でしかないので、実際に何が問題としてあったかはわからずじまい(´・ω・`) 先にnameserver 8.8.8.8追加を試すべきだった。

まあ仮説どおりだとするとまた再現しそうな気はしているので、その時調べればいいかなというお気持ちです。