Author: Junya Watanabe

Amazon Linux 2へ移行完了

このブログは、Amazon EC2の上にWordPressを乗せて構築しているのですが、Amazon Linuxのサポートが2020/12/31で切れるということで、年末の休みの間に重い腰を上げてAmazon Linux 2への移行をしました。

いくつかハマったポイントがあったのでメモ。

いつも通りyumにepelとremiのリポジトリを追加して、MySQL + php-fpm + nginxの環境をつくろうとしたが、MySQLが入ってくれない。MySQLのリポジトリを追加しても依存関係でうまくいかない。

しばらく頑張ったけど、諦めてAmazonのコアリポジトリにあるMariaDBで構築することにした。MySQLと互換性があるみたいなのでしばらく試してみる。

php-fpmとnginxのブリッジはUNIXソケットを使う派なんだけど、いつも通り/etc/php-fpm.d/www.conf に

listen = /tmp/fpm.socket

を書いてもソケットファイルが作成されない。

CentOS 7以降からsystemdでプロセス管理をするようになり、どうやらSELinuxっぽい感じでセキュリティ対策が施されているらしい。

phpから /tmp にファイルが書き込めない

こちらの記事を参考にphp-fpm.serviceに

PrivateTmp=false

を設定したところ無事/tmp配下にソケットファイルが作成されました。ちなみに、nginxも同様にPrivateTmp=falseにしないとソケットにアクセスできないのでご注意を。

これでずっと個人issuesに上がっていたAmazon Linuxのインスタンスを落とすことができます。

というわけで、2021年もGROOVEをよろしくお願いします。

独り言

ロードバイクに乗る人にはお馴染みの「獲得標高」

ヒルクライムに限らず道を走っていると上り下りを繰り返しますが、登った標高差を積算したものを獲得標高と呼んでます。つまり、低い山でも上り下りを繰り返すルートであれば、多くの獲得標高を得られるわけです。

一般的に登山では「標高○○mの山に登頂」という風に、どれだけ高い地点に到達したか、言うなれば「到達標高」が注目されますが、ロードバイクではどれだけの量を登ったか、つまり獲得標高が重要で、あまり到達標高が話題になることはありません。

最近、以下のようなツイートをしたところいくつか反響をいただきました。

みんな同じ山に登ろうとすると、一握りの勝者以外は達成感も冒険心も満たされない。それなら、みんなそれぞれ登りたい山に登る方がよくない？
— 渡辺順也 INNOVATOR JAPAN (@junchang) June 9, 2020

特に人生を山登りに擬えたわけではないのですが、そのように理解される方が多かったように思います。

そこでふと考えたのですが、人間の一生においても獲得標高と到達標高、2つの評価指標があるような気がします。

獲得標高は、経験や挑戦の積み重ねの総量。主観的な指標でしか量れないので、他人からは見えづらい。

一方、到達標高は社会的な地位や名声。客観的な指標により定義され、他人から見えやすい。

前述のツイートにある「みんな同じ山に登りがち問題」は、獲得標高よりも到達標高を重視しているのも原因のひとつではないかと。

到達標高を目指すのであれば、得体の知れない山に登るよりも、既に誰かが登って標高が高いことがわかっていて、できれば登山道が整備されている方が確実ですよね？

一方で、未知の山であっても登り続ければ確実に獲得標高を稼げるし、登頂して物足りなければ一度下山して別の山に登るのもあり。

結局は個人の価値観次第ですが、より多くの人が獲得標高という指標があることを知ると人生もっと楽に楽しくなるのではないかなと思った次第です。（登っている時は毎回しんどいんですけどね…）

さらには、下山することは即ちアンラーニング（Unlearning）であり、イノベーションを実現するために不可欠な要素だったりします。ヒルクライムを頑張った後のダウンヒルは爽快ですよね！

というわけで、早くロードバイクでヒルクライムしに行きたいですね！