急にV言語のことを思い出した
今日TwitterのTLで観測したこれを見ていたんですね。
RustやElixir、最近よく見るようになった言語の情報が増えると、このようないいとこ取りを目指した言語が生まれるなーと考えておりまして、ふと、「そういえばGoが爆発的に流行っていたときにいたな、V言語」と湧き出たんですね。
以前取り上げたことがありました
一年前とちょっと。このときはまだ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
にあった。
設定は、これ見るのが一番参考になる。
chornyはデフォでslewモードで動くため、NTPサーバーの設定だけ変更しておくと良さそう。
日本のntpサーバーに向けさせる
初期値では、ntp.ubuntu.com、もしくはubuntu.pool.ntp.orgが設定されていますがレイテンシ影響などもあり精度がいまいちなので、日本時間に合わせるので国内サーバーを使いましょう。
CloudFlareは割といいらしい。セキュリティを重視しているらしい。 https://blog.cloudflare.com/jp/secure-time-jp/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が使えない(´・ω・`)
理由も解決方法も上の記事掲載されているのですが、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という文字列だけ残して無反応。
再起動も試したが再現する。これじゃ仕事に差し支えるので調査を開始
調査
ここで使うのは、エラーコード。特徴あるコードだからすぐ見つかるだろうとググると即出る。
しかし内容を見ると、今年の2月3月あたりの話であって、今起きている問題とは関係ない気がする。
以下のコマンドが解決策として提示されていた。
I fixed same problem by "netsh winsock reset"
コマンド的にはWindowsが持っているSocket通信用ライブラリの、TCP/IP接続のリセットであることが分かったので、適当に叩いてもOKだろうととりあえず実行する。実行後、通知に促されるまま再起動。
しかしダメー
ヾ(:3ノシヾ)ノシ
再度調査に戻る。
WSL用のLinuxカーネルの提供方法が変わるらしい
そして見つけた以下の記事。
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つヒットしたものがあるらしい。適用して再起動。
よしきた( ゚д゚)
結局何を入れなければいけなかったのか
動作するようになったとき、何が反映されたかをチェックしておく。
情報 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追加を試すべきだった。
まあ仮説どおりだとするとまた再現しそうな気はしているので、その時調べればいいかなというお気持ちです。